AWS Identity and Access Management Policy Types

IAM is the heart of access definition that tells who must have what access, and the level of access, and ensures the identity of the user with identity and authorization to use the resources.

Key terms in the IAM

• Identities
• Resources
• Entities
• Principles

Here this blog, will discuss different types of policies that provides powerful flexibility in designing IAM access controls.

• Service control policies
• Permission boundaries
• Identity-based policies
• Resource-based policies

Service control policies

Service control policies shortly known as SCPs are a feature of AWS Organizations. As the name suggests, AWS Organization is a service for managing the AWS accounts centrally by grouping them. SCPs are a set of policies that specify the maximum permissions or set access limits for an organization, organizational unit (OU), or individual account and even for a root user.

The primary function of SCPs is to enforce security permissions across AWS accounts and OUs in an organization. Security permissions are the configurations that you apply to multiple accounts, OUs, or the whole AWS organization like deploying resources to certain locations /regions.

Permissions boundaries

Permission boundaries are an advanced IAM feature in which maximum permissions that an identity-based policy can grant to an IAM principal can be derived. When you set a permissions boundary for a principal, the principal can perform only the actions that are allowed by both its identity-based policies and its permissions boundaries.

It’s a type of identity-based policy that doesn’t directly grant access but instead provides fine-grained access control. A permissions boundary is typically used to delegate the creation of IAM principals. Delegation enables other individuals in your accounts to create new IAM principals but limits the permissions that can be granted to the new IAM principals.

Identity-based policies

Identity-based policies are policy documents that you attach to a principal to control what actions a principal can perform, on which resources, and under what conditions. Identity-based policies can be further categorized into three

• AWS-managed policies –  Reusable identity-based policies that are created and managed by AWS, can be used to build specific policies
• Customer-managed policies – Reusable identity-based policies that can be attached to multiple identities.  It is useful when you have multiple principals with identical access requirements.
• Inline policies- Inline policies are identity-based policies that are attached to a single principal. It is used to create least-privilege permissions that are specific to a particular principal.

Resource-based policies

Resource-based policies are policy documents that can be attached to a resource such as an S3 bucket. These policies grant the specified principal permission to perform specific actions on that resource and define under what conditions this permission applies. Resource-based policies are inline policies.

For resources or workloads spanning multiple accounts, this is optional. Fine-grained access within a single AWS account is typically granted with identity-based policies.

• AWS Key Management Service (AWS KMS) keys
• IAM role trust policies

The above two services are exceptions, both resources must have a resource-based policy even when the principal and the KMS key or IAM role are in the same account. IAM roles and KMS keys behave this way as an extra layer of protection that requires the owner of the resource to explicitly allow or deny principals from using the resource.