IAM / Secrets

IAM and secrets solve different problems

Identity and Access Management (IAM) answers who is allowed to do what. Secrets management answers how sensitive credentials are stored, rotated, audited, and delivered. They work together, but treating them as one vague security feature hides important design decisions.

Least privilege

IAM should follow the principle of least privilege: a workload gets only the permissions necessary for its job. A document worker that needs to read one storage bucket should not automatically have administrator access to the entire account.

Identities can represent humans, services, workloads, or federated external principals. Policies then define which actions are permitted on which resources. Workload identities and short-lived credentials are usually safer than permanent keys because compromise windows become smaller.

Secrets management

Secrets include passwords, API tokens, private certificates, database credentials, webhook signing keys, and encryption material. They should not be committed to source control, baked into public container images, or copied into logs.

A secrets manager can encrypt values at rest, restrict retrieval to authorized identities, record access, and support rotation. At runtime, secrets may be exposed through environment variables, mounted files, sidecars, or platform-native identity mechanisms. The design should minimize copies and make revocation practical.

Common failure modes

A leaked API key is obvious, but broad permissions can be just as dangerous. If a compromised inference worker can read unrelated customer data, the blast radius is much larger than the original credential exposure.

Rotation is another operational problem. Long-lived credentials that nobody remembers how to rotate become permanent liabilities. Good systems make rotation routine rather than an emergency procedure.

Logging is an easy leakage path: authorization headers, environment variables, request payloads, and error objects can accidentally contain credentials or sensitive data.

Example

An inference service may need permission to read model artifacts from one object-storage bucket and publish metrics. It should not need permission to change billing settings or read another team's database. Its workload identity provides the required access, while the remaining sensitive bootstrap material is retrieved from a secrets manager.

The core idea

IAM controls identity and authorization. Secrets management controls sensitive credentials. Secure systems combine least privilege, strong identity, short credential lifetimes where possible, safe storage, rotation, and auditability.