Azure / Advanced: secure and recoverable architecture / Lesson 14

Workload identity, secrets, and layered security

Build a narrow trust path between an application and its dependencies. Separate managed identity, role assignment, secret lifecycle, network access, encryption, and application permission.

About 5 min readContent reviewed 2026-10-25

On this page

Lesson goals

Compare system-assigned and user-assigned identity lifecycles.
Model least privilege and selected diagnostic fields.
Explain why a vault or private endpoint is not complete security.

Managed identity changes credential ownership

Managed identities let supported workloads obtain Microsoft Entra tokens without application-managed credential material for that identity. They do not automatically grant access to every downstream resource. A system-assigned identity is tied to its resource lifecycle, while a user-assigned identity is a separate resource that can be attached under supported rules. Recreating or changing a resource can therefore have identity and permission consequences that a code-only rollback misses. Choose deliberately, record which principal the application actually selects, and verify the target service supports the intended authentication path. Do not assume a display name uniquely identifies the security principal.

Draw every boundary on the dependency path

An API reading a document container needs a selected workload identity, a token for the right target, a suitable data role at the intended scope, a permitted network path, and application rules for the requested document. The model below lists those requirements without creating an identity or assignment. A private endpoint changes reachability but does not replace data authorization. A role at a broad parent scope can exceed the intended container-only design. Review inherited access and alternate credentials so a test does not accidentally succeed through a shared key while the intended identity path is broken.

json A synthetic service-to-service trust path

{
  "model": "workload-trust-path-only",
  "workload": "document-api",
  "requires": [
    "selected-managed-identity",
    "correct-token-target",
    "container-scoped-data-role",
    "permitted-network-path",
    "document-authorization"
  ],
  "alternate_credentials_reviewed": false
}

Expected output

all boundaries and alternate credential paths need explicit review

The model contains no tenant, principal identifier, token, secret, or actual assignment and proves no live access.

A vault needs bootstrap, permission, and recovery design

Azure Key Vault provides managed capabilities for secrets, keys, and certificates under its supported contracts. Storing a secret there does not decide which workload can retrieve it, how versions rotate, how cached values expire, or how the workload behaves during an outage. Use the minimum required operation and scope, protect network access and logs, and plan revocation and recovery. Different key ownership and encryption choices create availability and restore dependencies. Avoid placing secret values in tags, infrastructure outputs, logs, or examples. A rotation plan should account for old/new compatibility and confirmation before removing an older required version.

Keep useful evidence while removing sensitive payloads

Use allowlisted diagnostic fields rather than logging a request or configuration object wholesale. The offline model retains an operation and correlation label while excluding a synthetic token field. It is a data-selection demonstration, not proof that every runtime, exception path, or logging channel redacts secrets. Treat identifiers as scoped operational data and control retention and access. A 403 investigation should preserve safe target, action, identity selection, and failure category, then trace role and network boundaries without copying a token. Automated collection should be tested for accidental secret exposure before being enabled in a real environment.

python Offline allowlisted diagnostic projection

event = {"operation": "read-document", "correlation": "synthetic-17", "token": "synthetic-not-a-credential"}
allowed = {"operation", "correlation"}
safe = {key: value for key, value in event.items() if key in allowed}
print(",".join(sorted(safe)))
print("token" in safe)

Expected output

correlation,operation
False

The token text is intentionally fake and never used. The check covers this dictionary projection only.

Layer controls and test the denied path

Security design spans identity, authorization, network exposure, input handling, data protection, dependency trust, monitoring, and recovery. Azure Policy, Defender for Cloud capabilities where selected, and other governance tools can support that work but do not certify the application merely by being present. Define permitted and prohibited actor/action/object cases, and verify absence of private data or side effects after denial in a future authorized setup. This course performs no identity creation, role change, token acquisition, vault access, security scan, or cloud action. Its models teach ownership and evidence boundaries rather than claiming a secure deployed environment.

Common errors and fixes

Enabling managed identity is treated as granting data access

Why it happens: Credential acquisition and authorization are conflated.
How to fix it: Verify target support, selected principal, role, scope, and network path.
Prevent it next time: Include a denied scope and alternate-credential review.

Secret storage is called a complete rotation policy

Why it happens: Version, cache, revocation, and recovery behavior are omitted.
How to fix it: Design and verify the whole secret lifecycle.
Prevent it next time: Test compatibility and failure paths before removing old versions.

Full configuration is logged to diagnose access

Why it happens: Private data is collected without a minimal schema.
How to fix it: Use safe allowlisted context and controlled retention.
Prevent it next time: Test every logging and exception path for sensitive exposure.

Check your understanding

1. A workload moved to a new resource cannot read the same container. What identity question matters?

Show worked solution

Determine which principal is now selected and whether its lifecycle changed, especially for a system-assigned identity. Then inspect the intended target, role scope, credential path, and network conditions. A matching display name or unchanged application code does not prove the new resource has the old principal’s access.

2. What does the safe-diagnostic model establish?