Inline Policy AWS Introduction

The management of access-rights within AWS is accomplished by using AWS Identity and Access Management (IAM) policies. IAM policies are a set of statements that define permissions and are attached to IAM entities such as IAM groups, users, or roles. Amazon evaluates IAM policies to decide what level of access users, groups, and services are allowed to resources. When attached to IAM identities, policies are referred to as identity-based policies. Policies may also be attached directly to AWS resources (e.g S3 buckets, KMS keys, etc) and are known as resource-based policies. These are then evaluated in combination with IAM policies to grant the correct level of access. The actions that the policy permits may be performed via the console, CLI, or SDK. Policy actions can also be restricted to specific resources by specifying their ARNs.

Identity-based policies can be associated with identities as either managed policies or inline policies. Managed policies can be attached to multiple IAM entities and managed independently. There are two categories: AWS-managed and customer-managed.  As the name indicates, AWS managed policies are pre-defined and are ready to be attached to identities. Customer managed policies, on the other hand, are managed by the customer and are tailored to an organization’s requirements. Inline policies follow a one-to-one relationship with IAM identities, meaning that an inline policy can be attached to only one entity, and has a lifespan equal to that of the IAM entity.

By ensuring that policies adhere to best practices, you mitigate the risks associated with over-permissiveness and aid the reusability and centralized management of permissions. This article aims to provide a deep dive into inline policies and we will: 

• compare them to other common policy types
• provide several inline policy use-cases
• cover several implementation best practices 

For your convenience, the executive summary below summarizes the key areas covered in the article.

Executive Summary

Inline Policies 

When setting permissions for IAM entities, you may choose from Inline Policies, AWS Managed Policies or Customer Managed Policies. Inline Policies are an implicit part of an IAM entity (group, user, or role). They can be created alongside an IAM entity (or at any other time) and are destroyed when the associated entity is deleted. The screenshot below shows an S3FullAccess-InlinePolicy that is attached to an IAM user. 

Fig 1. Inline Policy Attached to a user

The policy above is associated with the IAM user ‘coreStackUser’ only, and will be deleted automatically when the user ‘coreStackUser' gets deleted. Any series of permissions can be attached to an IAM entity when using an Inline Policy. Like all other policy types, Inline policies can be created using a policy editor or by writing the policy with JSON. Policies also support the addition of conditions, as well as any allowed actions specified against the resource. We can see below that a policy editor can be used to create policies, without having to understand the specifics of JSON.

Fig 2. Policy Editor

Comparing Inline Policies with Managed Policies

As previously discussed, Inline policies are considered an inherent part of an IAM object. Conversely, managed policies are stand-alone and can be attached from zero-to-many entities. AWS managed policies are administered by AWS and may be used immediately. They have been designed in advance by AWS to address many common use cases. Only AWS, and not the customer, may update AWS managed permissions. Any policy updates are applied automatically to objects that have the policy attached to them. We can see from the screenshot below that AWS managed policies are available through the AWS Management Console under IAM>Policies.

Fig 3. AWS managed policies

If required, policies can be tailored specifically for a customer's requirements and these are then referred to as customer managed policies. These policies are administered by the customer and are therefore only available within that customer's AWS account. Customer managed policies support re-usability, versioning, and the central management of permissions. The screenshot below shows a customer managed policy. In terms of structure, all three IAM policies are almost identical.

Fig 4. Customer managed policies

When to use inline policies?

Inline policies are useful when you want to ensure that a one-to-one relationship exists between an entity and the policy. This can be useful in scenarios where you don’t want the accidental allocation of a policy to another identity. Inline policies are destroyed with the deletion of the associated IAM entity, and therefore cannot be assigned to a different identity. Inline policies can also be used to assign temporary access to entities where policy versioning is not required. 

Fig 5. When to use inline policies

Securely managing certificates with an inline policy

AWS Certificate Manager securely stores TLS/SSL certificates so that they are readily available for use with other AWS integrated services. It is important to restrict access to these certificates to privileged users only. An inline policy can be attached to an IAM user that allows the import or use of a particular certificate.

KMS Key access management

AWS KMS is used to create and manage the keys that you use to encrypt and decrypt sensitive data, as well as to cryptographically sign and verify messages. As before, access to these keys should only be provided to authorized users. By attaching an inline policy to a key, we can also prevent any accidental allocation to unauthorized users. 

