Is there a way to use an AWS IAM policy to make S3 files public?
I realize that S3 has ACL permissions as well as Bucket Policies. If those are my only options then I am certainly willing to use those options. However, I would prefer to use IAM policies to control permissions if at all possible.
As I understand them, IAM policies affect user, groups, and roles. This being the case, it seems that "anonymous user" (aka the general unauthenticated public) is not an option in IAM policy making.
Is it even possible (or appropriate) to use IAM to make S3 files public?
You have almost answered your own question. IAM can dictate only the users with AWS account. Anonymous users do not fall under its landscape.
For making S3 files publicly accessible, you have to set the permissions on S3 level only.
Related
I have all my user permission needs covered using IAM, therefore I keep my bucket policy sections completely empty.
I was wondering if this is a good practice and if it raises any potential issues from any perspective.
Perhaps there is some configuration that is good to set as default?
Just double checking.
Typically:
When you want to grant 'public' access to an Amazon S3 bucket, use a Bucket Policy
When you want to grant access to specific IAM Users, attach an IAM policy to the IAM Users or IAM Groups
It sounds like your needs are satisfied via IAM policies, so that's perfectly good (and actually preferable!).
For using s3 bucket which IAM policy need to be created AdministratorAccess or AmazonS3FullAccess or both together?
You can use amazons3full access but I would suggest you to create a custom Iam policy which gives access to just that particular bucket .
Refer: https://aws.amazon.com/blogs/security/writing-iam-policies-how-to-grant-access-to-an-amazon-s3-bucket/
If you are the only person using the AWS Account, then Administrator permissions are fine.
If, however, multiple people are using the account, then you should consider how to manage security of the AWS Account and the resources within the account.
Only grant Admin permissions to people who are responsible for all systems. It has "All Access" (including Amazon S3), so it can be quite dangerous.
Similarly, granting AmazonS3FullAccess is not necessarily a wise move. It allows the recipient all access to S3, including the ability to delete buckets and objects.
Preferably, only allocate the permissions that each user actually needs to perform their job.
Can we define object level ACL having group in which I can club users from other AWS account. Idea is having a group to which I can add or remove users. I know ACL are maintained at object level and for every new grantee I have to add it in ACL. But having a group assigned to ACL and then modifying that group will be way easier approach. I know it supports predefined groups like authenticated user . Is there a way to create other predefined groups based on application need?
Don't use ACLs, they're a legacy access control mechanism and they're going to bite you.
According to the docs (emphasis mine):
Access control lists (ACLs) are one of the resource-based access
policy options (see Overview of managing access) that you can use to
manage access to your buckets and objects. You can use ACLs to grant
basic read/write permissions to other AWS accounts. There are limits
to managing permissions using ACLs.
For example, you can grant permissions only to other AWS accounts; you
cannot grant permissions to users in your account. You cannot grant
conditional permissions, nor can you explicitly deny permissions. ACLs
are suitable for specific scenarios. For example, if a bucket owner
allows other AWS accounts to upload objects, permissions to these
objects can only be managed using object ACL by the AWS account that
owns the object.
As you can see from the limitations, it doesn't seem suitable for your use case.
There is a better solution for resource-based access policies and it's called bucket policies. They allow you to grant access to prefixes in the bucket based on IAM principals such as users and roles or AWS services, even from other AWS accounts. (note, that IAM groups don't work).
I suggest you review the Access Policy Guidelines before making your decision.
Is there an easy way to see what are the effective access permissions for a specific bucket? To be more specific about the environment, access to buckets is granted through identity policies, there are more than 170 IAM roles and users and 1000+ policies (not all of them are attached to IAM role or user). I need to see who has the s3:GetObject, s3:PutObject and s3:DeleteObject permission on a specific bucket. Is there some tool that can give me that kind of report? I can write a script that goes through all roles, policies attached to them, pulls out statements that contain specific bucket and then I can cross reference allows and denys, but I'm sure there is some smarter way of doing this.
I am not aware of any better way than you described. You can export your IAM settings (unless you already have them in CloudFormation or CDK scripts) as described at https://aws.amazon.com/blogs/security/a-simple-way-to-export-your-iam-settings/.
Then you can scan (manually or programatically) for policies of interest and to what users or roles are they attached.
From Using Access Analyzer for S3 - Amazon Simple Storage Service:
Access Analyzer for S3 alerts you to S3 buckets that are configured to allow access to anyone on the internet or other AWS accounts, including AWS accounts outside of your organization. For each public or shared bucket, you receive findings into the source and level of public or shared access. For example, Access Analyzer for S3 might show that a bucket has read or write access provided through a bucket access control list (ACL), a bucket policy, or an access point policy. Armed with this knowledge, you can take immediate and precise corrective action to restore your bucket access to what you intended.
I read https://aws.amazon.com/blogs/security/iam-policies-and-bucket-policies-and-acls-oh-my-controlling-access-to-s3-resources/, which to me answered the what and when, but not why.
I’m new to AWS and trying to learning it.
Why create two methods, and not just one? Based on the example in the article, why not just have IAM policy to handle both use cases, example like having IAM policy JSON include the ‘Principal’ entry as “base on association” or “??”, then it work like the Bucket policy. It look like for any services which require policy control will have another type of policy created. Example; YYY service policy will have a Principal and Action “YYY:”.
Reason I can think of is, S3 is where require lot of access control (like fine grain, grouping, etc..) and having a policy created specific S3 can ease management, and take less back-end resources?
S3 authorizes requests by testing all applicable authorities, in the "context" of user, bucket, and object.
See How Amazon S3 Authorizes a Request.
This document is confusing on first read, but it does give a better sense of what's happening with the multiple policies.
A few points to keep in mind:
Users do not own buckets. Accounts own buckets, and accounts own users.
If a user creates a bucket, the account that owns that user always owns that bucket.
If a user creates an object, the account that owns that user always owns that object -- even if the bucket where the object was created is owned by a different account.
Wait, what?
If my account gives your user permission to create an object in my bucket, you would actually own the object. Unless you give me permission to read it, I can't read it. Since it's in my bucket, and I am paying to store it, I can delete it, but that's absolutely all I can do to that object unless you give me access to it.
So there are three levels of permissions at play -- things users are allowed to do (IAM policies), things accounts allow to be done to their bucket and their objects in that bucket (bucket policies and ACLs) and things accounts allow to be done to objects they own (object ACLs).
The default action is implicit deny, but anything my account has the authority to allow can be allowed by allowing it in any one place, as long as it isn't explicitly denied, elsewhere. Explicit deny will always deny, without exception.
Implications of the model:
my user, my bucket, my object requires only one grant; access can be granted in any of the three places and only needs to be granted in one place, because my account owns all the resources... so I can do this in IAM policy, or bucket policy, or on the object.
my user, your bucket requires two grants -- I allow my user in IAM policy, and you must allow my user in yout bucket policy. I don't have authority to do things to your bucket without your consent, and you don't have authority to allow my user to do things without my consent.
it is possible to make my object in my bucket publicly readable via either the object ACL or via bucket policy, but not IAM policy, because IAM policies apply to users, and "everybody" is not one of my IAM users.
So, S3 needs multiple sources of grants becase of the permissions model. If you aren't doing anything cross-account, some of this would not be obvious since you would be unaware of some of the possible combinations.
My preference is for my bucket policies to require little attention. Users are given access in IAM, public objects are made public at the object level (you can do this in bucket policy, but I prefer it to be explicit at the object level), and so bucket policies have limited purpose -- sometimes there are bucket policy rules that deny access for all IP addresses except a list, usually the bucket policy denies uploads without AES-256 (so you can't "forget" to encrypt objects), and sometimes there are origin access identity rules for interoperating with CloudFront... but I do very little customization of bucket policies, because that's my design philosophy.
There are various reasons why there is IAM permission policy and resource-based policy such as S3 bucket policy.
Let's say you have a S3 bucket and you want to grant access to other account. It is not possible only using IAM policy. Hence you need the bucket policy to include the account or IAM entity as Principal.
Also, you cannot use Principal in the IAM permission policy since when you attach the policy to an IAM user, when the user makes request, it becomes the Principal.
Please have a look into the following for more details:
http://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html#Principal
http://docs.aws.amazon.com/AmazonS3/latest/dev/access-control-overview.html