Secrets & IAM
Where credentials live, how they rotate, and the least-privilege identity model that decides what a compromise costs.
Two Questions, Not One
Both matter because compromise is assumed, not hypothetical. The useful question is not whether a credential will leak but what it can do when it does, and how quickly it stops working.
That is the whole shape of the discipline: store it properly, grant it as little as possible, and make it short-lived. A key with narrow permissions that expires in an hour is a far smaller problem than a well-encrypted one that can do anything, forever.
Secrets Management
A secret is anything that grants access: database passwords, API keys, signing keys, certificates, tokens. The rule is simple and constantly broken — they never go in the repository.
| Where | Verdict |
|---|---|
| Committed in source | Never — git history keeps it after deletion |
| In a CI config file | Never — same problem, more readers |
| Environment variables | Workable, but visible in process listings and dumps |
| A secret manager | Correct — versioned, audited, rotatable |
| Mounted at runtime | Correct — never lands in the image |
Rotation is what limits the damage window, and it has to be routine rather than an emergency procedure. If rotating a credential is frightening, that is the finding — it means nobody knows everything that uses it.
Never bake secrets into a container image. Anyone who can pull the image can read them, layers and all. Inject at runtime, from the secret store.
IAM & Least Privilege
Identity and access management decides what an identity can do. Least privilege means exactly what the job needs and nothing more — the difference between an incident and a catastrophe.
| Practice | Instead of |
|---|---|
| A role assumed at runtime | A long-lived access key in config |
| Permissions per service | One shared admin credential |
| Scoped to specific resources | Wildcards on everything |
| Temporary elevation, audited | Standing production access |
| Groups and roles | Permissions attached per person |
Prefer identity over keys. A workload that assumes a role receives short-lived credentials automatically, with nothing to store, leak or rotate. A static key is a permanent liability whose only defence is that nobody has found it yet.
Audit logging is the other half. Knowing who did what, and when, is what turns an incident into an investigation rather than a guess — and it must be written somewhere the compromised identity cannot edit.
Interview Questions
A secret was committed and then deleted. Is it safe?
No. It remains in git history, in every clone and every fork. The only real remediation is rotating the credential and treating it as compromised from the moment it was pushed.
Why prefer roles over long-lived keys?
An assumed role hands out short-lived credentials automatically — nothing to store, leak or rotate, and a narrow window if it is stolen. A static key stays valid until someone remembers to revoke it.
Why not bake secrets into container images?
Anyone who can pull the image can read them, including from earlier layers after apparent deletion. Images get shared, cached and pushed to registries. Inject at runtime instead.
What does least privilege actually buy?
It bounds the blast radius. Compromise is assumed, so the question is what the credential can do — a read-only key scoped to one bucket is an incident, an admin key is a catastrophe.
Why review permissions on a schedule?
They only ever accumulate. People change teams and temporary grants become permanent, so entitlement drifts far past anything anyone would approve today.
Are environment variables good enough?
Better than committing them, worse than a secret manager. They appear in process listings, crash dumps and debug output, and they offer no versioning, audit or rotation.