Amazon Web Services Question posted in
The official Amazon Web Services documentation can be found here.

Amazon web services – Best Practice for Granting S3 Bucket Access to Friend: External AWS Account or IAM User?

I have an S3 bucket in my AWS account, and I want to grant access to my friend, who has his own AWS account. I’m trying to determine the best practice for providing access to the S3 bucket. Should I:

a. Grant access to his AWS account directly to the S3 bucket?

b. Create a user in my AWS account with permissions restricted only to the S3 bucket and share those credentials with him?

I want to ensure security and follow AWS best practices. What are the potential risks and benefits of each approach? Are there any considerations or caveats that I should be aware of when choosing between these options? Any insights or experiences shared would be greatly appreciated!

Tags:

2

Answers


  1. 0

    Using a principal under his account control

    These options don’t control the permissions on the user or role accessing the bucket, only the permissions in the bucket resource policy. In both cases, he’s responsible for the configuration of IAM permissions and you only own the bucket profile.

    Also in both cases, the user continues to be part of his account. If he’s going to be interacting with other resources in his account while he also interacts with your bucket, these are potentially good choices as he’ll need to manage IAM permissions for those other resources.

    MFA in both these cases can be required in the bucket policy.

    Granting access to his account

    This is best when you don’t want to have to be involved in creating or managing the users and other roles that should be able to access the bucket. For example, if your friend is going to be writing lambda functions that run in his account and will be operating in your bucket. Granting account access allows him to allow access to the bucket to roles and iam users at his discretion without your involvement.

    Granting access to a role or user in his account

    this is a middle ground where you want to restrict access to a particular User or Role in his account. Using a specific user or role principal will only allow that particular user or role; other users or roles in the account will not be allowed.

    Giving him access to a principal in your account

    In these cases you control the principal yourself. You are responsible for the permissions. If he’s likely to interact with other resources in your account while he interacts with your s3 bucket, these are good options because then he can use the same role / user for all that.

    Granting access to a role in your account

    Another option is to built a role in your account that is granted access to the bucket and allow his account or a specific user or role in his account to assume the role in the Assume Role Policy Document.

    He’d assume the role from an existing role / user in his account, then use the resulting short term credentials (the secret access key, the access key Id, and the session token, the last of which only exists for temporary credentials) to interact with resources in your account.

    MFA can be required to assume the role.

    The role can also be used at the console with the console’s "switch role" function.

    Creating an IAM User in your account.

    This is pretty much the same as granting access to a role, but worse because it requires you to generate and deliver long term credentials that don’t automatically expire. Adding multi factor authentication is messy to configure and inconvenient to require in policies. In addition to configuring MFA authentication to the web console (if console access is desired), the user’s IAM policy or the bucket policy must require MFA to protect long term user credentials from being used without MFA, but that requires the IAM user to generate a session token, which is about the same process as assuming a role.

    I would avoid creating IAM users whenever possible. Let the user manage their own IAM user in their account instead.

    Login or Signup to reply.
  2. 0

    Since you only want to give your friend access to an Amazon S3 bucket, the simplest method would be to add a Bucket Policy that grants access to their AWS Account.

    It would look something like:

    {
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": { "AWS": "arn:aws:iam::111122223333:root" },
            "Action": [
                "s3:GetObject",
                "s3:PutObject",
                "s3:ListBucket"
            ],
            "Resource": [
                 "arn:aws:s3:::BUCKET-NAME",
                 "arn:aws:s3:::BUCKET-NAME/*",
            ]
        }
    ]
}

    Some things to note:

    • It is granting access to the ‘root’ of their account. This means that your bucket is ‘trusting’ their account. However, they also need permissions to be granted in their account to access your bucket. If they have s3:* permissions on all buckets, then this is sufficient. You could instead specify their IAM User ARN, but then only that specific IAM User would be permitted to access the bucket.
    • The policy is only granting specific actions (read, write, list) — you can add actions as desired.
    • The Resource section mentions the bucket and the contents of the bucket separately. This is because the ListBucket action operates on the bucket while the GetObject operation operates on the contents of the bucket.

    If your friend was accessing more services than just an S3 bucket, then it would be worth considering alternative ways of using your account (eg an IAM Role). But since it is just one bucket, a simple Bucket Policy is the simplest method.

    Login or Signup to reply.
Please signup or login to give your own answer.

Back To Top
Search