Machines need identities too

A scheduled job needs to read one storage container. Nobody is there to type a password every night. That job still needs an identity, a permission boundary, and a way to lose access when it is retired.

Workload identity: An identity used by software to authenticate and request access to resources.

A service account is not a person in disguise

Workload identities represent applications, jobs, or services. Give them owners and distinct purposes. Sharing one broad account across many jobs makes permission reviews and incident investigation difficult.

Separate environments and workloads where their risks or permissions differ. A test job should not inherit production access merely because both use the same deployment script. Inventory the dependencies before retiring an identity.

Tokens carry a destination and a lifetime

A token may have an issuer, audience, subject, expiry, and scopes or roles. These concepts need validation according to the actual protocol. A service should not accept a token just because it is well formed or signed by some known issuer. It must be intended for that service and appropriate to the request.

Short lifetimes reduce the duration of some exposure; they do not prevent misuse during the valid window. Avoid placing tokens in logs, client bundles, or other locations that do not need them.

Federation moves the trust decision

Federated workload credentials can let one environment prove a workload’s identity to another without a stored reusable password. The trust policy must bind the intended issuer, workload identity, and relevant execution context. Broad trust rules can turn convenience into unintended access.

A managed identity reduces credential-handling chores, but does not automatically choose least privilege. Review granted permissions, ownership, usage, and revocation paths. Credential rotation and identity retirement are related but different operations.

EXPLORE THE CONCEPT

What changed in the credential design?

Compare three choices for the same read-only job.

A shared permanent secret

Many jobs may gain the same authority and the secret needs protection and rotation. Attribution becomes harder.

A dedicated short-lived identity

A distinct identity and limited permissions improve attribution and reduce unnecessary scope; validation is still required.

Federation with broad trust rules

Removing a stored secret helps, but an overly broad trust policy may allow unintended workloads to obtain access.

A simplified learning model. It connects to no systems and uses no real data.

Follow a nightly summary through its decisions

A fictional transport cooperative runs a nightly job that reads yesterday’s aggregate journey counts and writes a summary. It does not need passenger names, payment records, or permission to delete source data. Mei owns the report’s purpose; the platform team operates the job. Give the workload a distinct identity so its authority can be compared with that approved purpose.

Separate authentication from authorization. The identity service decides whether this execution may obtain an appropriate credential. The receiving storage or reporting service then validates the credential and applies its access rules. Successful issuance does not mean every resource will accept the resulting token, or that every accepted request is permitted.

A token’s audience describes its intended recipient, not the dataset it may read. Scope, roles, resource policies, and other applicable rules determine permissions according to the service. In a federation flow, an external assertion used at the identity service and a resulting access token used at a resource can have different audiences. They perform different jobs; do not treat every signed token as interchangeable evidence.

PredictThe job presents a valid token intended for the reporting service to the photo-storage service. Both trust the same issuer. Is the issuer enough?

No. The recipient must validate the intended audience and the rest of its protocol requirements. A trusted issuer alone does not make a token intended for a different service acceptable.

Review who may obtain authority

Federation removes some stored-secret handling by accepting evidence from an external identity provider. That creates a trust boundary to review: which issuer, which workload identity, and which execution conditions are accepted? A rule for an approved production job should not accidentally include unrelated test runs simply because they originate from the same organization.

Provider mechanisms differ. Some bind exact claim values; other supported arrangements express additional conditions. Consult the selected product’s current documentation instead of copying a generic trust rule. Also identify who can change the accepted workload or its execution environment: that administrative power can affect which software runs with the approved identity.

Compare granted access with required access

The cooperative’s job needs to read one approved aggregate dataset and write one report area. A broad storage-administrator role exceeds that statement even if the job currently performs only reads and writes. Usage records help find exercised permissions, but an absence of observed use does not prove a permission is unnecessary. A monthly recovery task may fall outside a seven-day sample.

Ask the owner to confirm rare operations and dependencies. Propose a narrower role, define allowed and denied outcomes with fictional data, and identify a fallback if the change interrupts required work. This is a reasoned review, not permission to remove access based solely on a quiet dashboard.

Also account for other assignments: narrowing one role may leave broad access elsewhere. If a rare operation needs an exception, record its owner-approved purpose, limited conditions, and review date instead of retaining a broad role indefinitely.

Short-lived credentials reduce how long some previously issued authority remains usable. They do not automatically terminate all work when an identity is disabled. Issuance, existing-token acceptance, session state, and propagation behavior may differ. Retirement needs an owner, a dependency check, and evidence that the intended authority has ended. Continue with the permission-review case.

Turn the idea into a decision

The absence of a password file is not the absence of trust. Ask which workload can obtain which token and what that token permits.