IAM Policy

IAM Policy

IAM policies are permission statements applied to AWS identities – user, role or group, which specify what actions can be performed by that identity on an AWS resource/service. Since these policies are applied to AWS identities, these are sometimes also referred to by AWS as Identity-based policies. Some policies are created by AWS and are available in the AWS IAM console, which are called AWS managed policies. Others can be created by you for your own specific needs and are called Customer managed policies. I know this description looks simple, but AWS policies are anything but simple because of two reasons – firstly, AWS policies can be created at other places and not just IAM – resource policies like for S3 and KMS, AWS Organizations with Service Control Policies (SCPs), and Permission Boundaries. And secondly, because policies created at multiple places may conflict with each other and can create a troubleshooting nightmare. So take a deep breath, relax and let us take it step by step. In this article we will talk about the concepts of an AWS IAM policy or Identity-based policy. We will introduce other policies like Resource policy, SCP and Permissions Boundaries in the future articles.  

Components of an IAM Policy

An IAM policy has three mandatory components – Action, Resource, Effect and one optional component – Request Conditions. 

Actions specify the service and the related permission that the policy is evaluating. It has two parts – AWS Service name and action. Example if Rachel is creating an IAM policy for reading objects from a S3 bucket, the Action would be “s3:GetObject” which would grant permission to retrieve objects from Amazon S3.

Resources specify the resource for which the action is applicable. Rachel would specify the Resource as the S3 object resource ARN.

Effect is simply “Allow” or “Deny”.

Finally, Request Conditions are the optional parameters that can be used for restricting access for specific use cases. If for example, the S3 object above was highly confidential and Rachel wanted an additional level of protection, she might specify the ConditionKey “aws:SourceIp” in the Condition block and give it the value of a CIDR range to restrict the access to the S3 object to only a specific source IP block. There are a bunch of other similar conditions, some generic ones like “aws:SourceIp” and some specific to a particular AWS service like – “s3:TlsVersion” to restrict user or application access to S3 buckets based on the TLS Version used by the client.

Key Security Insight

One important security aspect to be mindful of with IAM policies, is that the policy does not need to have a specific value for Action/Resource, meaning, you can specify * (star) in either of these elements to specify “Applicable to ALL”. Rachel could very well have created a policy with Action – “*” , Resources – “*” to mean that this policy allows all actions to all AWS resources (effectively Admin privileges). This feature along with the need for agile development is the reason why there are excessive and unnecessary permissions in the AWS dev environments for almost all companies today, and might remain so for the fore-seeable future.

Negative IAM blocks

For creating advanced Policies, there are negative blocks for IAM Policy called -NotAction and NotResource. These can be used for policy statements like – “Allow/Deny all actions but these actions” or “Allow/Deny access to these resources but these resources”

Lab Demo

In the video lab walk-through, we will create our very first IAM policy to grant read access to a S3 object from a particular source IP. We will also show how easy it is to create excessive permissions. And finally, we would attach the policy to a user/role.

Security tidbits

Summary of security best practices to keep in mind regarding IAM Policies: