Certified Security - Specialty

Sign Up Free or Log In to participate!

Adding the “root” user to the Keypolicy ?

at 4:29 the summary it says " the key policy – add the root user, not the individual iAM users/ roles "

Can someone please verify that i have understood this correct or not please; 

In the key policy of the CMK i would add the root user of the account that want’s access to it… but i am not using the root user to access that CMK key ? is it because to allow or authorise the entire account access and then IAM policy of the requester when they want to access the CMK key ? 

Can someone please verify this. 


4 Answers

Hi, yes that’s correct, there are 2 steps, 

1) In the CMK you need to allow the external ROOT account to have access

2) In the external account, you need to set up an IAM user or role with explicit permission to use the CMK

there is also a really good demo of this provided by the AWS knowledge center:


Colin Coleman

This is still not that clear – Do you HAVE to explicitly specify the arn of the key you wish to use from the 2nd account? My understanding that it is best practice to have least privilege in the 2nd account and specify the specific key but that any user with admin rights or even kms: actions on would have access

Ron D White

I’m not sure I fully understand your question, but here’s my best guess of the answer. In Faye’s example, there are two accounts, the primary account (the account that owns the CMK) and the external account (the one that needs to access the CMK). Within the primary account, I would need to create a key policy. In the principal section of the key policy, I have several options. If I use an arn similar to arn:aws:iam::444455556666:root, I’m saying that the root user or any IAM user or role within that external account can get access to my key (as long as there is a corresponding IAM policy in the external account). Instead of specifying the root arn of the external account, I can use least privilege and only specify a role or user from the external account similar to arn:aws:iam::444455556666:role/ExampleRole. In the primary account’s key policy, I wouldn’t specify the arn of the key in the resource section, I would use ‘*’. In the resource section of the external account, I will need to specify the arn of the key in the primary account like arn:aws:kms:us-west-2:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab.

Adam C

I don’t know if the KMS policy principals changed, but the documentation clearly says… "Instead of giving permission to the external account, you can specify particular external users and roles in the key policy . However, those users and roles cannot use the CMK until IAM administrators in the external account attach the proper IAM policies to their identities. The IAM policies can give permission to all or a subset of the external users and roles that are specified in the key policy. And they can allow all or a subset of the actions specified in the key policy."

The documentation is clear:

To give permission to use a CMK to users and roles in another account, you must use two different types of policies:

The key policy for the CMK must give the external account (or users and roles in the external account) permission to use the CMK. The key policy is in the account that owns the CMK.

You must attach IAM policies to IAM users and roles in the external account. These IAM policies delegate the permissions that are specified in the key policy.

Reference: https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-modifying-external-accounts.html

As such, you do not need to specify root. Any other user in the external account or Role can also be specified. Hope this clarifies.

I found this to be a helpful read, From KMS Best Practices Document:

Cross Account Sharing of Keys

Delegation of permissions to a CMK within AWS KMS can occur when you include the root

principal of a trusted account within the CMK key policy. The trusted account then has the

ability to further delegate these permissions to IAM users and roles within their own account

using IAM policies. While this approach may simplify the management of the key policy, it also

relies on the trusted accounts to ensure that the delegated permissions are correctly

managed. The other approach would be to explicitly manage permissions to all authorized

users using only the KMS key policy, which, in turn, could make the key policy complex and less

manageable. Regardless of the approach you take, the specific trust should be broken out on a

per key basis to ensure that you adhere to the least privilege model.

So to conclude both work!

I think the confusion is that when you use the console to add cross account permission, it adds it as "root" – since you’re giving the account permissions.  If you manually edit the key policy, you can specify specific users – so you an give JeffK permission, but not the entire account.  In either case though, the IAM policy in the second account must be updated correctly.

Sign In
Welcome Back!

Psst…this one if you’ve been moved to ACG!

Get Started
Who’s going to be learning?