In AWS, are S3 and IAM permissions different? - amazon-web-services

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

Related

Limiting S3 bucket access to users within one account

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.

Do IAM roles by default have access to resources , for which root account has access?

I am new to AWS and trying to understand IAM. I have a doubt which goes like this. for example there is a s3 bucket in account A and in it's resource policy another AWS account B (root user) is given permission for a certain set of actions. Now there are certain roles which are also present in account B. so if someone assumes those roles, will they also have access to that s3 bucket in account A or the Arn of that role needs to be explicitly mentioned in the resource policy of bucket even though it's root account already has access to it ?
When you want to provide access cross-accounts, that is - access to a resource in one account to a principal (in this example, a role) from another account - granting the access on the resource policy is not enough - and you also have to give access to that principal in a IAM policy in its account. When you place the root user of an account in a resource based policy - that indicates that access may be granted to any principal within that account (using a IAM policy on that account)
So, to answer your question - if the root user of account B is a principal to which access is granted in the bucket policy - you don’t have to indicate the ARN of any specific role - However, you do need to assign access to the role in a IAM policy in account B so assuming it would grant access to the bucket (I’m assuming there’s no mechanism denying the access of course)
When a user assumes a role, the user temporarily gives up his or her original permissions in exchange for those granted by the role. So to answer your question, in order for the bucket to be accessible to the role assumed by the root account (or any principle really), the ARN of the role needs to be explicitly mentioned in the bucket policy.

Iam permission vs resource permissions

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.

Aws IAM Roles vs Bucket Policies

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.

Use of s3:PutBucketPolicy

I was trying few things with aws s3 bucket policy and the documentation for put-bucket-policy says that the user should have PutBucketPolicy on the bucket and should be the owner.
I do not understand the use of PutBucketPolicy permission then.
Also is the bucket owner given a default PutBucketPolicy permission on his bucket?
http://docs.aws.amazon.com/AmazonS3/latest/API/RESTBucketPUTpolicy.html
The confusion here, I suspect, is related to the fact that users don't own buckets. The "owner" of a bucket is an individual AWS account.
You can't successfully grant PutBucketPolicy to any user in a different AWS account -- only your own account's user(s).
There's an illusion of circular logic here: How can I set a bucket policy... allowing myself to set the bucket policy... unless I am already able to set the bucket policy... which would make it unnecessary to set a bucket policy allowing me to set the bucket policy?
This is not as it seems: the problem is resolved by the fact that IAM user policies can grant a user permission to set the bucket policy, and the root account can do this by default -- which is why you should not use your root account credentials routinely: they are too privileged, if they fall into the wrong hands.