AWS IAM Inline vs. Managed Policies

What Are AWS IAM Identities?

An IAM policy defines a set of access controls for AWS resources. You can attach these policies to an identity, and this grants or denies access to that identity. AWS supports several identity types.

User

A user identity represents a single entity. This user can be a human or a machine user that an administrator configures in an AWS account. You can add policies to a user; however, this is a very granular approach and does not scale well.

User Group

A user group improves your ability to manage users at scale. You can define user groups such as administrator, developer, test, and product. By controlling the IAM policies at the user group level, you can add a user to a group, and that action will immediately apply the policies for that group. You can even assign users to multiple groups.

Role

A role is similar to a user but is used to assign permissions to an entity. Consider the situation of an Auto Scaling Group (ASG) of EC2 instances. As the ASG changes in size, it may create an instance. Creating a new user to support that instance is not feasible at scale. Instead, new instances are assigned a role that defines all the allocated permissions during their lifetime.

After creating an identity, different policies are assigned to that identity, be it a user, a user group, or a role. AWS evaluates these policies together to determine whether to allow or deny an action. The final assessment is an intersection of all the applied policies, meaning that if one policy allows an action while another explicitly denies that action, the action is denied.

Types of Policies Available

The type of policy you create depends on several factors, and no single policy type is correct for all applications. The different policy types you can choose from are:

• Inline policies
• Managed policies
• Customer managed policies

Inline policies apply where there is a direct one-to-one relationship between the policy and the user or group. Usually, inline policies aren’t a good choice, but there are times when you might want to use one. We’ll discuss that in more detail and share some example use cases below.

Managed policies lend themselves to reusability and provide users with a library of well-defined and well-scrutinized policies they can attach to roles as needed. AWS provides a comprehensive collection of policies you can use, and customers can create their own managed policies.

Let’s explore each of these in more detail and view some examples and use cases.

Inline Policies

As we mentioned above, using an inline policy should be an exception. You’ll want to ensure a strict one-to-one relationship between the entity and the permissions defined in the policy. As you might imagine, there is a tight coupling between inline policies and the entity. If you delete the entity, the action deletes all inline policies associated with that entity. If the permission might apply to more than a single entity, it’s better to use a managed policy.

An example of where you might choose an inline policy would be where you want to ensure that someone does not inadvertently assign those permissions to another entity. Consider a case where an organization has S3 folders assigned to each department. The organization decides that only the CIO can grant access to every department’s folders and give them access permissions. You could create an inline policy on the permitted user that would grant this to only their user profile.

After creating the new CIO user, you might see something similar on their AWS user profile.

Clicking the Add inline policy link would take you to a page where you could add the inline policy using a simple JSON editor or the Visual editor that walks you through the process. Let’s choose the Visual editor and enter the following policy:

• Service: S3
• Actions: All S3 actions (s3:*)
• Resources: All resources
• Request conditions: MFA required

After selecting those options and clicking on the Review policy button, you can review the actions allowed by this policy.

Clicking the Create policy button will add this as an inline policy to this user, and the CIO_Inline_Policy will not be available to other user accounts.

If you delete this policy or the associated user, the policy will cease to exist. This example is a little extreme but illustrates the application of an inline policy. A less extreme example might be if you have an AWS Lambda function that sends events to an AWS SQS queue. Suppose you want to ensure that only this Lambda can send events to the queue. In that case, you could create a role for the Lambda function to assume and attach a targeted inline policy that grants the sqs:SendMessage action for the ARN of the SQS queue to that role.

Managed Policies

Managed Policies are a collection of policies created and managed by AWS to make managing permissions as easy as possible. To be specific, these are AWS Managed Policies. Instead of selecting particular AWS resource types and the available actions for that type, you can choose an AWS Managed Policy that meets the requirements and attach it to a user, user group, or role.

If we return to the previous example, let’s say that any IT Management user group member has Read Only access to all S3 resources within the AWS account. From the user group profile page, you would click on the Add Permission button and select Attach existing policies directly. Then, you would see a list of AWS Managed Policies that can be attached to the group. At the time of writing, AWS has 807 Managed Policies from which to choose. You can select one or multiple policies to associate with the entity.

