Navigate to… Terms and acronyms What this is, and how to read it Passwords for programs, and why we refuse them Envelope encryption: the key idea The mailbox trick: public-key encryption Signing is not encrypting Locks and keys: symmetric encryption Who are you defending against? The two questions every secrets system must answer What a secret is Why secrets leak The cast of characters Where your private key actually lives What we deliberately do not have The bet: the server should be powerless How the layers stack Asserted vs attested: two very different promises Two modes, one format The uncomfortable truth we start from What the audit log can tell you phase 3 Bus factor When two people write at the same time The weekly checkup Fingerprints, and how trust is kept over time Giving someone access You lost your key. Now what? Reading a secret Taking access away The three rotations Versions, and how a secret changes without breaking anything Writing a secret Backups and drills Create an organization (serverless) Config reference Install Onboard a machine (CI, a service) Turn on the server (optional) phase 3 Onboard a teammate Asserted custody cannot be enforced We cannot protect you from your own machine Metadata leaks even though contents do not Stolen ciphertext can be attacked forever Cloud misconfiguration is outside our reach Revocation is not retroactive, and serverless mode has no read log You have to trust the client itself Command cheat sheet Glossary Cloud misconfiguration is outside our reach¶
With KMS custody, your cloud provider decides whether a workload's identity claim is genuine. If that trust policy is too loose, through a generic audience or a subject pattern matched by prefix, an attacker can obtain your machine principal's private key, and our client is never consulted. We refuse the configurations we can see (onboarding a machine ) and re-check what the provider's API exposes, but the authority is theirs. Review those policies as carefully as you would review a grant.