AWS IAM permissions are the permissions that a user has to access and use the AWS services. They are used to manage access to resources, such as files, folders, and applications. The following table lists the AWS IAM permissions for a specific user: User Name Role Description aws_iam_access_key_id IAM role for the user’s account aws_iam_access_token IAM role for the user’s account aws_iam_certificate IAM role for the user’s account aws_iam_certificate2 IAM role for the user’s account awsS3 bucket name The name of an S3 bucket that stores data for this user
The AWS IAM Management Console lists over 500 assignable permissions-based policies you can give to enable your IAM users to access different services. What do they all do, and how can you configure your own?
You Should Always Fine Tune Your Permissions
First off, it’s a terrible idea to use your root credentials for everything. AWS recommends that you create an administrator IAM user with console access (that you can log in with) to manage your account, and only use your root credentials for account maintenance.
But for anything that’s not your own personal computer, you should set up access-based permissions for any remote service that needs to connect with AWS. Even if you’re a one-person team, your server should not have administrator access to your whole account.
Read-only access works well for applications that make no changes. Giving write access is more dangerous than you may think—write access means privilege to delete files and terminate instances, something which you may not want that account to do.
In general, whenever you have to link the AWS CLI to a remote machine, you should create a new IAM user and give it only the permissions it needs to operate. It’s also a good idea to reconfigure your personal CLI with:
to match the permissions you intend to use on the server, just so you don’t run into mismatched permissions issues when testing.
What Permissions Should I Use?
You can browse this list of permissions from the IAM Management Console, under the “Policies” tab:
Your service probably doesn’t need access to everything, so rather than trying to find the specific policy that works best, you should create your own policy to restrict access as much as possible. If you don’t want to do this, you should—at the very least—limit access to the relevant service rather than giving full access to everything.
You Should Create Your Own Policies
If the default policies don’t have the specific permissions you want, you can create your own policies. For example, if you have a service that needs to upload items to S3, you can’t give it read-only access, but it shouldn’t have full access either. You can define a new policy that will only enable it to upload objects to a specific bucket.
Click “Create Policy” from the policy browser. You can edit them as JSON, but the visual editor is much easier. Select a service; we selected S3 for this example. Each policy applies to a specific service; if you need to give an application multiple permissions, you need to create seperate policies for each service.
Next you select the permissions you want, based on different access levels (List, Read, Tag, Write). The one you’re looking for is “PutObject”, which enables objects to be uploaded. You can see here how giving write access to an application like this is a bad idea; it only really needs one permission, but if it had full write access it would have every permission in this list.
As you can see, there are a lot more individual permissions than default policies. We can’t possibly explain them all, but luckily AWS makes it easy to figure out. Click the ? icon next to the permission you want to know about, and it will bring up a sidebar with a quick description. If that’s not enough, you can click “Learn More” to go to the docs page for that permission.
When you’ve selected all the permissions you want, you can now restrict access to specific resources, or choose to enable the permissions for any resource. In this example, our application might only need to upload files into a specific bucket, and doesn’t need access to any other buckets you have or may create in the future.
You can choose resources by selecting “Add ARN” to restrict access:
Going even further, you can enable whitelisting so that requests must always come from your server. If you’re enabling access for a remote service, and your server’s IP isn’t going to change anytime soon, it’s a good idea to turn this on.
You can also require that multi-factor authentication be turned on for the policy to apply, which is only relevant for actual user accounts with access to the console.
If you click “Add Condition”, you can specify extended conditions that the request must meet before being approved, such as only allowing access on Thursdays, if that’s what you want.
Once you’re done, click next to review the policy, and give it a name and description. Click “Create Policy”, and it should be visible and assignable to users in the policy list.
