I have a centralized CloudTrail bucket which contains the CloudTrail logs of multiple accounts. Is it possible to write a bucket policy which allows that account 123456789112 can only download logs from Awslogs/123456789112 and that account 456789012345can only download logs from Awslogs/456789012345etc ? I don't want to hardcode this for each account since I have a lot of accounts. Is there a way to do this?
AWS IAM policies (and bucket policies) support a few policy variables that you can use as dynamic values such as aws:SourceIp, however account ID is not one of them. There is a aws:userid variable but it's the account ID only for the root user, for other principals like IAM user/role it is the user/role name. Technically if you used the AWS root user to access this bucket, you could use the userid variable in the Resource element to achieve what you want but it is strongly recommended not to use the root user for such everyday tasks (AWS recommendation).
There are also policy condition keys like aws:PrincipalAccount but without a relevant policy variable these cannot be used to dynamically compare the requesting account ID with the resource. There are no other IAM feature that could be used to achieve this.
I don't know your exact environment but a few things to consider:
I'd recommend to explicitly list the allowed principal ARNs anyway because even if you have many accounts, you should allow only specific IAM users/roles to read the bucket to follow the least privilege principle. Granting access based on account ID would allow all users/roles in that account to read these files and not just specific services. (unless this is the objective)
since this is a cross-account access (principal in account A wants to read from the bucket located in account B), you will need to allow this access on both sides, both in the requester's IAM policy and the target bucket's policy. Just a heads up. More info on AWS.
I would consider using Terraform to simplify the management of these resources
Hope this helps, let me know if you have more questions!
Related
I have an IAM user that has full S3 access (i.e. can perform any S3 actions on any S3 resource within the AWS account). This user has created a bucket and put some files in it. The bucket has a policy which just contains an Allow rule that grants access to a different IAM user, in the same AWS account. Public access is turned off for the bucket.
Should the first user be able to access objects in this bucket? If so, is that because they created the bucket, or because they're in the account that owns the bucket? Is it possible to limit access to a bucket for users within the same AWS account?
S3 is one of the few services with resource policies, in this case they are called bucket policies.
A user in the same account has access to a (S3) resource if
nothing explicitly denies the access AND
either the bucket policy grants access OR the user / entity has a policy attached that grants access
If you wanted to restrict a bucket to a single user / entity you would
need to write a bucket policy that specifies that using a Deny statement for every user except the target one AND
either add a statement to the bucket policy or a policy attached to the user / entity granting access to the bucket.
The standard doc for understanding policy evaluation logic is this. There are other, more complicated ways to achieve your goal using e.g. permission boundaries and SCPs but they are probably overkill in your situation.
I'm tasked with creating an IAM policy in AWS which grants a user access to all s3 objects in all s3 buckets within a specific account.
However, because s3 bucket names are globally unique, and there being no region or account element in an s3 ARN, it would appear that there's no way to grant access to all s3 objects in one specific account. I must grant it either to specific buckets, or all buckets in all accounts. Is that true? There must be a work around.
I want something like:
"Resource": "arn:aws:s3::<accountid>:*"
not:
"Resource": "arn:aws:s3:::*"
Anyone see any solution? I did already read this other related discussion
You can add conditions to S3 resource policies, one of them is s3:ResourceAccount which should allow you to use the ARN arn:aws:s3:::* but still restrict access to only buckets in your account.
https://aws.amazon.com/blogs/storage/limit-access-to-amazon-s3-buckets-owned-by-specific-aws-accounts/
Usually there is Compute Engine default service account that is created automatically by GCP, this account is used for example by VM agents to access different resources across GCP and by default has role/editor permissions.
Suppose I want to create GCS bucket that can only be accessed by this default service account and no one else. I've looked into ACLs and tried to add an ACL to the bucket with this default service account email but it didn't really work.
I realized that I can still access bucket and objects in this bucket from other accounts that have for example storage bucket read and storage object read permissions and I'm not sure what I did wrong (maybe some default ACLs are present?).
My questions are:
Is it possible to limit access to just that default account? In that case who will not be able to access it?
What would be the best way to do it? (would appreciate a lot an example using Storage API)
There are still roles such as role/StorageAdmin, and actually no matter what ACLs will be put on the bucket I could still access it if I had this role (or higher role such as owner) right?
Thanks!
I recommend you not to use ACL (and Google also). It's better to switch the bucket in uniform IAM policy.
There are 2 bad side of ACL:
New created files aren't ACL and you need to set it everytime that you create a ne file
It's difficult to know who has and who hasn't access with ACL. IAM service is better for auditing.
When you switch to Uniform IAM access, Owner, Viewer, and Editor role no longer have access to buckets (the role/storage.admin isn't included in this primitive role). It could solve in one click all the unwanted access. Else, as John said, remove all the IAM permission on the bucket and the project that have access to the bucket except your service account.
You can control access to buckets and objects using Cloud IAM and ACLs.
For example grant the service account WRITE (R: READ,W: WRITE,O: OWNER) access to the bucket using ACLs:
gsutil acl ch -u service-account#project.iam.gserviceaccount.com:W gs://my-bucket
To remove access of service account from the bucket:
gsutil acl ch -d service-account#project.iam.gserviceaccount.com gs://my-bucket
If There are roles such as role/StorageAdmin in the IAM identities (project level), they will have access to all the GCS resources of the project. You might have to change the permission to avoid them having access.
In aws an IAm user can be given say read access to an s3 bucket using permissions. Similarly a policy (permission) can be attached to an s3 bucket to allow certain user access to that s3 bucket. My question is why there are two ways to do it. Should you define both? What if user 1 is allowed to access an s3 folder but IAM policy at resource level allows user 2 access to it. Who wins in this situation? What is the order of evaluation?
Typically:
To grant Amazon S3 access to a specific user, it is best to place the policy on the IAM User (or an IAM Group container IAM Users).
To grant public access, place a Bucket Policy on the bucket permitting anonymous access.
Yes, it is possible to grant individual access via a Bucket Policy, but this can become quite messy if multiple users are added this way.
The user will be permitted to access the bucket as long as either of these methods are used. However, any Deny policy will always override an Allow policy from either source.
How do ECR policies differ from IAM policies?
The language around the ECR policies seem to indicate it is similar to the S3 bucket policy.
Does it allow you to grant access not using IAM?
If I wanted to grant another account access to registry can I use an ECR policy or do I still need a cross account role?
The language around the ECR policies seem to indicate it is similar to the S3 bucket policy.
Yep, they are. Both ECR repository policies and S3 bucket policies control permissions of specific resources rather than permissions of principals (identities). In the case of ECR, it lets you define permissions for a specific repository.
Does it allow you to grant access not using IAM?
Sort of. You need both an IAM policy and a repository policy to express some kinds of permissions. For example, an IAM policy on a user might have permissions like ecr:* in order to allow the user to make API calls to ECR and then a repository policy might grant control over a particular repository.
If I wanted to grant another account access to registry can I use an ECR policy or do I still need a cross account role?
This is one of the primary use-cases of repository policies. A user in account A might have permission to make ECR API calls with ecr:* in the IAM policy. A repository in account B could then grant cross-account access to account A, at which point the account A user does not need to assume a cross-account role in order to access the repository.
According the documentation, you can allow cross-account access to your ECR with just the repo policy:
For Principal, choose the scope of users to apply the policy statement to.
You can apply the statement to all authenticated AWS users by selecting the Everybody check box.
You can apply the statement to all users under specific AWS accounts by listing those account numbers (for example, 111122223333) in the AWS account number(s) field.
You can apply the statement to roles or users under your AWS account by checking the roles or users under the All IAM entities list and choosing >> Add to move them to the Selected IAM entities list.
So you don't need to setup cross-account role assumption, but I imagine you would have to grant the appropriate permissions to the users/groups/roles in the remote account to allow them to talk out to your ECR.