AI-powered Continuous Cloud Governance

Platform	Provisioning Automation	Security Management	Cost Management	Regulatory Compliance	Powered by Artificial Intelligence	Native Hybrid Cloud Support
AWS Native Tools	✔	✔	✔
CoreStack	✔	✔	✔	✔	✔	✔

When not to use inline policies?

Despite the ease of use, there are several scenarios where it is not recommended to use inline policies. Because inline policies are embedded into the entity that they are created for, assigning the same permissions to multiple users requires repeated duplication. This might not be too difficult for small environments, but larger organizations may have difficulty keeping track of policy assignments due to the larger number of entities. Better tracking can be achieved by using customer managed policies, where standalone policies are created and then assigned to all required identities. 

Fig 6.  When not to use inline policies

Updating copies of the same inline policy (attached to multiple users) is cumbersome, because changes must be applied to each and every copy. For AWS managed policies though, updates are managed centrally by AWS and are deployed without the need for customer involvement. It should be noted, however,  that AWS managed policies are designed to fit as many use cases as possible and therefore do not follow the principle of least privilege. For example, a lambda function could use a managed policy for S3 “AmazonS3FullAccess” to push images to S3 buckets. That policy though, is overly permissive and could be used to carry out a denial of service attack by deleting all S3 resources within an AWS account. Although updates are not applied automatically to customer managed policies, they are easier to manage since the policies are visible within a single console. Furthermore, a single copy of the policy can be attached to multiple entities.

Inline policies do not support versioning, so once a policy is updated the previous version is lost. If you require the ability to manage versions, you should use managed policies.

AWS supports the transition from inline policies to customer managed policies by copying the inline policy to a new managed policy. The new managed policy can be attached with the user/role/group along with the inline policy. Once the managed policy is attached, the inline policy can be deleted.

Inline Policy security risks

Company insiders could apply unrestrictive permissions (via inline policies) to perform illicit tasks, and these permissions could easily evade casual detection . For example, administrative permissions could be assigned using an inline policy, with the hope that this is then overlooked by a standard security audit. Also, If an inline policy were altered or corrupted by an attacker, it would not be possible to roll back the changes, since there is no built-in support for versioning. It is incumbent on Admin to version and archive previous versions for future use. Inline policies are typically difficult to audit since they cannot (by default) be viewed through a single IAM console. That being said, AWS Config and automation scripts could be used to identify if any inline policies were attached to IAM groups, roles or users. However, this is not particularly straightforward.

IAM Best Practices

According to the official AWS Best Practices for IAM, it is recommended to use customer-managed policies rather than inline policies. But in some situations, such as when enforcing strict one-to-one relationships, you can still choose inline policies. It is also recommended to use IAM condition keys within the policies – this is to ensure that certain requests can only be conducted under specific conditions. IAM condition keys can be used with any Identity-based policy and most resource-based policies. For example, the condition key aws:MultiFactorAuthPresent can be used to ensure that MFA authentication is used for temporary credentials. 

It is also a good idea to use your company's tagging policy to create a uniform convention within your policies, as this helps with policy identification and auditing. We also recommend that you implement a management process that ensures that any permissions assigned via policy, follow the principle of least privilege. With this in mind, IAM access analyzer can be used to review and validate your policies based on predefined AWS checks. Furthermore, CloudTrail logs should be enabled for global events, and Cloudwatch alarms should be set up to notify of any IAM changes within an account (for example, the creation and deletion of policies, the attachment of inline policies to users, and so on).

AI-powered Continuous Cloud Governance

Platform	Provisioning Automation	Security Management	Cost Management	Regulatory Compliance	Powered by Artificial Intelligence	Native Hybrid Cloud Support
AWS Native Tools	✔	✔	✔
CoreStack	✔	✔	✔	✔	✔	✔

Conclusion

While IAM policies are an essential part of AWS access management, security misconfiguration, poor access control, and overly permissive policies are critical vulnerabilities that can lead to subsequent exploits and breaches. It is therefore important to follow the best practices and recommendations highlighted in this article to minimize and manage these weaknesses. Use inline policies only when there is a requirement for strict one-to-one relationships, or when assigning access on a temporary basis. For all other cases, particularly where reusability, update management, central control, and versioning are a concern, we strongly recommend the use of managed policies.