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.
Related
I want to be able to specify an iam group as the principal within my policy but i have been reading that you cannot specify an iam group as part of a resource based policy. I could potentially add in a list of iam users but then my policy would look really messy. What is the best approach to take if i cannot add an iam group arn as the principal within my policy.
If you cannot specify an IAM group as the principal in a resource-based policy, you have a few options:
Attach the policy directly to the IAM users: In this case, you would
need to specify each IAM user ARN in the policy. This approach can
quickly become messy and difficult to manage as the number of IAM
users grows.
Use an IAM role: An IAM role is a way to grant permissions to AWS
services or applications that run on AWS. You can create an IAM role
that can be assumed by IAM users or IAM groups. You can then specify
the IAM role in the policy instead of the IAM users or IAM groups.
This approach provides a cleaner and more scalable way to manage
permissions.
Use a service control policy (SCP): An SCP is a type of policy that
is used to set permissions boundaries for an AWS account. You can
use an SCP to allow or deny access to AWS services for IAM groups,
IAM users, or IAM roles. This allows you to manage permissions for
multiple users in a centralized and organized manner.
I would recommend option 2 or 3 as the best approach, as they provide a cleaner and more scalable way to manage permissions compared to specifying individual IAM user ARNs in the policy.
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!
After creating an S3 bucket in AWS - I want to find out how permissions for Read and Write access to the S3 bucket should be provided?
I am thinking that IAM user permissions and S3 bucket permissions are different. What I am mean is - an IAM user with no permissions on AWS can be granted access to the S3 bucket by just adding him to the S3 buckets permissions for read or read+write accordingly. And S3 permissions have got nothing to do with IAM permissions>
Is the above understanding correct? Please correct and elaborate if the above is wrong?
And S3 permissions have got nothing to do with IAM permissions
This is not the case. The effective permission for the bucket and its objects are union of the IAM identity based permissions (i.e. those attached to IAM user,role, group) plus bucket policies plus other permissions (SCPs, IAM boundaries), which I don't mention for simplicity.
By default bucket and objects are private. You can Allow access to them using either IAM policies, bucket policies or both. Effective permissions will be the union of all these individual permissions. This means that you can use bucket policy to grant access to object1 and IAM policy to grant access to object2 to the same IAM user. The said user will be able to access both objects.
This behavior changes when there is Deny, as deny always wins. So an IAM user can have Allow in IAM policies to a given bucket, but the bucket can have Deny for that user. The result will be Deny always.
Subsequently, all these mean that bucket polices and IAM permissions should be considered together and are inter-connected with each other. Thus, you can't say that "S3 permissions have got nothing to do with IAM permissions".
An IAM User has no permissions by default. If they wish to do anything via an authenticated API call, they must be granted permission to do so.
Even if an Amazon S3 bucket policy grants access to an IAM User, they cannot access content in Amazon S3 unless their IAM permissions allow them to make the associated API call (eg ListBuckets or GetObject).
Please note that I am referring to an authenticated API call, not an Anonymous HTTP requests via a web browser URL.
A Bucket Policy can grant "public access" by referring to "Principal": "*" (which means that even unauthenticated users can retrieve content via a URL), or it can grant access to specific IAM Users and IAM Roles. However, if that user/role doesn't have permission to call any S3 Actions, then they cannot access the bucket.
A Deny policy from either IAM or a Bucket Policy takes precedence over Allow. So, an IAM User with permission to access a bucket can be denied by the Bucket Policy, and vice versa.
In AWS IAM is the place to generate all policies and to assign them to users and/or roles.
As a general rule, AWS recommends using S3 bucket policies or IAM policies for access control.
"S3 ACLs are a legacy access control mechanism that predates IAM. However, if you already use S3 ACLs and you find them sufficient,
there is no need to change."
By default, a user/role is assuming the policies provided by an SCP which stands for "service control policy". It is very similar to the policies you probably faced but this is provided by the account level/or organization level.
Among all options to generate and assume policies, there is a logical "and" which mean that in case there is at least 1 "deny" among the policies it will restrict access of a user/role to a specific bucket for instance in your case
Suppose, I am AWS IAM user, is there any way so that I can check what resource permission has been given to me, using CLI or Console.
Unfortunately, there is no comprehensive tool for that. In IAM console you can only check your user's IAM profile or group permission you belong to.
But full set of privileges is a very complex thing to get. Apart from obvious IAM user or group permissions you can have:
IAM roles which you can assume,
resource policies which you are listed as a principle (e.g. bucket policy, kms key policy),
resource policies where a role you can assume is a principle,
cross-account permissions in IAM roles or resource policies,
AWS Organization level SCP permissions.
If the reason for asking this question is related to security, e.g., to check what resources were accessed by a compromised IAM user credentials, you suspend the credentials or delete the user. Also can inspect the CloudTrial history to check what resources a given IAM user accessed.
I have been reading a number of docs and watched number of videos, but I am still very confused about IAM Roles and Bucket policies. Here is what confuses me:
1) I create a bucket. At that time I can make it public or keep it private. If I make it public, then anyone, or any Application, can "see" the objects in the bucket. I think the permissions can be set to add/delete/get/list objects in the bucket. If this is the case, then why do I ever need to add any IAM Role for S3 buckets, or, add any Bucket policy (???)
2) At the time I create a bucket, can I give very specific permissions to only certain users/applications/EC2 instances etc to all or part of the bucket? e.g. App1 on EC2-X can access subfolder A in bucket B1.
3) Coming to IAM Roles, an EC2 role that gives full S3 access- what does it mean? Full access to any bucket? How can I restrict an app running on an EC2 to only certain buckets, with only certain restricted permissions (see #2) above)? Do all Apps on the EC2 have full access to all buckets? At the time of creating a bucket, can the permissions be so set that an IAM Role can be overruled?
4) Finally, what do Bucket Policies do in addition to the above IAM Roles? e.g is 'AllowS3FullAccess' a "Bucket Policy", or an "IAM Policy"? Why differentiate between types of policies- policies are just that- they define some permissions/rules on some objects/resources,as I see it.
Thanks for any clarifications.
- a newcomer to AWS
I think you are confusing permissions for resources with IAM entities.
i) There are resources (S3 bucket, EC2 instances etc.) owned by the AWS account and these resources can be accessed by IAM users, IAM roles or other AWS Services (can be from same or different account)
ii) We manage who can access and their permission level with policies
iii) Policies can be identity based (attached to IAM user/group/role) or resource based (attached to S3 bucket, SNS topic)
iv) Resource based policy will have a Principal element but the identity based policies will not have that (because the attached IAM entity is the Principal)
v) Permissions start from default deny, allow overrides the default deny and an explicit deny overrides any allow
vi) Final access will be determined by combination of all policies
To answer your questions:
1> We cannot add (or attach) an IAM role with an S3 bucket. If you want your bucket should be public (which is not recommended but need to do it till some extent if it's in use for static website), then you can keep it public
2> It is not possible while creating the bucket. You have to do it after creating the bucket via IAM and/or S3 bucket policy
3> If an IAM role has AmazonS3FullAccess, the role can (Effect:Allow) call any S3 API (s3:) for any S3 resource (Resource:) in your account (provided they don't have cross account access).
If multiple applications run on an instance with an IAM role attached and are using credentials provided by the role, their permission will be same.
4> I don't know where you got the reference AllowS3FullAccess but we cannot confirm unless we know the exact JSON. If it is attached to a bucket or has the Principal element, it is a bucket policy.
You can use IAM and Bucket policies based on your need. Usually bucket policies are used for cross account access or if you want to manage S3 permission policies in a single place.