Workload identity identifies an executing service or process; privileged-access management controls elevated actions and sessions. Authentication establishes an identity, while authorization determines which resources and actions that identity can use.

Identities, credentials and permissions

A credential supplies evidence used in authentication. A permission defines an allowed operation over a resource. Possessing a valid credential therefore does not specify every action the authenticated identity can perform.

SPIFFE defines workload identities and associated identity documents and interfaces. Vault can issue dynamic credentials. These mechanisms connect executing software to authentication material, but the financial application still needs an authorization decision for the requested account, dataset or action.

A human administrator and an automated service also have different operating lifecycles. A service needs issuance, renewal and recovery that work without a person handling every credential. A privileged human session needs an accountable actor and controls appropriate to its approved purpose.

A balance reader and an administrator

Take a service credential that permits reading balances and an administrator role that permits changing configuration. Neither permission, by itself, authorizes transferring a customer’s money. The payment operation has a separate resource and action scope.

Rotating the balance reader’s credential changes the authentication material. It does not decide whether the service should gain payment permission. Revoking payment permission changes authorization; it need not mean that the identity ceases to exist for every other operation.

An access record therefore needs the identity, credential or session context, requested resource, requested action and decision. Logging only successful authentication leaves the financial permission question unanswered.

Keys and administrative authority

Cryptographic key management introduces another boundary. Authority to administer stored objects need not include authority to decrypt their contents. Likewise, permission to request a protected key operation does not automatically authorize a financial transaction involving the recovered data.

A complete access path identifies the issuer, policy authority, credential lifetime and application enforcement point. A secrets store can serve several workflows without making their permissions equivalent.

Credential lifetime and recovery

Short-lived credentials constrain how long a particular issued credential remains usable under its validity rules. They also require a working renewal path when new credentials are needed. Cached authority, expiration and alternate access determine the effect of an issuer outage.

What changes across deployments is the trust domain, issuer, policy and recovery arrangement. The distinction between identity, evidence of identity and permission remains necessary in each deployment.

Questions about principal

Does being on a private network establish trust?

No. Network location alone does not establish the requested resource permission.

Does rotating a credential revoke every permission?

No. Credential lifecycle and authorization policy must be evaluated separately.