Read on:
AWS for Beginners: Understanding AWS Terminologies: Part 1
AWS for Beginners: What is AWS EC2: Part 2
AWS for Beginners: AWS Compute Services: Part 3
AWS for Beginners: How to Protect AWS Security Tools: Part 4
AWS for Beginners: What is IAM (Identity and Access Management) and Best Practices: Part 5
AWS for Beginners: Provisioning IAM Users and Programmatic Access in AWS: Part 6
AWS for Beginners: Securing Root account using MFA: Part 7
AWS for Beginners: Amazon S3 Overview, Security and Best Practices : Part 8
AWS for Beginners: Creating and managing IAM groups: Part 9
Introduction
In the cloud, whenever any identity like a user or any other cloud resource requests access to any other resource in the cloud, then necessary checks have to be made to ensure that there are required permissions available for the identity for that request. In AWS, the IAM service helps to configure the required authentication and authorization for the identities. Authentication means to validate the credentials used by the identity for signing in and authorization means whether the identity has the required permissions to access the resource.
Policies in AWS help to manage access to the resources. Policies are JSON documents that define what type of access an identity can have for a resource. Once the policies are created, they can be attached to an identity and those permissions are applied to that identity. When the identity requests access, the AWS policies are evaluated and if the permissions are allowed, then the identity can access the resource. Permissions defined by a policy are applicable to any type of access method like AWS console, AWS CLI, or API-based access.
There are 6 different types of policies in AWS.
- Identity-based policies
- Resource-based policies
- Permission boundaries
- Organization SCPs
- Access Control Lists (ACLs)
- Session Policies
Identity-based policies
Identity-based policies are those JSON documents that are applied for identities like users, groups, or roles. These policies define what permissions the identities can have on the resources under specific conditions. There are further categorizations in this type of policy.
- Managed policies
These are standalone policies that can be attached to multiple users, groups, or roles in the AWS account. Standalone policies mean that these policies have an ARN with the policy name. For example, the ARN arn:aws:iam::3748592019332:policy/ManageCredentialsPermissions is a managed policy that provides permissions to ManageCredentialPermissions. Managed policies can be used for the most common and widely used scenarios.
There are further categorizations in this policy type.
- AWS managed policies
These policies are the default set of policies available in the AWS account that is created and managed by AWS. If these policies satisfy your requirement, you can attach these policies directly to the identities.
One advantage of using managed policies is that there are policies defined based on the job functions. For example, there are policies like Administrator Access, and Power access, etc., Administrator access policy can be attached directly to a group that contains only the Administrator users. A power access policy can be attached to users who need all privileges except for IAM and organizations.
Users cannot change the permissions of AWS-managed policies. AWS will update the permissions in these policies whenever there is a new service released or when there are new API calls released for existing services.
- Customer-managed policies
These policies are created and managed by the customers in the AWS account. These policies can be created in a much more precise manner that can have fine-grained permissions based on the requirement. If the AWS-managed policies have more broad permissions for any resource, then you can go with your policies to define restricted permissions.
- Inline policies
These are the policies that are added directly to a single user or group or role. These policies are strictly tied up with an identity. Also, when the identity is deleted the policy is deleted. For example, if you want specific permissions to be assigned to a specific identity only and not to any other identities, then inline policies can be used. Inline policies ensure that these policies could not be assigned to the wrong identities.
Which policy to choose – Managed or Inline?
In general, the recommended policy to use is managed policies. But the usage depends on the different types of use case scenarios.
Managed policies provide the following features:
- Ability to reuse – A single policy can be attached to multiple identities
- Centrally Managed – When the policy is updated, it is applicable for all the identities to which the policy is applied
- Ability to version & roll back – When updating a customer-managed policy, the old version is not deleted. But a new version of the policy is created and hence, rollback becomes easy
- Ability to delegate permissions – Few users can be delegated to create and manage policies and few users can be delegated to attach the policies to the identities
- Perform automatic updates – AWS-managed policies are automatically updated by AWS whenever there is a new service or API update released and don’t require any user intervention
Resource-based policies
Resource-based policies are those JSON documents that are applied to AWS resources like S3 buckets, VPC endpoints, etc., These policies define permissions to perform specific actions on those resources under specific conditions. All resource-based policies are inline policies only. There are no managed resource-based policies.
Difference between Identity & Resource-based policies
Permissions Boundaries
AWS IAM allows setting permissions boundaries for identities like Users or Roles. Permissions boundary is an advanced feature in IAM that can set the maximum permissions an identity can have. Identity-based managed policies are used to configure permissions boundaries. Both AWS-managed policy and customer-managed policy can be used to configure permissions boundaries.
The permissions boundary does not provide the permissions by itself but it is used to limit the actions that can be performed by the user or role.
When permissions boundaries are set, an identity can get the permissions to perform actions that are allowed by both the identity-based policy and the permission boundary.
For example, let us assume for an IAM user User A, a permission boundary is set for managing EC2 and S3 using the below policy.
{
“Version”: “2012-10-17”,
“Statement”: [
{
“Effect”: “Allow”,
“Action”: [
“s3:*”,
“ec2:*”
],
“Resource”: “*”
}
]
}
Now, you assign permissions to User A to create IAM users by using the policy below.
{
“Version”: “2012-10-17”,
“Statement”: {
“Effect”: “Allow”,
“Action”: “iam:CreateUser”,
“Resource”: “*”
}
}
Now if User A tries to create an IAM user, the operation will fail. Because the permissions boundary policy does not allow any actions for IAM.
Organization SCP’s
Service Control Policies (SCPs) are the type of policy that is used for AWS Organizations. SCPs provide a way to centrally control (or) manage the maximum permissions for all the accounts in the Organization. If all the features are enabled in an organization, then you could apply service control policies (SCPs) to any or all accounts. SCPs could not be applied if only the consolidated billing features are enabled in an Organization. SCPs are JSON policy documents that specify the maximum permissions that would be provided for an Organization.
SCPs do not provide any permissions. An SCP is like a guardrail or it sets limits on the actions that the account’s administrator can delegate to the users and roles. To grant permissions to the users and roles, the account administrator should attach the identity-based policies, and to grant permissions to the resources, the account administrator should attach the resource-based policies. The effective permissions will be the intersection of the permissions from both the SCP and the Identity based or resource-based policies.
Access Control Lists (ACLs)
ACLs are the type of policies that can be used to define which identities from other AWS accounts can access a resource. These policies are not in JSON format. This is similar to a resource-based policy. ACLs cannot be used with the same account to control access to a specific resource.
Session Policies
Session policies are used to provide access during a temporary session for a role or a federated user for programmatic access to the AWS resources. A role session can be created and session policy can be passed as a parameter through the AssumeRole, AssumeRolewithSAML (or) AssumeRolewithWebIdentity API operations.
Conclusion:
In this article, we have gone through the various policies available in AWS IAM and what is the difference between each policy, and in what conditions a policy can be used. It is very important to identify the right policy type for the use case. The most commonly used policy types are identity-based policies and resource-based policies. Along with that, the Permissions boundaries are also used to restrict the permissions of the users. By using policies, one can protect the AWS cloud environment from unauthorized access. Policies could provide finely-grained permissions for the resources and hence it’s up to the cloud administrator to decide upon how to set up the permissions using policies based on the use case scenarios.
Follow our Twitter and Facebook feeds for new releases, updates, insightful posts and more.
