Cross-account authorization

Lesson 4 of 5 in Policy Evaluation.

Cross-account trust established the rule: both accounts must allow the request, independently. This lesson puts it to work across the services the exam actually uses, and walks one scenario end to end — because real cross-account questions are never about one policy. They stack three or four, and the denial comes from whichever one you did not check.

The scenario to hold in mind: an analytics account must read encrypted objects from a data account's bucket, write results back, and drop a completion message on a queue the data account owns. That single sentence requires a bucket policy, a KMS key policy, a queue policy, and an identity policy — and getting any one of them wrong produces the same AccessDenied.

AWS KMS deserves its own paragraph, because it is the one service whose resource policy is mandatory and the one that most often explains a cross-account failure.

Every KMS key has a key policy, and the default one contains this statement:

{
  "Sid": "Enable IAM User Permissions",
  "Effect": "Allow",
  "Principal": { "AWS": "arn:aws:iam::111122223333:root" },
  "Action": "kms:*",
  "Resource": "*"
}

Read it carefully: the principal is the account, not the root user, and this statement is what delegates key authorization to IAM for principals in the key's own account. Remove or narrow it and identity policies stop working for the key, however permissive they are. That is the inversion to remember — for most services an identity policy is sufficient and a resource policy optional; for KMS the key policy is required.

Three related mechanisms:

Grants are scoped, revocable delegations created programmatically, usually by an AWS service for the life of one operation (attaching an encrypted EBS volume, taking an RDS snapshot). The documented way to permit that without permitting humans to create arbitrary grants is a key-policy condition on kms:GrantIsForAWSResource being true.
kms:ViaService restricts key use to requests arriving through a named service — "this key may only be used by S3 in this account", so a stolen credential cannot call Decrypt directly.
kms:CallerAccount lets one key-policy statement cover every principal in a given account, which is how cross-account key sharing is usually written.

Cross-account mechanisms by service — what the exam expects you to reach for
Service	Resource policy?	The cross-account detail
Amazon S3	Bucket policy; also access point policies	Both sides must allow. Object ownership matters: with ACLs disabled (the modern default) the bucket owner owns all objects, which removes the old "uploaded by another account, unreadable by the owner" problem. Access points give each consumer its own named endpoint and policy, so a 20-team bucket policy becomes 20 small ones.
AWS KMS	Key policy — mandatory	The key policy must allow the external principal and that principal needs the action in its identity policy. IAM alone never suffices. Grants, `kms:ViaService`, and `kms:GrantIsForAWSResource` round it out.
Amazon SQS / SNS	Queue policy / topic policy	Classic resource-policy services. For a service publishing on your behalf, add `aws:SourceArn` and `aws:SourceAccount` to prevent a confused deputy.
AWS Lambda	Function resource policy (added with `AddPermission`)	How another account or an AWS service is permitted to invoke the function. Note `lambda:AddPermission` in an identity policy lets a principal rewrite that policy — treat it as a sensitive action.
IAM roles	Role trust policy	The universal fallback: works for every service, including those with no resource policy, and makes the actions appear as the owning account’s own role in its CloudTrail.
AWS Secrets Manager	Secret resource policy	Cross-account secret access needs the secret policy and the KMS key policy, because a secret encrypted with a customer managed key cannot be read without the key.
AWS RAM	Managed permissions on the share	Resource Access Manager shares specific resource types — subnets, Transit Gateways, Private CA, License Manager configurations, Route 53 Resolver rules — with accounts, OUs, or the whole organization. The consumer still needs identity-policy permissions to use what was shared; sharing is not granting.
Services with no resource policy	None (EC2, RDS, Systems Manager, CloudWatch metrics)	A role is the only path. A question offering "attach a resource policy to the EC2 instance" is offering something that does not exist.

The cross-account diagnosis order

When a cross-account call fails, check in this order — it is roughly cheapest-first and catches the common cases early:

The caller's identity policy — does it allow the action on that exact ARN? (The most commonly forgotten half of the both-sides rule.)
The resource policy in the owning account — does it name this principal, and does any condition on it hold?
The KMS key policy, if anything is encrypted with a customer managed key. This is the usual answer when S3 or Secrets Manager "nearly" works.
Organization policies — an SCP on the caller's account, an RCP on the resource's account.
VPC endpoint policies, if the traffic goes through one.

And then the sentence worth repeating: the error is identical for all five. AccessDenied is not a diagnosis.

Key terms: KMS key policy, KMS grant, Resource-based policy, Role trust policy, aws:PrincipalOrgID

Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.