How to write an AWS policy which can be assumed by other accounts but gives different permissions depending on which account is assuming the role?

Question

I have 2 AWS accounts with ID 111111 and 222222 and I am trying to attempt the following

Both accounts should access AWS by assuming the same role
The assumed role gives each access to read/write an s3 bucket on account 111111
Account 111111 can write anywhere but /production/*
Account 222222 can write only to /production/*

I created the s3 bucket called myBucket on account 111111 and set the following bucket policy in it

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "",
            "Effect": "Deny",
            "NotPrincipal": {
                "AWS": "arn:aws:iam::222222:root"
            },
            "Action": [
                "s3:PutObject",
                "s3:GetObjectVersion",
                "s3:GetObject",
                "s3:DeleteObject"
            ],
            "Resource": "arn:aws:s3:::myBucket/production/*"
        },
        {
            "Sid": "",
            "Effect": "Allow",
            "Principal": {
                "AWS": [
                    "arn:aws:iam::111111:root",
                    "arn:aws:iam::222222:root"
                ]
            },
            "Action": [
                "s3:ListBucket",
                "s3:GetBucketLocation"
            ],
            "Resource": "arn:aws:s3:::myBucket"
        }
    ]
}

Then I create a user on account 111111 with the following IAM Policy

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "",
            "Effect": "Allow",
            "Action": [
                "s3:RestoreObject",
                "s3:PutObjectAcl",
                "s3:PutObject",
                "s3:GetObject",
                "s3:DeleteObject"
            ],
            "Resource": "arn:aws:s3:::myBucket/*"
        },
        {
            "Sid": "",
            "Effect": "Allow",
            "Action": "s3:ListBucket",
            "Resource": "arn:aws:s3:::myBucket"
        }
    ]
}

The above should be sufficient for account 111111 to assume the role and be able to write to /myBucket/* except /myBucket/production/* and this is working fine.

The problem becomes when account 222222 assumes the role. It is able to do the same thing as account 111111 (Write to /myBucket/* except /myBucket/production/*) which is not the intention.

I suspect the issue here is once the account 222222 assumes the role, it appears as coming from that same account but I am uncertain.

How does one identify the source account in a case like this so I can set policies on account 222222 even though it has assumed a role on account 111111?

That second code snippet contradicts the first one by allowing everything under `myBucket`. You say that second one is for allowing 1111111 to assume policy, but it just gives unrestricted access to the bucket. — kichik, Jan 10 '18 at 19:31
Actually the second one is on a user and while it does give unrestricted access to that user on account 111111, AWS DENY policies always have precedence over ALLOW so that user cannot write under `/myBucket/production/*` — Alexandre Thenorio, Jan 11 '18 at 08:12

score 0 · Answer 1 · answered Jan 10 '18 at 21:42

0

Yes, once the role has been assumed, who or what assumes that role is irrelevant. All further Auth is based on the role and the role is in account 1111111.

I sense an XY problem here. Your requirements seem odd. Why are you wanting both accounts to assume the role. It’s like saying you want 2 people to have 2 people share the key but have locks behave differently depending on who is holding the key. The far more logical solution is to give each person there own key.

answered Jan 10 '18 at 21:42

Nath

748
4
16

The reason is that the application calling the API is going to be run on 2 different machines on 2 different AWS accounts and the application is not so flexible as to allow something like environment variables to configure whether the application should assume a role (when running on account 222222) or not (when running on account 111111) so the simplest option would be to have the application always assume the role and steer access on AWS depending on the source of the call. Does that make any sense? – Alexandre Thenorio Jan 11 '18 at 08:10

How to write an AWS policy which can be assumed by other accounts but gives different permissions depending on which account is assuming the role?

1 Answers1