IAM Policy¶
A document which provides the details of the permission granted to access any AWS resources is called an IAM Policy. The default policy applied to all AWS users is non explicit deny.
The IAM Policy takes effect as soon it is attached to a user or group, there is no delay in its application. The User & Groups can have more than 1 policy attached at any given time. Roles are utilized because we cannot attach policy directly to AWS resources.
IAM Policy Document¶
How does an IAM Policy look like.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "*",
"Resource": "*"
}
]
}
The above is an example of an IAM Policy
If we observe closely, these are the various important points to note about the IAM Policy.
- Statement
- Each IAM policy is composed of statements. Policy can have one or more statements. In the above example, there is only 1 statement, composed of
- Effect
- It tells if the impact is allowed or deny. It takes these 2 values. In the above example, it is Allow for all.
- Action
- What type of action is allowed or denied. We can drill it down to single API also, which we will see later. In the above example, it is allowing all actions.
- Resource
- Which resource are being accessed using the policy. Like in case of S3, it can mention the resource is a S3 bucket, not the full S3. In the above example, all the resources are being granted access.
Explicit Allow & Explicit deny¶
When granting access explicitly we have 2 categories of IAM Policy
- Explicit Allow
- Explicit Deny
When a user has both explicit allow and explicit deny, then the explicit deny always take precedence. In all cases just remember deny is the best way.
- Example of explicit allow
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "*",
"Resource": "*"
}
]
}
- Example of explicit deny
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "*",
"Resource": "*"
}
]
}
IAM Policy Templates¶
We can have an IAM policy in two ways.
- Pre-Built Policy
- Custom Policy
Pre-Built Policy¶
- These are the policies provided by AWS to all the users. We can just pick and use which ever we like.
- These policies are identified with an Amazon logo just next to them.
- Most commonly used pre-build polices are
- Administrator Access
- Power User Access
- Read-Only Access
Administrator Access¶
Administrator Access: Full Access to all AWS resources.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "*",
"Resource": "*"
}
]
}
Power User Access¶
Admin Access, except it does not allow user-group management.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"NotAction": [
"iam:*",
"organizations:*",
"account:*"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"iam:CreateServiceLinkedRole",
"iam:DeleteServiceLinkedRole",
"iam:ListRoles",
"organizations:DescribeOrganization",
"account:ListRegions"
],
"Resource": "*"
}
]
}
Read-Only Access¶
Only View AWS resources. This policy is very big, please search for it in AWS. - The AWS managed policies cannot be edited, they are read only.
Custom Policy¶
- Some time the requirements of a policy cannot be fulfilled from an AWS managed policy. We have to use a custom policy in those cases.
- We can import the pre-built policy into our own, and then modify them.
Custom IAM Policy Generation¶
In addition to AWS provided policy, user can also create custom policy. We have 2 methods to create custom policy.
- Visual Editor
- JSON Editor
Visual Editor¶
The are 4 selections, we have to do for creating a policy, as shown below.
- Service
- Choose a service like, IAM, S3, EC2 on which the policy is applicable.
- Actions
- Based on the service selected, we can choose the Actions, which can be associated with it.
- Primarily the actions are
- List
- Read
- Tagging
- Write
- Certain service have certain extra Actions associated with itself.
- Resources
- We can restrict the Actions allowed on Services selected to specific resources.
- We may not have to provide the full access.
- The access can be restricted to even a particular ARN.
- Request Conditions
- The policy can also specify if the
- MFA is required for the access
- Only a particular public IP should be
- We also restrict using the time or the day and various other parameters.
- All the conditions if selected is AND ed
We can also take a easy way out, by "Import Managed Policy" and then modifying it to our need.
After selecting the above information we are only left with providing
- Tags
- Review
JSON Editor¶
We can use JSON editor if we understand the JSON syntax, and the format in which AWS wants the KEY/Value pairs. We can also import an existing policy and then edit the JSON.
Conclusion¶
To summarize, IAM policy is a document representing the permission encapsulated inside for a USER or a Role.
The default policy on IAM is non explicit deny, but though IAM we can give either an explicit deny or an explicit allow. The explicit deny always takes precedence over any explicit allow.
IAM policy are categorized into either managed by AWS, or user created. There are many AWS managed policy and the most useful once are Administrator policy, Power user policy and Read Only Policy.
The IAM policy is a JSON statement, and having these 3 statement at the minimum
- Effect
- Action
- Resource
IAM policy can be created by using the custom visual editor or the IAM JSON editor. Generally for new users the visual editor is beneficial once the user becomes comfortable, we can change to JSON editor.
Multiple policy can be applied to Groups and Users. Roles are used for AWS resources.
Reference¶
- Photo by Ales Nesetril on Unsplash
- Creating IAM policies (console)
Top comments (0)