Skip to main content

Day 1 Wrap-up — Identity as the First Perimeter

Mitch Mommers18/05/2026About 3 min

Day 1 Wrap-up — Identity as the First Perimeter

Today we started with identity because identity is often the first security boundary in cloud environments.

Before looking at networks, storage, APIs or compliance, we need to know:

Who or what can do what?

What we covered

Today you worked through this cycle:

Main lessons

1. Workload identities are powerful

A managed identity is not a person, but it can still have permissions.

If an attacker controls the workload, they may be able to use those permissions.

2. Scope changes risk

A role may be acceptable at one scope and dangerous at another.

Contributor on one test resource

is very different from:

Contributor on a full resource group

3. Broad access is not correct access

The backend identity had broad management access, but still lacked the correct data-plane access for Key Vault.

This is the core lesson from Lab 1.2:

too much access in one place
does not mean
the right access in the correct place

4. Least privilege must be tested

A good fix should prove two things:

The legitimate application flow still works.
The risky action is blocked.

In this case:

TestDesired outcome
Backend reads required secretWorks
Backend modifies unnecessary Azure resource metadataFails

5. Zero Trust is a design habit

Zero Trust is not only a product.

It is a way of thinking about access:

explicit
limited
verified
monitored
removable

Final Day 1 model

Reflection questions

Discuss briefly:

  1. Which permission was too broad?
  2. Why was the scope important?
  3. What did the backend actually need?
  4. Why did Contributor not solve the Key Vault secret access?
  5. How did the fix reduce risk?
  6. What would you monitor after applying this fix?
Split Responsibility (Dev Vs SecOps)

A common production pattern is to split responsibility between teams and Terraform states.

For example, a development team may manage non-persistent resources such as App Services, deployments, temporary test resources, or application configuration. These resources can usually be recreated or changed more frequently.

A SecOps or platform team may manage persistent and security-sensitive resources such as Key Vaults, identities, role assignments, logging workspaces, policies, and shared networking. These resources are more sensitive because they protect data, control access, or are used by multiple applications.

In that model, both teams can use Terraform, but they do not manage the same state file:

dev-app.tfstate      → application and non-persistent resources
secops-core.tfstate  → persistent resources and access control

This separation reduces the need for the development deployment identity to manage security-critical permissions directly. It also creates a clearer ownership boundary: developers can deploy the application, while SecOps controls the long-lived resources and the permissions around them.

Bridge to Day 2

Today we reduced who can control the environment.

Tomorrow we look at what is exposed:

  • public access
  • network boundaries
  • storage exposure
  • encryption
  • remaining attack paths

Identity is only the first layer.

The next question is:

Even with better access control, what is still reachable?

Day 1 Challenge

If time allows we have a challenge: Click me!

Contributors: Mitch Mommers