After Lab 1.3 — Recap

In Lab 1.3, you changed the access model.

The goal was to remove excessive access and add the correct permission.

---

Before the fix

The backend managed identity had:

Contributor
at resource group scope

This allowed too many management-plane actions.

But it still did not provide the correct data-plane access to read Key Vault secrets.

---

After the fix

The backend managed identity should now have a more specific role assignment.

Example:

Key Vault Secrets User
at Key Vault scope

This better matches the actual task of the backend application.

---

Before and after

---

Expected result

Endpoint	Before fix	After fix
/api/impact-demo/tag-self	Works	Fails
/api/secret-demo	Fails	Works

Caution

This was a rather small risk as changing tags on it's own can be quite mudane. However as we think about it we had full contributor on the entire resource group... this would allow us to do all kinds of things. Like?

The expected results are there:

Figuur 0: Ok, we got a secret

And ...

Figuur 0: And changing tags isn't possible anymore

---

Key lesson

A secure permission model is not just smaller.

It is more accurate.

right identity
+ right role
+ right scope
+ right reason

---

What we improved

We reduced:

• unnecessary management-plane access
• broad resource group permissions
• the blast radius of a compromised backend
• dependency on trust

We improved:

• task-specific access
• separation between application access and infrastructure management
• alignment with least privilege

---

Why this matters in real environments

In real cloud environments, teams often start with broad permissions because they are easy. Especially during development, however keeping these broad permissions can create risks in the short and long term.

It's thus very important that teams keep track of required permissions during the development cycle and update the environments accordingly.

A better model is thus designed around the actual task:

What does this identity need to do?
Which exact role supports that task?
What is the narrowest useful scope?
How can we test that the model still works?

One Step Further

This example shows how you can scope the permissions to the exact Key Vault secret and thus provide even more narrowly scoped permissions.

Figuur 0: Changes using the exact secret

As a result it's scoped to the resource:

Figuur 0: IAM for demo-api-message

Bridge to Lab 1.4

In the final Day 1 lab, we take a step back from the technical fix. We will translate the RBAC change into a simple Zero Trust access model.