Identity, Secrets & Encryption
The deepest infrastructure module. Identity → policy → action → resource; human credentials versus workload identity; policy anatomy and blast radius; short-lived role credentials instead of static keys; secret storage, rotation, audit and revocation; and the key hierarchy behind encryption at rest.
Four nouns explain every access decision in cloud infrastructure: an identity performs an action on a resource, and a policy says whether that is allowed. Everything else — roles, groups, conditions, boundaries — is a way of managing those four at scale.
Q · When a request reaches a cloud service, what exactly decides whether it is allowed?
Applications should not borrow human credentials. A developer's access key in an environment variable gives the application the developer's permissions, records the developer as the actor in every audit log, and takes production down the day that developer is offboarded.
Q · Whose identity should an application present when it calls a cloud service?
Take one workload, write down what it actually needs, then read what its policy actually grants. The gap between those two lists is the lesson — and the blast radius is how you measure it.
Q · How do I read a policy and tell, in under a minute, whether it grants more than the workload needs?
The measure is not how clean the policy looks. It is what an attacker can do in the first ten minutes after they hold this credential. Ask the blast-radius question out loud, for every identity, before it reaches production.
Q · What is the blast radius if this identity is compromised?
A workload should receive a credential that expires in minutes, not hold one that never does. A leaked one-hour token is an incident with an end time; a leaked long-lived key is an unbounded one that may already be years old.
Q · Why is a short-lived role credential a fundamentally different security object from a long-lived access key?
The secrets that genuinely cannot be roles — third-party keys, database passwords, signing material — need one place that answers five questions: where it is stored, who may read it, how it rotates, who read it last, and how fast it can be revoked.
Q · Where does a credential live when the workload cannot get one from an identity provider?
Data is encrypted with a data key; the data key is encrypted by a key you never see, held in a key management service. What you actually operate is not cryptography — it is the policy on that key, and the answers to who can decrypt, what deletion means, and what rotation really re-encrypts.
Q · If everything is encrypted at rest by default, what is actually left for me to decide?