The AWS IAM Management Console lists over 500 assignable authorization-based policies that you can provide to enable your IAM users to access various services. What do they all do, and how can you configure your own?
You should always fine-tune your permissions
First of all, it’s a terrible idea to use your root credentials for everything. AWS recommends that you create an administrator IAM user with console access (which you can log in with) to manage your account and only use your root credentials for account maintenance.
However, for anything that is not your own computer, you should set up access-based permissions for all remote services that need to be connected to AWS. Even if you are a one-person team, your server should not have administrator access to your entire account.
Read-only access works well for applications that do not make any changes. Giving write access is more dangerous than you might think ̵1; write access means the privilege of deleting files and closing instances, something you may not want your account to do.
Generally, you should create a new IAM user and only grant permissions it needs to use the AWS CLI on a remote machine. It is also a good idea to configure your personal CLI with:
to match the permissions you intend to use on the server, so that you do not encounter incorrect 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:
As a general rule for most services, there is a “read-only” permission and a “full access” permission. For example, S3 “
AmazonS3ReadOnlyAccess“. They are all handled by Amazon, but most of them are simply here as templates. It is much better to create your own policies.
For example, each state allows for a specific set of actions; You can see them in more detail by clicking on them and selecting “JSON”, which shows a complete list of everything that permission allows. For example “
AmazonDMSRedshiftS3Role“Policy provides the following permissions:
Your service probably does not 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 do not want to do this, you should – at least restrict access to the relevant service rather than giving full access to everything.
You should create your own policies
If the default policy does not 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 not give it read-only access, but it should not have full access either. You can define a new policy that only allows you to upload items 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 chose S3 for this example. Each policy applies to a specific service; If you need to grant an application multiple permissions, you must create separate policies for each service.
Then select the permissions you want, based on different access levels (List, Read, Tag, Write). The one you are looking for is “PutObject”, which makes it possible to upload objects. Here you can see how it is a bad idea to give write access to such a program; it really only needs a permission, but if it had full write access, it would have all the permissions in this list.
As you can see, there is one pulp more individual permissions than the standard policy. We can’t possibly explain them all, but fortunately AWS makes it easy to find out. click
? icon next to the state you want to know about, and it will display a sidebar with a quick description. If that is not enough, you can click “Read more” to go to the document page for that permission.
Once you have selected all the permissions you want, you can now restrict access to specific resources or choose to activate the permissions for all resources. In this example, our application may only need to upload files to a specific bucket and may not need access to other buckets you have or may create in the future.
You can select resources by selecting “Add ARN” to restrict access:
You must enter the Amazon Resource Name (ARN) for the item you want to grant access to. Fortunately, the policy editor makes this easy and provides a custom dialog that only asks for the resource name or ID; in this case you can enter the bucket name:
When you go even further, you can enable whitelisting so that requests must always come from your server. If you enable access for a remote service and your server IP will not change anytime soon, it is a good idea to turn it on.
You can also require that multi-factor authentication be enabled for the policy to be applied, which is only relevant for actual user accounts with access to the console.
Clicking “Add Terms” allows you to specify extended conditions that the request must meet before it is approved, such as allowing access only on Thursdays, if that is what you want.
When you are done, click next to review the policy and give it a name and description. Click on “Create policy”, and it should be visible and assigned to users in the policy list.