Access AWS S3 bucket from another account using roles

Question

First things first, my question is very similar to this one, but since I couldn't find a "Me too!" link, and it's been unanswered since Jan 1, I thought I would ask here. Please let me know if that was the wrong thing to do.

OK, so here is my problem. I have two AWS accounts, lets call them Prod and Audit. In Prod, I have many EC2 instances, all with their own specific IAM Roles already defined. In Audit, I have a number of S3 buckets.

What I need to be able to do is, using only IAM Roles, access the S3 buckets in the Audit account from specific machines, using specific IAM Roles, in the Prod account.

I've seen many answers talking about Group Policies, Resource Policies and having IAM users assume roles, etc, but as I said, I am using IAM Roles on EC2 instances, there are no groups, users, etc.

I don't want to have credentials anywhere on any of the instances, ala AWS Best Practices.

So is this possible? Is there some other secure way of doing this, without involving users or credentials? Any and all help greatly appreciated, thanks!

Note:

The application running on the Prod EC2 instances that I am attempting to allow access to the Audit S3 buckets is Logstash. I have confirmed the setup works when pushing logs to Prod S3 buckets, just not Audit ones. I have also tried using an S3 Bucket Policy with no success there either.

The S3 Bucket Policy I added is as follows:

{
"Version": "2012-10-17",
"Statement": [
    {
        "Sid": "CrossAccountPolicy",
        "Effect": "Allow",
        "Principal": {
            "AWS": "arn:aws:iam::<Prod Account ID>:root"
        },
        "Action": "s3:*",
        "Resource": [
            "arn:aws:s3:::logstash.prod.logs",
            "arn:aws:s3:::logstash.prod.logs/*"
        ]
    }
  ]
}

The Inline Policy attached to the IAM Role for the Prod EC2 instance:

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Action": "sts:AssumeRole",
    "Resource": "arn:aws:iam::<Audit Account ID>:role/ProdLogstashPush"
  }
}

The Policy attached to the IAM Role in the Audit account:

{
"Version": "2012-10-17",
"Statement": [
    {
        "Effect": "Allow",
        "Action": [
            "s3:*"
        ],
        "Resource": [
            "arn:aws:s3:::logstash.prod.logs/*",
            "arn:aws:s3:::logstash.prod.logs"
        ]
    }
  ]
}

I am currently trying out fluentd/td-agent because I think it allows for sts:AssumeRole, which in theory would allow this setup to work.

Dean

Answer 1

Yes, it's possible. I believe you can do this using either roles or an S3 bucket policy. For reference, see How IAM Roles Differ from Resource-based Policies, which uses a similar S3 scenario as an example.

Using Roles

1. In the Audit account, set up a cross-account role

   a.) Add a policy granting appropriate read/write access to the S3 buckets.

   b.) Add a trust policy specifying the Prod account.

2. In the Prod account, create or modify your EC2 roles (instance profiles)

   a.) Allow your EC2 instances to call AssumeRole for the Audit account's shared role

   b.) Allow your EC2 instances to write to S3 (specific Audit bucket or any bucket)

3. In your application, call sts:AssumeRole to get temporary credentials to write to the Audit account's S3 bucket. The various AWS SDKs all have fairly easy but slightly different ways to create new temporary credentials from a role.

Using S3 Bucket Policy

You can also do this through a resource policy on the Audit account's S3 buckets, granting access to the Prod account, but not specifying a particular user in the Prod account. Granting Cross-Account Permissions to Upload Objects While Ensuring the Bucket Owner Has Full Control has an example bucket policy for a similar example. An advantage of this approach is that your Prod account roles would be able to write directly to the bucket without having to get temporary credentials from sts:AssumeRole first. There are two things to do:

1. In the Audit account, set the S3 bucket policies to allow the Prod account access. Your S3 bucket policy above looks OK to me.

2. In the Prod account, allow the EC2 instance profile role to write to S3.

You can try the AmazonS3FullAccess managed policy for debugging, but you will probably want to eventually specify resources like you have in your policies.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:*",
      "Resource": "*"
    }
  ]
}