Where your private key actually lives
Your private key has to be somewhere, and that choice is the single biggest security decision you will make. We call it custody, and the tool supports four options behind one interface. Nothing else in the system changes based on which you pick, since a grant is a grant either way.
| Custody | How it protects the key | Best for | Available |
|---|---|---|---|
| File | A file on disk, ideally locked with a passphrase that is stretched with a deliberately slow function so guessing is expensive | Getting started; small teams; machines with no cloud identity | Phase 1 |
| Security key (FIDO2) | A hardware device derives the unlocking key inside itself. It cannot be copied off the device, and it requires a physical touch | People, especially anyone with production access | (phase 2) |
| Cloud KMS | Your private key is stored encrypted, and only a cloud key-management service can decrypt it. The workload proves its identity to the cloud to ask | CI pipelines and services, including in serverless mode | (phase 2) |
| Ambient cloud identity | Same idea, but the workload is already inside the cloud's identity system (an instance role or service account) | Servers running in the cloud that hosts your KMS | (phase 2) |
Worth knowing
Cloud KMS custody works in serverless mode too. The KMS belongs to your cloud provider, so using it does not mean running any infrastructure of ours. A CI job with no secrets on disk at all is achievable without ever deploying our server.