Discussion : Change AWS cross account access grant model

[gene1wood]

Avoid granting access through the root user or, another category regarding granting permissions through the root user, for example, granting an S3 bucket policy that allow the root user of another aws account (and thus which allows everything on that other account to access the s3 bucket) its the same kind of issue, but for any access that is being granted through any method (not just through API keys)

This seems to go against https://infosec.mozilla.org/fundamentals/security_principles.html#do-not-allow-lateral-movement as AWS accounts tend to host more than one service. If the AWS account has a single service it would be "very normal" as in it would be fine indeed. When they host a variety of services you're effectively granting overly broad access (also usually called out as "fine grained access control" and "minimum necessary privileges")

The meat of this is: it's easy to end up with an unsafe configuration when all you want is "for things to work".

I think this could also be something about which cross-accounts privileges can be typically granted in a safe manner and how (as per initial comment "maybe an additional section".

[gdestuynder]

I feel like this is slightly misrepresented, or that there is some confusion - this is my actual comments:

Avoid granting access through the root user or, another category regarding granting permissions through the root user, for example, granting an S3 bucket policy that allow the root user of another aws account (and thus which allows everything on that other account to access the s3 bucket) its the same kind of issue, but for any access that is being granted through any method (not just through API keys)

This seems to go against https://infosec.mozilla.org/fundamentals/security_principles.html#do-not-allow-lateral-movement as AWS accounts tend to host more than one service. If the AWS account has a single service it would be "very normal" as in it would be fine indeed. When they host a variety of services you're effectively granting overly broad access (also usually called out as "fine grained access control" and "minimum necessary privileges")

The meat of this is: it's easy to end up with an unsafe configuration when all you want is "for things to work".

I think this could also be something about which cross-accounts privileges can be typically granted in a safe manner and how (as per initial comment "maybe an additional section".

[gene1wood]

Sorry about that, I've updated the body of the issue to your text. Here's what I had originally put in

Currently we configure the grantor account to grant rights to the entire grantee account (e.g. arn:aws:iam::371522382791:root) to assume a role in the grantor account. This sets the demarcation point between the grantor and grantee at the account level (as opposed to the IAM user or IAM role level).

Reasons for this choice are

• As the grantor has no ability to see inside the grantee's account, granting rights at the account level removes any need for the grantor to coordinate (outside of AWS) with the grantee to discover ARNs of IAM users or roles in the grantee's account
• The grantee has agency over what entities in their account (users, lambda functions, ec2 instances) should and should not have rights to AssumeRole into the grantor account. The grantee need not request the grantor make changes in the grantor account when the grantee wants to make a change. This prevents the grantee being restricted from, for example, redeploying a CloudFormation Stack with a role in it.
• The grantee can create roles which provide a mix of local account rights and delegated remote account rights (in the grantor's account) without having to coordinate with the grantor. More detail on this scenario at serverfault.

The downsides to this model are

• If the grantee does not manage the IAM policies they grant to their local users and roles well, for example, by granting local users or roles overly broad rights to sts:AssumeRole, local users and roles would be able to AssumeRole into the grantor account despite the grantee not actually wanting this.

• The conversation that spawned this request