CH07-02: Identity, Secrets, and Access Boundaries
Goal
The previous section introduced security selection as control-objective matching. The first control objective to understand is access: who can act, what they can affect, and how workloads authenticate when they call other services.
In Azure, access design usually combines identity, authorization scope, workload identity, and secret management. These are related, but they are not the same thing.
The durable idea for this section is:
Secure Azure design separates who can act, what scope they can affect, and how workloads access secrets or resources.
The Short Version
Microsoft Entra ID is the identity foundation for many Azure access decisions. In plain language, it is where users, groups, applications, service principals, and managed identities can be represented and authenticated.
Azure RBAC answers a different question. It decides what an authenticated identity can do at a specific Azure scope, such as a management group, subscription, resource group, or individual resource.
Managed identities solve a workload problem. They let supported Azure workloads authenticate to supported services without storing passwords, access keys, or client secrets in code or configuration.
Azure Key Vault solves a secret and key management problem. It stores and protects secrets, keys, and certificates, but it still needs careful access design. A vault with broad access is just a better-looking place to make the same old mistake.
The Access Boundary Model
Access design has two paths that often meet:
flowchart LR
A["Human identity<br/><small>User or group</small>"] --> B["Azure RBAC assignment<br/><small>Role + scope</small>"]
B --> C["Azure resource action<br/><small>Read, write, operate, deploy</small>"]
D["Workload identity<br/><small>Managed identity</small>"] --> E["Scoped permission<br/><small>Only what the app needs</small>"]
E --> F["Key Vault or Azure service<br/><small>Secret, key, certificate, or resource access</small>"]The top path is usually about people and operations. The bottom path is usually about applications, automation, and service-to-service access.
These paths should be designed deliberately. Production operators may need read access, deployment rights, or break-glass procedures. Applications may need to read one secret, write to one queue, or connect to one database. Automation may need deployment permissions in one resource group but not broad ownership of a subscription.
Identity Is Not Authorization
Authentication proves who or what is calling. Authorization decides what that caller is allowed to do.
This distinction matters because teams often say, "The app uses Entra ID, so it is secure." That is only the start. After the identity exists, the design still needs to decide what permissions it receives, at which scope, through which group or assignment, and how those permissions are reviewed.
Azure RBAC uses role assignments to connect three pieces:
| Piece | Plain Meaning | Example |
|---|---|---|
| Security principal | Who or what receives access. | User, group, service principal, or managed identity. |
| Role definition | What actions are allowed. | Reader, Contributor, Key Vault Secrets User, or a custom role. |
| Scope | Where the role applies. | Subscription, resource group, or a specific resource. |
This is why scope matters so much. A Contributor role on one resource group is very different from a Contributor role on a whole subscription. A reader role for troubleshooting is very different from Owner access that can grant permissions to others.
Managed Identities Reduce Secret Handling
Applications often need to call other services. A web API may need to read from storage. A function may need to send a message. A container app may need to read a secret from Key Vault. The older pattern is to store a connection string, password, certificate, or access key somewhere the application can read it.
That creates a recurring risk: secrets leak through configuration, deployment scripts, source control, logs, tickets, screenshots, or overly broad operator access.
A managed identity gives an Azure workload an identity it can use to request tokens. The workload can then access supported services if that identity has been granted the right permission. The important point is not magic. The important point is removing static credentials from the application path where possible.
Managed identity does not remove the need for authorization. A workload identity with excessive permissions is still risky. The design should grant only the permissions the workload needs, preferably at the narrowest practical scope.
Key Vault Protects Sensitive Material
Azure Key Vault is used for secrets, keys, and certificates. Examples include API keys, database connection strings, signing keys, encryption keys, and TLS certificates.
Key Vault helps because it centralizes sensitive material, supports access control, and can produce logs that show how secrets and keys are accessed. It also separates secret storage from application code. Instead of embedding a database password in source code, an application can retrieve a secret from Key Vault at runtime or use a platform integration that references it.
But Key Vault is not a design excuse to be careless. You still need to decide:
| Design Question | Why It Matters |
|---|---|
| Who can manage the vault? | Vault administration can become a powerful privilege. |
| Who can read secrets or use keys? | Secret access should be narrower than general application administration. |
| Which workloads need access? | A shared vault can become too broad if every app uses it. |
| How are secrets rotated? | A secret store without lifecycle planning can preserve old risk. |
| How is access monitored? | Logs and alerts help reveal misuse or unexpected access. |
| Should network access be restricted? | Private access and firewall settings may be needed for sensitive workloads. |
For many architectures, a strong pattern is: use managed identity for the workload, grant it narrow access to Key Vault or to the target service, and avoid putting long-lived credentials in app settings.
Example: API Access Design
Imagine a customer API that reads sensitive records from a database and uses a signing certificate for tokens.
A weak design might give several developers Owner access to the production resource group, store a database password in application settings, and keep the signing certificate in a deployment pipeline variable. The system may work, but the access story is blurry. Too many people can change too much. Secrets live in too many places. Audit evidence is difficult to explain.
A stronger design could look like this:
| Need | Design Choice |
|---|---|
| Operators need production visibility. | Assign Reader or purpose-specific roles through Microsoft Entra ID groups. |
| Deployment automation needs to update the API. | Use a dedicated identity with scoped deployment permissions. |
| The API needs secret access. | Enable a managed identity for the workload. |
| The signing certificate must be protected. | Store it in Key Vault and grant only the API identity permission to use or read what it needs. |
| Emergency access must exist but be controlled. | Define break-glass access, logging, and review. |
| Auditors need proof of access control. | Retain role assignments, Key Vault access logs, and access review evidence. |
This design is not only more secure. It is easier to explain.
Common Mistakes
Storing secrets in code, plain configuration, local files, or deployment scripts.
Giving broad Owner or Contributor access because it is faster during delivery.
Confusing authentication with authorization.
Creating managed identities but granting them excessive permissions.
Protecting secrets in Key Vault while leaving vault access too broad.
Forgetting that operators, workloads, deployment pipelines, and emergency access need different access patterns.
If Someone Asks You
How do identity, RBAC, managed identities, and Key Vault work together?
A good answer is:
Microsoft Entra ID provides the identity foundation. Azure RBAC grants permissions to users, groups, applications, service principals, or managed identities at Azure scopes. Managed identities let workloads authenticate to supported services without storing credentials in code. Key Vault stores and protects secrets, keys, and certificates. A good design combines them with least privilege, narrow scopes, monitoring, rotation, and access reviews.
What You Should Remember
Identity decides who acts; RBAC scopes the action; managed identity and Key Vault reduce secret exposure.
Questions to Check Your Understanding
What is the difference between identity and authorization?
Why do managed identities reduce secret-handling risk?
Why does Key Vault still require careful access design?