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.
Related
I have two IAM roles in AWS; A and B. In role A I have an explicit deny to prevent certain permissions from being performed in Elastic Map Reduce(EMR). How can I prevent a scenario where Role B could be updated to have an allow on the permissions that were denied in Role A?
I am not very familiar with our IAM federation but my understanding is that users access a federated portal URL and are presented with an initial role that they can select from a radial button based on the AD groups that they are in. From there users can change role/assume role if permissions are setup properly. Currently we have ~150 roles that I would need to ensure do not have the ability to circumvent the explicit deny in Role A.
If possible, it is always better to avoid Deny policies because they often do not work the way people expect. AWS has "deny by default" behaviour, so it is better to control access by limiting Allow permissions.
Unfortunately, many organisations use "Grant All" permissions, such as granting s3:* permissions and giving people Admin permissions. These examples grant too many permissions, which might then need a Deny to override.
Some services (eg Amazon S3, Amazon SQS) also have the ability to apply service-specific policies (eg S3 Bucket Policies) that can grant permissions in addition to IAM.
A good place to start is to strongly limit who has iam: permissions. Only admins should have the ability to use IAM (and that should only be granted via an IAM Role that the admins need to Assume). By controlling such access, it will avoid your scenario where you are worried that an IAM Role could be modified to permit unwanted access.
For worst-case situations where it is vital that access to certain resources are strictly controlled (eg S3 buckets with HR information), a common practice is to create a separate AWS Account and grant limited cross-account access. This way, access will not be granted via generic Admin policies.
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!).
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.
As per AWS documentation here - You cannot switch roles when you sign in as the AWS account root user.
If we go by AWS best practices i.e. not to use root user to perform actions, this restriction makes sense & supports why AWS does not allow role switch as root user. However, when using a Bucket policy, a root user in one account can access a Bucket in another account & AWS does not seem restricting that unlike roles (Technically, both are cross account actions using resource policies).
Why does this 'root user restriction' apply only for roles and not buckets - Any security reasons?
Access to services is normally granted via IAM permissions on IAM Users, IAM Groups and IAM Roles.
Some AWS services also permit the creation of policies that can grant access to aspects of that specific service. Examples are:
Amazon S3 bucket policies
Amazon SQS queue access policies
Amazon SNS access policies
These policies can be used to grant cross-account access, and also unauthenticated access such as public access to objects in Amazon S3 buckets and the ability to send unauthenticated messages to an Amazon SQS queue.
These policies are used to grant additional access. They do not involve "assuming" any additional roles.
I think there is some misunderstanding on the use of roles and a bucket policy with external account's root as principle.
The roles are meant to be temporary assumed, for someone or something that normally does not have permissions for some action. This could be a user or service from same or different account.
However, when you use other account's root in a bucket policy principle, you are giving that account permanent (until manually revoked by you) trust to the bucket for all or some actions on it. You use root as the principle so that the owner of the other account can delegate access to its own users or roles. You fully trust the other account to manage the access to the bucket without your involvement.
Off course if you are not comfortable giving such trust to the other account, you can limit access to you bucket to a given IAM user or a role only. This will obviously limit the ability of the owner of the other account to delegate access to your bucket.
I am deploying a server program in an ec2 instance which needs to be able to create pre-signed urls for s3. So far I've had my AWS credentials in environment variables for testing, but I would like to switch to the IAM Role strategy now. However, I am unsure as to which policies the role should have access too. My initial guess is to have AmazonS3FullAccess, but the description says "Provides full access to all buckets via the AWS Management Console" but the ec2 instance will be using the c++ sdk, not the management console. Or is the policy not important, just that it has a policy so it gets credentials somehow?
You're confusing policies and roles.
a policy grants permissions to a user or to a role or to a group.
the difference between a user and a role is subtle, but basically a role is something that's assumed by other services in AWS, like an EC2 instance, while a user is generally just an identity you've created for use in AWS.
The policy description for full access may make mention to the management console, but it grants full access to all buckets whether through the console, the api or an sdk, they're all really the same thing under the hood.
You should not use the fullaccess policy. You could use it as a base to build your real policy, but IAM should always use the least privilege principal, where you only give the permissions that are absolutely required, in this case the role only needs read and possibly list permissions on the specific bucket in question if generating urls for reading, or put permissions if allowing uploads.