Long-lived object-storage keys are easy to distribute and hard to retire. MinIO's Security Token Service offers a different model. Applications exchange a trusted identity for temporary access credentials that include an expiration and, where supported, a session policy. The security review should cover how the identity is established, how the policy is bounded, and what happens when access needs to end early.
Temporary does not mean unconstrained
MinIO STS supports several identity inputs, including existing MinIO identities, OIDC tokens, LDAP identities, client certificates, and custom tokens. The exact endpoint differs, but the result is the same class of object: an access key, secret key, session token, and expiration. Applications must use the session token together with the temporary keys.
A common mistake is to treat the short duration as the whole control. If a token can request a policy with access to every bucket, the token has broad authority for its lifetime. Use an inline session policy to narrow the result when the workflow supports it. Start with the exact bucket prefixes, object operations, and conditions the workload needs.
The identity mapping also matters. An OIDC claim, LDAP group, certificate subject, or built-in user can map to a policy. A change to that mapping changes the credentials the application receives even when the application code and the STS request remain unchanged.
Separate bootstrap identity from workload access
The credential that calls STS is a bootstrap credential. It should not be the same principal that performs normal reads and writes after the exchange. Give the bootstrap path a narrow identity and prevent it from being used as a general-purpose object-storage key. Workloads should receive only the temporary credentials they need for the job.
Map each identity source to an owner and a lifecycle. An OIDC integration depends on issuer metadata, audience, and claim mapping. A certificate integration depends on the issuing CA and subject rules. An LDAP integration depends on group membership and directory availability. These are separate failure modes, and each needs a negative test.
Expiration is not revocation
MinIO documents that STS credentials expire. Some deployments also support revoking STS tokens before expiration. Where revocation is available, use it for offboarding, incident response, and failed deployment rollback. Keep a record that links the session token to the identity and policy so an operator can identify what to revoke. Do not store the session secret itself in logs.
Expiration should be short enough to limit stale access and long enough for the workload to complete without uncontrolled chaining. A job that runs for hours may need a renewal path rather than an extremely long initial duration. A renewal path should re-check identity and policy, not simply extend the token because the old one is still valid.
Tests that expose unsafe assumptions
Request credentials with the intended policy and perform one allowed operation. Then try a different bucket, a different prefix, an administrative operation, and a request without the session token. Confirm that failures are authorization failures and not malformed requests. Test after an identity group change to confirm that the new policy is reflected.
Check the expiration timestamp in the response and the storage client's handling of an expired session. Test time skew between the application host and the identity provider. A token can be valid at the provider but unusable at the client because the local clock is wrong.
MinIO STS provides a useful way to reduce standing access. The design is stronger when the bootstrap identity, session policy, expiration, revocation path, and audit trail are reviewed together. A temporary credential with an unexamined policy remains an unexamined permission.