A role in account B is allowed s3:GetObject by both its own IAM policy and the bucket policy in account A, yet every download returns AccessDenied. The objects are encrypted with a customer managed AWS KMS key owned by account A. Why does the request still fail, and what has to change?

## Two authorizations, not one When an object is encrypted under a KMS key, a read crosses two independent permission checks: 1. **The service action.** S3 decides whether the caller may perform `s3:GetObject` on that object, using the caller's identity policy and the bucket policy. 2. **The key action.** S3 then needs the object's data key in usable form, so it calls KMS on the caller's behalf. KMS decides whether that caller may perform `kms:Decrypt` on the key, using the *key policy* and the caller's identity policy. Either check can deny. The failure in the scenario is the second one, and it is confusing because the error S3 returns to the client is an ordinary `AccessDenied` — the same shape you get for a missing `s3:GetObject`. Engineers then re-read the bucket policy over and over, which is already correct. ## Why the key policy is not implied by the bucket policy A KMS key policy is the key's own resource policy, and unlike most resource policies it is *mandatory*: a key is never accessible through IAM alone unless its policy delegates to the account. That is what the default statement in a key policy does — it names the owning account's root principal with `kms:*`, which is what makes IAM policies in that account effective for the key. Nothing about that statement extends to another account, and nothing about S3 allowing an action makes KMS allow one. This separation is the feature, not an accident: it lets a security team hold an independent veto over a dataset that a data team administers. ## The cross-account both-sides rule Cross-account access to a KMS key requires an allow in the key's account *and* an allow in the caller's account. Neither alone is sufficient: ```json { "Sid": "AllowPartnerRoleToDecrypt", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::222222222222:role/report-reader" }, "Action": ["kms:Decrypt", "kms:DescribeKey"], "Resource": "*", "Condition": { "StringEquals": { "kms:ViaService": "s3.eu-west-1.amazonaws.com" } } } ``` That statement goes in the key policy in account A. `Resource: "*"` in a key policy means "this key" — it is not a wildcard over your account. The `kms:ViaService` condition is worth adding: it restricts the grant so the key can only be used through S3 in that Region, meaning the partner role cannot call `Decrypt` directly against arbitrary ciphertext it has obtained by other means. In account B, the role still needs `kms:Decrypt` on the key ARN in its identity policy. ## Diagnosing it quickly The fastest signal is CloudTrail on the key's side: a `Decrypt` event with an `AccessDenied` error code and the caller's role in `userIdentity`. If you see the `Decrypt` denial, stop reading the bucket policy. If you see no KMS event at all, the failure is earlier and the S3 layer is the problem after all. Newer AWS error messages often name the key ARN in the denial text, which shortens this considerably — but do not rely on the message, rely on the trail. ## Writes, and the AWS managed key trap The same structure applies to writing. A caller that puts an object into a KMS-encrypted bucket needs `kms:GenerateDataKey` on the key, because the data key for the new object has to be produced; multipart uploads typically need `kms:Decrypt` as well. A role with only `kms:Decrypt` can read but not write, which produces a puzzling half-working state. The hard stop is the AWS managed key. If the data were encrypted with the service's AWS managed key rather than a customer managed key, no cross-account fix exists: those keys have a key policy you cannot edit, so an external principal can never be authorized. This is the single most practical reason to choose a customer managed key up front for any dataset that might ever be shared — you cannot retrofit the decision without re-encrypting the data. ## The generalization worth stating The same pattern recurs everywhere KMS sits under a service: sharing an encrypted EBS snapshot with another account requires sharing the snapshot *and* granting on the key; a Lambda function reading a KMS-encrypted secret needs the key permission on its execution role; a replication or backup role that copies encrypted data needs permission on both the source and destination keys. Whenever a request touches encrypted data, ask which principal KMS sees and whether the key policy names it.