Who controls the key
1. Who controls the key
SSE-KMS buys you a key you own, and a key policy to go with it. That was last time. Here is what it costs you: a role with a KMS allow in its IAM policy can still be denied, because two policies are always in the room.2. Two kinds of KMS key
Which two, and who writes them? That depends on the key. An AWS managed key is created and run for you by a service, under an alias like aws/s3. Its policy is readable, not editable.3. Two kinds of KMS key
A customer managed key is one you create, like alias/reports, and its policy is yours to write, for a dollar a month. A pool car and a leased car both drive; only one lets you say who else may.4. Two gates, and both must open
So that key has a policy, and here is what surprises people. Your IAM policy is the first gate, the one you already know: what this caller may ask for.5. Two gates, and both must open
The second gate is the key policy, a resource policy attached to the key itself. Every key ships with a statement saying IAM decides; remove it and your IAM allows go inert. Money moves only when both banks accept it. A grant does the same for one principal, and AWS services use them.6. The key never touches your data
Why does the key deny the call rather than the bucket? KMS will not encrypt more than four kilobytes directly, so your object never reaches it. A separate call does, authorized separately.7. The key never touches your data
GenerateDataKey returns one data key in two forms: a plaintext copy that encrypts the object, and an encrypted copy stored beside it. Reading it back calls kms:Decrypt on that stored copy. Think of a vault holding the key to the unit, not the furniture.8. Across accounts, nobody sees both halves
Cross-account use is the same two gates, moved apart. The caller's IAM policy must allow the action on the key's ARN.9. Across accounts, nobody sees both halves
But the key policy lives in the other account, and it must name yours, or a role inside it. Two administrators, two files, and neither can see the other's. That is why this fails so often.10. Read the denial, not the guess
When it fails, the message names the gate. AccessDeniedException, then the clause that matters: because no identity-based policy allows the kms:Decrypt action. That is the caller's own IAM policy.11. Read the denial, not the guess
Swap identity-based for resource-based and the gate that closed is the key policy. Same error code, different half of the sentence, and it tells you which file to open.12. What rotation actually changes
That is diagnosis. Now the control that looks like a fix. Rotation replaces the key material behind the key. On a customer managed key you switch it on or off and choose the period, with a default of a year.13. What rotation actually changes
You can also rotate on demand, at any time. Two limits matter. AWS managed keys rotate yearly and you cannot change that, and automatic rotation covers only symmetric keys whose material KMS generated.14. What rotation does not fix
Now the important half. Rotation changes the engine, not the license plate. The key ID, the ARN, the aliases, and the policy all stay as they were.15. What rotation does not fix
That cuts both ways. Old objects keep their old key material, and nothing in your code changes. But rotation fixes neither gate. Before you rotate to fix a denial, ask which one was closed.16. So why switch it on
So why switch it on? That limitation is the point: each version protects only the slice written under it, so no single version ever covers all your data. Compliance and contract rules often mandate rotation too, and this is how you meet them.17. So why switch it on
And it costs nothing: KMS picks the right version on decrypt, with no code change.18. Let's practice!
Now it's time to put key control into practice with some exercises.Create Your Free Account
or
By continuing, you accept our Terms of Use, our Privacy Policy and that your data is stored in the USA.