Identities and access are the core concepts of security as they control who is allowed to do what. AWS is no different and has its own AWS IAM service. AWS IAM has many different components which together governs the usage and access of any AWS account. In this blog post we will be covering AWS IAM policies, and break them down into components to understand how they work.
What are different AWS IAM components?
Before we understand how AWS IAM Policies work we need to understand what are the different component types in AWS IAM. AWS IAM consists of below components:
- Users (don’t use them)
- Groups (don’t use them)
- Policies
- Roles
- Permission boundaries
Users and Groups
Special note about users and groups as I have mentioned above don’t use AWS IAM Users and Groups. Users and Groups have been part of AWS IAM since beginning but now AWS has a better service with better out of the box security practices for users and groups. The service is called AWS SSO, please use it to manage your users.
Roles
AWS IAM Roles are the roles that are either assigned to different AWS resources to allow them to access other AWS resources or the Roles can be assumed by users to perform the tasks that their normal users are not able to. We will discuss AWS IAM Roles in a different blog post in detail.
What are AWS IAM Policies?
Before we move further lets talk a bit about AWS IAM Policies. AWS IAM Policies are identity based policies that are nothing but a json document describing who has access to what and on what conditions. The AWS IAM policies can be categorized in 3 sub types.
- AWS Managed Policies (don’t use them in production)
- Customer Managed Policies
- Inline Policies
AWS Managed Policies
These are the policies that you can not modify and they are being created and managed by AWS. These are mostly generic policy documents covering wide range of use cases for all AWS customers, and because of this they are very broad in nature and grant permissions that are not required most of the time. These policies are created by AWS to help you get started on AWS easily but the use of these policies is not recommended in production. Because these policies conflict with least privileges security best practice.
Customer Managed Policies
Customer Managed policies as the name suggest are the policies that are created from scratch and managed by the customer and this is what we will be understanding in this blog post in detail. Customer Managed policies are the only way you should be using it in production. Customer managed policy json documents are the individual documents with their own ARN and can be attached to multiple identities.
Inline Policies
Inline policy documents should be avoid if you can but in some cases they are necessary and their usage makes more sense. Inline policy documents are not individually created and maintained instead they are just inline documents created under identities and assigned to that identity directly. These documents doesn’t have the ARN so and can’t be assigned to multiple identities.
AWS IAM Policy Syntax
Now that we have talked about AWS IAM policy types lets see how a policy actually looks like and break it down to its basics. We are going to build the policy document from scratch. We are only going to talk about AWS IAM Customer managed policies so we will skip the syntax that does not apply to Customer Managed policies. Since we know that policy document is a json document so at its very basic a json document is nothing but set of brackets.
{
// the policy will go here
}
Version statement
The policy document contains a version statement to allow you to define which policy language version you are using so it be evaluated accordingly. There are 2 versions available:
- 2012-10-17
- 2008-10-17
As from the version string we can see that 2012-10-17 is the new policy version with most features so we are going to use that. This is how our policy document looks like with the version statement.
{
"Version": "2012-10-17"
//statements goes here.
}
Policy Statements section.
Policy statement section in policy document is list of policy statements which are specify the access. Lets see how a policy document looks like with statements list and then we will break down the statements into sub components.
{
"Version": "2012-10-17",
"Statement" : [
statement1,
statement2
]
}
Sid
Sid are just statement IDs for individual statements, they are only for your reference and must be unique. A policy document with statements and sid looks like following.
{
"Version": "2012-10-17",
"Statement" : [
{
"Sid": "statement1"
}
{
"Sid": "statement2"
}
]
}
Effect
The effect is one of the mandatory elements of a policy statement and tells AWS that if the identity this policy is applied to should be allowed or denied access. We will now add the Effect statement to our policy document that we are building. We are going to add Allow in statement1 and Deny in statement2
{
"Version": "2012-10-17",
"Statement" : [
{
"Sid": "statement1",
"Effect": "Allow"
}
{
"Sid": "statement2",
"Effect": "Deny"
}
]
}
Action
Action is an AWS API action which the identity is going to perform either through AWS CLI, API or AWS Console. There are thousands of different AWS actions and the Service authorization Reference document lists all the actions available for individual services in detail.
Lets add actions to our evolving policy document. We will add a lambda function execution action to statement1 to allow the identity to execute lambda function and we will add ECR describe images to statement2 which will deny listing the container images in AWS ECR.
{
"Version": "2012-10-17",
"Statement" : [
{
"Sid": "statement1",
"Effect": "Allow",
"Action": "lambda:InvokeFunction"
}
{
"Sid": "statement2",
"Effect": "Deny",
"Action": "ecr:DescribeImages"
}
]
}
Resource
The Resource statement allows you to specify the AWS resource the action will act on, in above example we have specified the lambda execution action i.e “lambda:InvokeFunction”, now we need to specify which lambda the identity i.e IAM user or IAM role should be able to execute or run. Resources are specified in ARN format and can include “*” to specify wildcard resources.
Lets allow the user to specify the lambda function ARN and deny access to list all containers.
{
"Version": "2012-10-17",
"Statement" : [
{
"Sid": "statement1",
"Effect": "Allow",
"Action": "lambda:InvokeFunction",
"Resource": "arn:aws:lambda:us-east-2:123456789012:function:my-function"
}
{
"Sid": "statement2",
"Effect": "Deny",
"Action": "ecr:DescribeImages",
"Resource": "*"
}
]
}
Condition
Condition are conditionals, this is true for AWS IAM policy statements. If you don’t specify conditions the policy will be applied always, but if you specify a condition the policy will only be applicable if the specified condition matches. The condition can be anything like specific date, or the source IP address. The conditions consists of specific condition operators and and conditions to match against. You can read about condition and condition operator on AWS IAM Condition user guide. We will talk about AWS IAM Conditions in more details in another blog post.
Conclusion
As we went through writing our custom AWS IAM policy document and broke it down into its basic components, I hope it has clarified for you what an IAM policy looks like and how you can create your own IAM policies. AWS IAM is a very simple service if you understand its basics and give you the power and control on your AWS account to keep it secure. At SUDO Consultants this is what we believe in that simpler the security implementation is the better it is to operate and manage which is what AWS Well-Architected pillars of Operational excellence and security are about.
