AWS IAM Policy Example

Cloud service providers usually offer an IAM or Identity and Access Management feature to give a user root account extra security. In a work/production environment giving each user access to a root account or managing services directly from the root, the account is vulnerable to security threats. Instead, we can create users with specific permissions to avoid privilege escalation problems. Following the same pattern, AWS provides provisions for creating IAM-based users, roles, and policies.

By attaching IAM policies to IAM roles, we can control the type of access, tasks that can be performed, and the resources used with these tasks. IAM policies can be used to provide access permission to particular AWS service APIs and resources. In the same way, we can decide under what condition access should be provided.

We need permissions for IAM entities like users, groups, and roles to make them access AWS resources. By default, AWS provides no permissions to these entities. And that’s where AWS Policies come in. These policies are attached to the above entities to grant them various permissions.

What will we cover?

In this guide, we will discuss the AWS Policy section and see some example policies. We will also see a practical demo of using an AWS policy for RDS-based operations.

Types of Policies

AWS provides the following types of policies:

1. Identity-based policies: Used for attaching managed and inline policies to IAM entities like users, groups, and roles. It gives permission to an identity.

2. Resource-based policies: Used for attaching inline policies to resources, e.g., attaching an S3 bucket.

3. IAM permissions boundaries: This feature lets you specify the maximum permissions that can be set to an IAM entity by an identity-based policy.

4. Service control policies: Used for defining maximum permissions granted to accounts owned by an organization.

5. Access control lists(ACLs): Used for controlling which specified principals from other accounts can access the resources in the native account.

6. Session policies: These are passed as an argument or parameter when a temporary session is created for a role.

The JSON format is used for defining most policies in AWS. However, we can also use the visual editor instead of writing the JSON syntax for defining a policy. AWS provides a pre-built policy for many use cases which can be used with your IAM identities. This page documents various use cases for IAM identities. Let’s take a use case of an Identity-based policy for RDS.

Example of an AWS IAM Policy

For this tutorial, we have created an IAM user who, by default, cannot create or modify RDS resources due to permission barriers. For e.g., in its current state, without any policy attached, this IAM user cannot create an RDS DB instance. If we try to create an RDS DB from the RDS console of this IAM user, we get the following error:

As an IAM administrator, we will create a policy and then attach it to the IAM user. This policy will enable our IAM users to:

1. Create database 
2. Delete database 
3. Describe database
4. Start database
5. Stop database

For the above operation, we will add an identity-based policy called Inline policy. This inline policy is a set of minimum permission set for the above-specified database operation. Now follow the instructions below:

Step 1. Go to the AWS IAM console of the root Account and click ‘Users’ and choose the target user from the list(‘LinuxHint’ in our case):

Step 2. On the new page, we can see that there are no policies attached to the IAM user. Click on ‘Add inline policy’ as shown below:

Step 3. A new wizard named as ‘Create policy’ will appear where you have to select the JSON tab and paste the below code there:

Step 4. Now click the ‘Review policy’ button at the bottom:

Step 5. Give a suitable name to your policy and click the “Create policy’ button:

The above inline policy can now be seen under the permissions tab:

Now we can create and manage an RDS database through an IAM user. To check this, head back to the RDS console of the IAM user and again try to launch an RDS DB instance. This time we can launch the database easily under the ‘Standard create’ option of the RDS launch wizard.

Final Note: Do not forget to clean up the resources not in use to avoid unexpected charges.

Conclusion

In this guide, we have learned about AWS policies for fine-grained control of resources. We have seen a demo attaching an identity-based policy to a user, which enabled it to manage RDS resources. Try experimenting with different policies available on the AWS by assigning minimal permissions to an IAM user.