How to automatically generate fine-grained AWS IAM policy
It is easy to assign full access policy to IAM principals so many of us do that to avoid writing a restrictive policy and that leaves our AWS account exposed to risk. But not anymore, because we now have a way to quickly and automatically generate a fine-grained IAM policy for our principals. So, let’s get started.
Before we actually talk about the way to generate a restrictive policy, let’s take a look at two sample policies to understand the difference between an over-permissive policy and a one with finite permissions.
Overly permissive policy
{
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:*",
"s3:*",
"iam:*"
],
"Resource": "*"
}
]
}
Restrictive policy
{
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:RunInstances",
"ec2:StartInstances",
"s3:ListBucket",
"iam:CreateUser",
"iam:CreateGroup",
"iam:CreateRole"
],
"Resource": "*"
}
]
}
Alright, let’s start with the fun part.
Access to the following services is required for automatically generating an IAM policy with a finite set of permissions:
CloudTrail
IAM
Let’s head over to the IAM service to generate a restrictive policy for an IAM user. You can try this with an existing user or create a new user. I’ll be using a new user with no permissions attached to the user.
Once you have decided the user you will be using for generating the policy click on Generate Policy button under the Permissions tab.
Note: Before proceeding ahead make sure you have a custom trail created in CloudTrail. If you don’t have a custom trail created follow the instructions mentioned in this documentation to create one. It is a security best practice to have a custom trail enabled so that all activity logs are stored in S3 or CloudWatch for as long as you need.
Once you click on Generate Policy button, you will be asked for a few inputs:
Select the time period for which you want to analyse CloudTrail events
Select the region in which your custom trail exists, the custom trail and the regions you want to analyse
Finally, if this is the first time let’s stick to the option of creating a new service role but if you have an existing role you are free to select that
Next, click on the Generate Policy button. Policy generation will take time depending on the number of events that need to be analysed.
Note: If you are generating an IAM policy for a newly created user like me chances are you might not see a policy generated if there aren’t any events in CloudTrail for that specific user. Hence, just to generate some CloudTrail events I logged into the newly created IAM user and navigated to a few services.
Once the policy is generated you will see a success message with a link to view the policy generated for your IAM user.
Click on the View generated policy link and you will be taken to a review page where you can see all the actions that were detected. You can add additional actions for those services or simply click Next.
Upon clicking Next you will be presented with the JSON version of the IAM policy which you can fully customise as per your need. You can remove actions from the generated policy, add some additional actions, add conditions to a statement or add permission for a new service.
The policy generated for me has a few errors, so let me fix those and make some minor changes.
Here’s the updated policy. I don’t want the user to have access to Storage Lens so I removed the block and updated the second block so that the user can only list his/her own access keys.
Click the Next button and on the final step, let’s give our policy a name, review the permissions summary and hit the Create and attach policy button.
Voila, without much effort and investing a lot of time we have a fine-grained IAM policy attached to our user.
Before we go
This is a great feature to help us generate a restrictive IAM policy but it surely does not take away the entire responsibility off our shoulders. We still have to review the permissions and modify them as required.
As mentioned earlier, you can also use this feature for an existing IAM user to refine permission for the current AWS account or for a protected account like your staging and production accounts.
Covering the basics
-
An AWS IAM policy is used for providing restricted permissions by attaching the policy to a principal (user, group or role) or a resource. Types of policies supported by AWS: Identity-based, Resource-based, Permission boundary, Service control policy, Access control policy and Session policy.
-
AWS IAM policy is written in JSON format that contains some required and some optional elements. You can use any of your favourite editors to write the policy. The format remains the same no matter which type of policy you are creating but the required elements change. Eg: if you are writing an identity-based policy, Principal isn’t required because when you attach the policy to a user, group or role, the entity is assumed to be the principal but when writing a resource-based policy it is required to mention principal.
-
An IAM policy contains more than just three components/elements. Some of these are required while others are optional:
Version: This is required and the value should be 2012-10-17 as it is the latest version.
Statement: This is a list of JSON object that defines the number of permissions. At least one block is required.
Sid: An optional unique identifier for the statement.
Effect: Only Allow or Deny is accepted.
Principal: Optional in case you are defining identity-based policy else required. This indicates which account, user, role or federated user will be allowed or denied access.
Action: List of API actions that are allowed or denied.
Resource: Required in case you are creating an identity-based policy else can be skipped.
Condition: An optional block to specify circumstances under which actions will be allowed or denied.
-
Writing a custom IAM policy can sometimes be challenging but thanks to AWS that simulating the policy isn’t. Using the AWS IAM Policy Simulator tool you can test if your custom policy acts the way you want it to. To use this tool you need to be logged in as a root or IAM user.
