Every service needs to prove who it is before it can read a database, call another service or decrypt a file. The oldest answer, a password or access key in a config file, is also the cause of a large share of breaches: keys leak into Git, logs and laptops, and they never expire. Modern cloud identity is built to remove them. Workloads get short-lived credentials from the platform they run on, encryption keys never leave a managed key service, and the secrets that must exist live in a store that audits every read. Secrets and encryption, Authentication and Authorization and OAuth teach the concepts; this page maps them onto the three clouds.
Side by side
| AWS | Google Cloud | Azure | Self-hosted | |
|---|---|---|---|---|
| Identity for a workload | IAM roles with temporary credentials; EKS Pod Identity for Kubernetes | Service accounts, attached to the resource | Managed identities in Microsoft Entra ID | SPIFFE identities issued by SPIRE |
| Trust from outside the cloud (CI, other clouds) | IAM OIDC identity providers | Workload Identity Federation | Workload identity federation | SPIFFE federation |
| Encryption keys | KMS | Cloud KMS | Key Vault keys, Managed HSM | HashiCorp Vault transit engine |
| Secrets | Secrets Manager (Parameter Store for simple config) | Secret Manager | Key Vault secrets | Vault, including dynamic secrets |
| The limit that bites | KMS: 10,000 to 100,000 symmetric requests a second per account, by Region | Key creation for service accounts blocked by default in newer organisations | Key Vault: 4,000 secret transactions per 10 seconds per vault | Your Vault cluster's capacity |
| Secrets priced per | Secret-month plus API calls ($0.40 and $0.05 per 10,000) | Active secret version and access operation | 10,000 transactions | Servers and licences |