Inline Policies Vs Managed Policies

AWS Managed Policies

An AWS-managed policy is a stand-alone policy that has been created and maintained by AWS. When a policy is regarded as stand-alone, it means that its name appears in its own unique Amazon Resource Name (ARN). One AWS-managed policy is arn:aws:iam::was: policy/IAMReadOnlyAccess. The IAMReadOnlyAccess AWS managed policy provides read-only access to all AWS services and resources. When a service launches a new feature, AWS adds read-only permissions for new operations and resources.

For a variety of frequent-use scenarios, AWS-managed policies are made to offer permissions. AWS-managed policies for power users like AWSKeyManagementServicePowerUser and AWSCodeCommitPowerUser are created with their needs in mind. Assigning the proper rights to users, groups, and roles is more straightforward when using AWS-managed policies than writing your policies.

The policies created for job functions are one kind of AWS-managed especially helpful policies. These regulations closely match the duties performed by typical IT employment roles. The goal is to make it simple to provide permissions for these typical job duties. An important perk of working with AWS is that they maintain and modify specific policies as new services and API activities are published.

The permissions specified in AWS-managed policies cannot be altered. The permissions specified in an AWS-managed policy are periodically updated by AWS. All principal entities (users, groups, and roles) to whom the policy is tied are impacted when AWS makes this change. An AWS-managed policy is most probably to be altered when a brand-new AWS service debut or when previously undocumented API methods are made accessible for services that currently exist.

For instance, all AWS services and resources are accessible with read-only access using the AWS-managed policy known as ReadOnlyAccess. AWS modifies the ReadOnlyAccess policy to add read-only access for a new service when it begins. The policy's attached primary entities receive the updated permissions.

The diagram that follows shows how AWS-managed policies work. AdministratorAccess, PowerUserAccess, and AWSCloudTrailReadOnlyAccess are three examples of AWS-managed policies that are shown in the diagram. It's crucial to understand that a particular AWS-managed policy can be implemented to the primary units in both a single AWS account and numerous distinct AWS accounts.

Customer Managed Policies

An independent policy that you design and manage inside of your own AWS account is known as a customer-managed policy. Only the users, groups, and roles inside your account are eligible to have this policy attached to them.

You can duplicate a current AWS Managed Policy and modify it to meet the needs of your business to build a new Customer Managed Policy.

It is advised to use a customer-managed policy in cases where your environment's requirements do not match those of the already existing AWS Managed Policies.

Get Started Using Permissions with AWS Managed Policies

The safest way to grant the least privilege is to write a customer-managed policy with only the abilities needed by your organization. You must establish a procedure that enables your team to ask for additional permissions as needed. It takes time and skill to create IAM customer-managed policies that grant your team only the permissions they need.

Use AWS-managed policies to begin adding permissions to your IAM identities (users, user groups, and roles). Least privilege permissions are not granted under AWS-managed policies. If you provide your principals greater permissions than they require to perform the duties, you must take into account the security risk.

Any IAM identity can have AWS-managed policies attached to it. Before converting to least privilege permissions, you can track the principals. Once you know which permissions your team is using, you may build a custom policy for them or a policy with just the permissions you need. This is less secure but provides more flexibility as you learn how your team is using AWS.

Inline Policies

An IAM policy known as an Inline Policy is integrated into the user, group, or role to which it is applicable. The organization and the policy have an exact 1:1 relationship.

The policy will be destroyed together with the user, group, or role that the inline policy attached.

AWS typically advises choosing Managed Policies over Inline Policies.

When you want to ensure that a policy's permissions are not unintentionally granted to any other users, groups, or roles than the ones for which they are intended, inline policies might be helpful (i.e. you are establishing a policy that can never be associated with more than one user, group, or role).

Choosing Between Managed Policies and Inline Policies

The various policy types can be chosen based on the use case scenarios. We generally advise using managed policies rather than inline policies.

