Lesson 6.2 · 12 min read
Policies across AWS, Google Cloud and Azure
The same control expressed in three clouds' policy languages.
One control, three syntaxes
| AWS | Google Cloud | Azure | |
|---|---|---|---|
| Where the rule lives | KMS key policy (or IAM policy) condition keys | Workload identity pool provider attribute condition, plus IAM on the KMS key | Key release policy on a Key Vault Premium or Managed HSM key |
| What is matched | kms:RecipientAttestation:ImageSha384, kms:RecipientAttestation:PCR<n> | Token claims such as assertion.submods.container.image_digest | Claims in the MAA token, such as attestation type and compliance status |
| Who verifies evidence | KMS itself | Google Cloud attestation service | Microsoft Azure Attestation |
| How the key reaches the TEE | Encrypted to the attestation document's public key | Federated credentials let the workload call Cloud KMS | Key released wrapped to a key held by the TEE |
Secrets that should never be in images
- API keys, database passwords and signing keys baked into a container or EIF are part of the measured image. Anyone with the image has them, and rotating them changes the measurement.
- Environment variables and command-line arguments supplied by the host are untrusted input and visible to the host.
- Fetch secrets after attestation, encrypted to the TEE, and keep them in memory only.
Key takeaways
- AWS matches PCRs in key policies; Google Cloud matches token claims in attribute conditions; Azure matches token claims in release policies.
- Use one internal standard for every attested key, regardless of cloud.
- Never bake secrets into measured images or pass them via host-controlled environment variables.