The benefit of using an AWS Managed Policy is that selecting specific actions on the resource has already been done and reviewed thoroughly to ensure that it grants only specified permissions. In the case of the AmazonS3ReadOnlyAccess policy, the only actions allowed on S3 are List and Get permissions, meaning the entity assigned this policy can only read (and not write to) S3.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:Get*",
                "s3:List*",
                "s3-object-lambda:Get*",
                "s3-object-lambda:List*"
            ],
            "Resource": "*"
        }
    ]
}Code language: Perl (perl)

Unlike an inline policy, the connection between an entity and a managed policy is by association. If you delete the entity, the policy remains as is.

Customer Managed Policies

AWS designed Managed Policies to be simple and easy to apply across the entire scope of specific AWS resources. For a small organization, this makes sense and reduces the management overhead associated with permissions management. However, as your organization grows, you will need to create more specific policies that may apply to multiple users, user groups, and roles. Customer Managed Policies provide this flexibility while incorporating many of the same benefits as AWS Managed Policies.

Let’s consider an organization that has a project with project resources stored in an S3 bucket. You need to give your engineers, QA team, and operations team access to this bucket without granting access to all S3 resources within your account. In this case, you can create a Customer Managed Policy that provides full access to this bucket and associate it with the user groups for each team.

From the IAM console, you would select the Policies option under Access Management and click the button to Create policy. As with creating an inline policy, you can use the Visual editor or enter the policy in a JSON editor. Let’s use the JSON option in this case. The ARN for the bucket in this example is arn:aws:s3:::acme-corp-projects-omega-group, and we want the policy to grant full access.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:ListStorageLensConfigurations",
                "s3:ListAccessPointsForObjectLambda",
                "s3:GetAccessPoint",
                "s3:PutAccountPublicAccessBlock",
                "s3:GetAccountPublicAccessBlock",
                "s3:ListAllMyBuckets",
                "s3:ListAccessPoints",
                "s3:PutAccessPointPublicAccessBlock",
                "s3:ListJobs",
                "s3:PutStorageLensConfiguration",
                "s3:ListMultiRegionAccessPoints",
                "s3:CreateJob"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": "s3:*",
            "Resource": "arn:aws:s3:::acme-corp-projects-omega-group"
        }
    ]
}
Code language: Perl (perl)

We can save this policy as Omega_Project and associate it with each user group for the teams involved. As with an AWS Managed Policy, this policy exists independently of each of the entities associated with it. And if an additional user or group requires the same access, you only need to associate this policy with that entity.

How to Choose the Right Policy

Selecting the right policy type depends on the kind of permissions that you need to grant to an entity and the scope of those permissions. In some cases, an inline policy may be the most appropriate and logical choice. However, if an AWS Managed Policy meets your needs or if the policy might apply to multiple entities in your organization, then managed policies are your best option.

Use the following guidelines when selecting the right policy for your use case:

• Does the entity require permissions for all AWS resources of a specific type? Begin by examining the Managed Policies provided by AWS and associate the AWS policies that match the level of access required for the user.
• Does the entity require permissions for specific AWS resources, and are these permissions likely to be reused or associated with multiple entities? Create a policy that provides the required permissions to the resources and associate it with the users, user groups, or roles that require these permissions.
• Is this the only entity that will require these permissions, and do we need to prevent these permissions from being accidentally granted to another entity? Consider creating an inline policy within the profile of this entity. Be aware that removing this entity will also delete this policy.

IAM policies require a careful and diligent approach. Consider your specific use case and select the policy that protects your resources while limiting the management overhead required to maintain those policies. The benefit of a platform like AWS is that you can update your decisions as your organization grows and evolves. If you create an inline policy and later determine that a managed policy may be better, you have the option to convert an inline policy to a managed policy.

Additional Resources

The AWS platform includes detailed and current documentation about its services, including Identity and Access Management (IAM). The managed policies and inline policies documentation is an excellent resource if you would like to learn more about each of these policies and discover additional tips and processes for managing your environment.