The features listed below are offered by managed policies:

• Reusability: Multiple principal entities may be connected to a single managed policy (users, groups, and roles). You may, in essence, compile a collection of policies that specify the permissions you'll need for your AWS account, and you can then attach these rules to primary entities as necessary.
• Central Change Management: All primary entities with which the managed policy is associated are affected when you make a change to it. As an illustration, you could edit the managed policy to include the permission if you wanted to add it for a new AWS API. All major entities to whom the policy is related will be affected when it is modified. In contrast, you have to individually modify each identity that the inline policy is contained in if you want to change it. For instance, if an inline policy is shared by a group and a role, you must manually edit each of the `two major elements to alter it.
• Versioning and Rolling Back: When you alter a customer-managed policy, the new version doesn't replace the old one. IAM instead develops a fresh iteration of the managed policy. Your customer-managed policies may be stored in up to five different versions by IAM. If necessary, you can go back to a previous version of a policy using policy versions.
• Delegating Permissions Management: While keeping control over the rights outlined in those policies, you can enable consumers in your AWS account to attach and detach policies. You can essentially designate select people as full administrators, or administrators who can add, edit, and remove policies. Then, you can assign other users as restricted administrators. Administrators can only attach those policies to other primary organizations, that you have given them permission to.
• Automatic Updates for AWS Managed Policies: Without your involvement, AWS keeps track of AWS managed policies and modifies them as needed (for instance, to add permissions for new AWS services). The primary entities to whom you have linked the AWS-managed policy automatically receive the updates.

Converting an Inline Policy to a Managed Policy

You can change any inline policies you have in your account to managed policies. You can duplicate the policy to a newly managed policy to accomplish this. The new policy should then be linked to the identity that already has the inline policy. After that, remove the inline policy. The steps listed below can be used to do this.

Process of Changing an Inline Policy Into a Managed Policy

• Open the IAM console by logging into the AWS Management Console at this Link.
• You can select User groups, Users, or Roles from the navigation pane.
• Select the name of the user group, user, or role that is the owner of the policy you want to delete from the list.
• Select the Permissions tab.
• Choose the name of the inline policy you want to delete for user groups. If necessary, select Show n more for users and roles before selecting the arrow beside the inline policy you wish to delete.
• For the policy, replicate the JSON policy document.
• Select `Policies from the navigation window.
• Select the JSON tab after selecting Create policy.
• Select User Groups, Users, or Roles from the navigation pane, then click the name of the user group, user, or role that has the policy you wish to delete.
• Select Add permissions under Users and Roles.
• Check the box beside the name of your new policy, select Add permissions, and then select Attach a policy for user groups. Add permissions can be selected for people or roles. Select Next: Review, check the box beside the name of your new policy, select Attach existing policies directly, and then select Add permissions.
• Your user group, user, or role's summary page is displayed once more.
• The inline policy is now deleted and a similar managed policy has been attached to the resource with the same permissions.

Deprecated AWS Managed Policies

When a new service is added, AWS may need to update an old policy with new permission. There are no features or abilities disrupted or lost when new permission is added to an existing policy.

However, if the required modifications to a current policy might have an impact on customers, AWS can decide to develop a new policy instead. For instance, deleting permissions from an established policy could affect all IAM entities and applications that rely on it, thereby disrupting a crucial process.

The traits of a deprecated policy are as follows:

• It still functions for all users, groups, and roles that are currently associated. Nothing is broken.
• It is incompatible with any brand-new users, groups, or roles. It cannot be reattached to an existing entity once it has been detached.
• It becomes invisible and completely useless once you have detached it from all active entities.

As an alternative, you must attach the new policy if any user, group, or role still needs the old one. We advise that, as soon as you learn that a policy is being deprecated, you make plans to promptly detach all users, groups, and roles from the deprecated policy and attach them to the replacement. The dangers associated with using the deprecated policy can only be eliminated by changing to the replacement policy.