Workload Identities, Temporary Credentials, and Secrets

Goal

Show how applications, automation, and platform components should authenticate without borrowing human identities.

The Short Version

A workload should prove what it is and receive the shortest-lived credential that its task permits.

Workloads need identities with independent ownership, scope, rotation, and revocation. The important architecture move is to make the boundary explicit before selecting a cloud feature. A feature can automate a decision, but it cannot decide the organization's risk tolerance, ownership model, or acceptable failure behavior.

Use this section as a decision tool. Name the actor or producer, the protected or affected resource, the contract between them, the conditions under which the action is allowed, and the evidence that will show whether the design worked.

Mental Model

Compare two paths: application reads a stored credential versus application presents platform identity and receives a temporary token.

flowchart LR
    N1["Actor"] --> N2["Credential or assertion"] --> N3["Identity provider"] --> N4["Policy decision"] --> N5["Resource"] --> N6["Evidence"]

Read the diagram from left to right, then review it from right to left. The forward pass explains how work succeeds. The reverse pass asks whether an operator can trace an outcome back to its initiating identity, input, policy, route, or contract.

Architecture Decisions

The answers should be recorded with the workload design. If the answer is merely "the platform default," the team has discovered an assumption, not completed an architecture decision.

Core Ideas

Workloads need identities with independent ownership, scope, rotation, and revocation

Workloads need identities with independent ownership, scope, rotation, and revocation. Make the owner, boundary, failure behavior, and evidence explicit. That turns the concept from a configuration choice into a design decision that another team can review and operate.

Platform-managed identities, roles, and federation can issue short-lived credentials without storing reusable keys

Platform-managed identities, roles, and federation can issue short-lived credentials without storing reusable keys. Make the owner, boundary, failure behavior, and evidence explicit. That turns the concept from a configuration choice into a design decision that another team can review and operate.

Secrets that cannot be eliminated need protected storage, controlled retrieval, rotation, expiry, and usage evidence

Secrets that cannot be eliminated need protected storage, controlled retrieval, rotation, expiry, and usage evidence. Make the owner, boundary, failure behavior, and evidence explicit. That turns the concept from a configuration choice into a design decision that another team can review and operate.

Provider Lenses

AWS commonly expresses these responsibilities through IAM identities, roles, policies, IAM Identity Center, and permission boundaries. Azure commonly uses Microsoft Entra ID for identity, Azure RBAC for resource authorization, managed identities for workloads, and PIM for time-bound privileged access. The useful comparison is the responsibility each feature carries, not a claim that the names are exact equivalents.

Provider lenses are useful for implementation planning, but they should come after the provider-neutral decision. This keeps the reasoning portable and makes differences in defaults, scope, and operational responsibility easier to detect.

Example: Applying the Decision

An application reads a database, a CI pipeline publishes an artifact, and a partner API still requires a client secret.

Use separate identities for people, pipelines, and running workloads; separate production from non-production authorization; require stronger approval for production elevation; and record both control-plane changes and data access where the risk requires it.

A review should finish with named owners, a testable success path, expected failure modes, and observable evidence. That is more useful than a diagram that only proves the components can connect.

Common Mistakes

• Sharing one workload identity across unrelated applications or environments. It hides a boundary or enlarges the impact of failure, so record the safer alternative in the design.

• Embedding access keys in code, images, configuration, or pipeline variables. It hides a boundary or enlarges the impact of failure, so record the safer alternative in the design.

• Moving a secret into a vault but never rotating or reducing its scope. It hides a boundary or enlarges the impact of failure, so record the safer alternative in the design.

If Someone Asks You

When does a workload need a secret, and when does it need an identity?

A clear answer is:

A workload should prove what it is and receive the shortest-lived credential that its task permits.

I would then show the decision path, the responsibility boundary, and the evidence used to review it. That explanation connects the technical mechanism to its architecture purpose.

What You Should Remember

A workload should prove what it is and receive the shortest-lived credential that its task permits.

Questions to Check Your Understanding

1. Why should workloads not reuse human credentials?

2. What risk do temporary credentials reduce?

3. Which lifecycle controls remain when a secret cannot be eliminated?