Encryption-key grants: inventory and retire temporary authority

Last updated: 5 Oct 20266 min read

tutorial

Managed services commonly create grants to use a customer-managed encryption key for a resource. A grant names a grantee and allowed operations, and may constrain cryptographic requests by encryption context or source resource. A key policy review that ignores active grants misses part of the authority picture. Revoking a grant during incident response can also break a healthy volume, archive, or replication process, so removal requires a resource-to-grant map.

Operational decision

A billing archive copies encrypted documents to a recovery account. Inventory the source and destination key policies, active grants, grantees, operations, constraints, and the storage resources that depend on them. In a disposable environment, create a constrained grant for a copy worker, complete one copy, and verify that a decrypt with the expected context succeeds while a mismatched context fails. If grant creation is retried after an ambiguous response, list grants before creating another so duplicate authority is visible. Retire the temporary grant only after the service has finished using it, then repeat the read with the permanent recovery role to prove the backup remains accessible. During key rotation, test an older encrypted object before retiring old grants or scheduling key deletion. Record grant identifiers outside public logs; encryption context is often logged in plaintext and must not contain customer secrets. For an incident, identify the exact malicious grantee and affected resources before revoking broad service grants that could take production storage offline.

Archive key-grant review
Key: source and recovery key identifiers
Grant: ID, grantee, operations, creation time
Constraint: approved context or source resource
Dependency: archive or copy job using grant
Negative test: wrong context denied
Retirement: job complete and older restore still works

Cost and verification

For G grants across K keys, inventory is O(G + K) records; matching grants to dependent resources adds a join against resource inventory. Stale grants increase review and exposure cost, while premature retirement adds outage risk. Measure grant count by key and grantee, duplicate grants, age after job completion, and failed decrypts after cleanup. A digest-valid object is not recoverable if no approved principal can decrypt it.

Common Mistakes

Do not infer complete key authority from the key policy alone.
Do not use customer secrets as encryption-context values.
Do not revoke a service grant before mapping the resource that uses it.

Connected lessons

Practice and check

devops

cloud-security