Is it possible to expose Amazon S3 account bucket (shared by ACL setings) to the users setup using new Amazon AIM API under different account?
I'm able to create working IAM policy when related to the users and objects belonging to a single account. But as it seems this no longer works when two different accounts are involved - despite account 2 being able to access account 1's bucket directly.
Sample policy is:
{
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:*"
],
"Resource": [
"arn:aws:s3:::test1234.doom",
"arn:aws:s3:::test.doom"
],
"Condition": {}
}
]
}
In this case AIM user is able to list test.doom bucket (owned by the same AWS account) and not 'test1234.doom' bucket (owned by the different AWS account). This is despite one account having correct ACL permissions to access the other bucket.
It looks like this can't be done.
http://aws.amazon.com/iam/faqs/#Will_users_be_able_to_access_data_controlled_by_AWS_Accounts_other_than_the_account_under_which_they_are_defined
Although it looks like in the future they might be allowed to create data under another account.
http://aws.amazon.com/iam/faqs/#Will_users_be_able_to_create_data_under_AWS_Accounts_other_than_the_account_under_which_they_are_defined
Related
How do i grant a customer read/write access to a specific S3 bucket in my AWS account without giving them access to any other buckets or resources?
They should be able to access this bucket from a powershell script in some ec2 instance of theirs.
found this policy
{
"Version": "2012-10-17",
"Id": "PolicyForBucketX",
"Statement": [
{
"Sid": "AllowCustomerRWAccess",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:root"
},
"Action": [
"s3:PutObject",
"s3:GetObject",
"s3:DeleteObject"
],
"Resource": "arn:aws:s3:::bucket-x/*"
}
]
}
Giving customer AWS access to my AWS's specific s3 bucket?
with this, they might be able to access s3 via their access key in powershell. However they might not be using access key hardcoded to use s3. They might be using STS with instance role for the ec2 to access their s3 resources.
Would this work still? Would they then have to add my bucket x into their instance role permissions buckets?
Any better way? I might/might not have details of their AWS resource IDs.
With Bucket policy and IAM policy (either for user or a role) you can restrict users/resources based on the requirement.
I agree with Maurice here as extent of restriction would heavily depend on what you specifically want to do.
You can also use CloudFront and restrict access to your bucket objects for users not managed by IAM.
In general you should think of access as two part task. On the side of the resource, you grant permissions to a resource, in this case you are doing that for a specific bucket (resource) for a cross account (principal). You're done.
Now, the identity that will access it will also needs permissions given to them by the account administrator (root) the same way. I.e. grant the user/role the permissions to
"s3:PutObject",
"s3:GetObject",
"s3:DeleteObject"
If they would like to use an instance which has AWS PowerShell installed, they can create an instance profile / role that has the above permissions, and they will be able to run the commands and access your bucket. That's right way to do it.
Regardless of how they access to the instance, when they make the api call from the instance to your bucket, AWS will first check to see if the caller (which could be instance profile or a role they assumed) has permissions to these actions (customer setup). It will then be checked to see if the resource allows these actions (your setup).
I have created an S3 bucket which we will call mytest-bucket where I am trying to grant access to the bucket and its objects to an IAM user at a different company, not within my organization. The user, which we call Bob has given me their account ID, IAM username, and canonical ID. I've done the following to attempt to grant Bob access:
1) I have set the bucket policy for mytest-bucket as such:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::111111111111:root",
"arn:aws:iam::111111111111:user/Bob"
]
},
"Action": [
"s3:*",
"s3:ListBucket",
"s3:GetObject",
"s3:GetObjectAcl",
"s3:PutObject",
"s3:PutObjectAcl"
],
"Resource": [
"arn:aws:s3:::mytest-bucket",
"arn:aws:s3:::mytest-bucket/*"
]
}
]
}
2) I have set my Individual Block Public Access settings for this bucket to the following:
3) I have also granted List, Write ACL permissions to the External account using the Canonical ID provided, as well as Read, Write Bucket ACL permissions. For object ownership, I have ACLs are enabled and can be used to grand access to this bucket and its objects.
Yet, still, Bob is unable to both 1) see the bucket listed under their account, 2) access any objects or the bucket itself due to Access Denied error.
Is there something I can change in the above configuration to provide Bob access to this one bucket and it's objects?
How can I help them get access?
Edit: Bob will not be uploading objects, but only reading and downloading objects from this bucket.
You say that "bob is unable to see the bucket listed under their account". This is normal -- the bucket does not belong to his account, so it will not be listed when he uses the S3 management console. However, Bob should be able to access it when using the AWS CLI, such as:
aws s3 ls s3://mytest-bucket
If Bob really wants to see it in the console, he can 'cheat' by using a URL that will show the bucket, but Bob would need to paste the URL directly rather than going through the bucket hierarchy. To demonstrate, here is a URL that would normally show a bucket:
https://us-east-1.console.aws.amazon.com/s3/buckets/mytest-bucket
You can change the bucket name at the end to 'jump' directly to a desired bucket.
I'm trying to grant access to S3 bucket to other account using S3 UI:
Permissions -> Access Control List -> Access for other AWS accounts
I know canonical id for account I want to grant permissions. It is 161 char code. When I'm trying to add It I'm getting next error:
I'm pretty sure I'm using the correct ID because it says says Canonical user ID (for Amazon S3)
What is wrong?
If you wish to grant bucket access to another AWS Account, I would recommend using a Bucket Policy. This allows the user(s) in the other account to use their normal credentials to access the bucket.
Here is a sample bucket policy that grants access to a specific user in another AWS account:
{
"Version": "2012-10-17",
"Statement": [
{
"Action": [
"s3:GetObject",
"s3:ListBucket"
],
"Effect": "Allow",
"Resource": [
"arn:aws:s3:::my-bucket",
"arn:aws:s3:::my-bucket/*"
],
"Principal": {
"AWS": [
"arn:aws:iam::ACCOUNT-ID:user/foo"
]
}
}
]
}
You are probably using the wrong id. Please have a look at this document to find out how to retrieve the one that you need here: AWS account identifiers - AWS General Reference
Having that said, in most cases it would be better to not use access control list but access S3 via cross-account roles instead. To learn more, please have a look at: Provide Cross-Account Access to Objects In S3 Buckets
My company has an organization set up in AWS (CompanyA as example). Each team has an account joined to this organization (HR, ProductA, ProductB, ect..). We in ProductA are attempting to grant read-only access to an S3 bucket which serves as a yum repository we own to anyone under this organization from their ec2 instance without auth (yum commands works out of box)
Some items we evaluated:
https://github.com/rmela/yum-s3-plugin -> This would go along with user principal access, users would need to add their keys to pull from the repo
http://parthicloud.com/how-to-access-s3-bucket-from-application-on-amazon-ec2-without-access-credentials/ -> Great tutorial for inside your own account, ec2 instances need to be brought up with a IAM policy to allow access to bucket.
Add a condition to the bucket policy listing your AWS Organization, and allow all principals access. See AWS Global Condition Context Keys, search for aws:PrincipalOrgID. "When you add and remove accounts, policies that include aws:PrincipalOrgID automatically include the correct accounts and don't require manual updating."
The Action and Resource sections in the example below should be the same as for your current policy that lists all the AWS accounts in your organization.
{
"Version": "2012-10-17",
"Statement": {
"Sid": "AllowOrganizationToReadYumBucket",
"Effect": "Allow",
"Principal": "*",
"Action": [
"s3:GetObject",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::your-yum-bucket",
"arn:aws:s3:::your-yum-bucket/*"
],
"Condition": {
"StringEquals": {"aws:PrincipalOrgID":["o-xxxxxxxxxxx"]}
}
}
}
It is not possible for an Amazon S3 bucket policy to refer to a group of accounts in an AWS Organization.
Your bucket policy would need to list permissions for each account individually. For example:
"Principal":{"AWS":"arn:aws:iam::ACCOUNT-NUMBER:user/*"}
For security reasons, we have a pre-prod and a prod AWS account. We're now beginning to use IAM Roles for S3 access to js/css files through django-storage / boto.
While this is working correctly on a per account basis, now a need has risen where the QA instance needs to access one S3 bucket on a the prod account.
Is there a way to have one IAM role that can grant access to the pre-prod And prod S3 buckets? As I'm writing it seems impossible, but it never hearts to ask!
Here's the AWS doc on this: http://docs.aws.amazon.com/AmazonS3/latest/dev/example-walkthroughs-managing-access-example2.html
Essentially, you have to delegate permissions to one account from the other account using the Principal block of your Bucket's IAM policy, and then set up your IAM user in the second account as normal.
Example bucket policy:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Example permissions",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::<Account-ID>:root"
},
"Action": [
"s3:GetBucketLocation",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::<bucket-name>"
]
}
]
}
This works well for read-only access, but there can be issues with write access. Primarily, the account writing the object will still be the owner of that object. When dealing with Write permissions, you'll usually want to make sure the account owning the bucket still has the ability to access objects written by the other account, which requires the object to be written with a particular header: x-amz-grant-full-control
You can set up your bucket policy so that the bucket will not accept cross-account objects that do not supply this header. There's an example of that at the bottom of this page: http://docs.aws.amazon.com/AmazonS3/latest/dev/example-bucket-policies.html (under "Granting Cross-Account Permissions to Upload Objects While Ensuring the Bucket Owner Has Full Control")
This makes use of a conditional Deny clause in the bucket policy, like so:
{
"Sid":"112",
"Effect":"Deny",
"Principal":{"AWS":"1111111111" },
"Action":"s3:PutObject",
"Resource":"arn:aws:s3:::examplebucket/*",
"Condition": {
"StringNotEquals": {"s3:x-amz-grant-full-control":["emailAddress=xyz#amazon.com"]}
}
}
I generally avoid cross-account object writes, myself...they are quite fiddly to set up.