AWS IAM Policy

An IAM policy is a JSON document that specifies permissions. Policies can be reused with different services in AWS. The same policy can be assigned to different people and teams. Policies are of two types in AWS:

• AWS Managed Policies: These are the policies that are provided by default in AWS. These consist of the commonly used services and the read and write permissions associated with them.
  
• Customer-Managed Policies: In case a user needs a policy that should meet their specific needs and use cases, then they can build their custom policies.
  
• Multi-Factor Authentication (MFA): For an added layer of security, IAM supports MFA, which requires users to provide a second form of authentication (like a one-time password) in addition to their regular credentials.
  
• Granular Control Using Policies: IAM policies are JSON-based documents that allow you to control access at a granular level. You can apply these policies to users, groups, or roles to define what actions they can take on specific AWS resources.
  
• Identity Federation: IAM supports identity federation, which allows users outside of AWS (like those from your organization’s Active Directory or third-party identity providers) to access AWS resources without needing a separate IAM user account

Policies and Permissions in AWS Identity and Access Management

In AWS IAM policies are the backbone of managing permissions. These policies specify what actions are allowed or denied on AWS resources, helping you enforce security and control. Policies can be attached to IAM users, groups or roles and they enable you to implement the principle of least privilege allowing users to perform only the tasks they need.

Types of IAM Policies

There are several types of policies in AWS IAM each serving different purposes:

1. Managed Policies

• AWS Managed Policies: These are pre-built policies created and maintained by AWS. They are designed to simplify permission management by providing a wide range of commonly used permissions for AWS services. Since AWS manages these policies, they are regularly updated and maintained by AWS, ensuring they follow best practices.
  
• Customer Managed Policies: These are custom policies created and managed by you. Customer managed policies offer greater flexibility as you can define specific permissions based on your requirements. You can reuse these policies across multiple users, groups, or roles within your AWS environment.

2. Inline Policies

• Inline policies are directly embedded into a single IAM user, group, or role. They offer a one-to-one relationship, meaning that the policy is tied specifically to that entity. While inline policies provide granular control, they are not reusable across different users or roles, making them less flexible than managed policies.

3. Resource-Based Policies

• Unlike the first two types, which are attached to users, roles, or groups, resource-based policies are attached directly to AWS resources, such as S3 buckets, Lambda functions, or SNS topics. These policies define which principals (users, roles, or services) are allowed to access the resource and what actions they can perform. Resource-based policies are useful for controlling cross-account access to resources.

4. Permission Boundaries

• These are advanced policies that set limits on the maximum permissions an IAM user or role can receive. Permission boundaries do not grant any additional permissions but act as a restriction, ensuring that policies attached to a user or role do not exceed the boundaries. This is particularly useful for delegating permissions to others while maintaining control over security.

5. Service Control Policies (SCPs)

• SCPs are used in AWS Organizations to manage permissions for all accounts within an organization or organizational unit (OU). They define the maximum level of permissions that can be assigned to any user, role, or group within the accounts governed by the organization. SCPs help ensure compliance and governance across multiple AWS accounts.

Permissions in AWS IAM Policies

Permissions within an IAM policy define what actions are allowed or denied for specific AWS resources. The policy includes the following elements:

• Actions: Specifies the API operations (like s3:PutObject or ec2:StartInstances) that the policy allows or denies.
• Resources: Defines the specific AWS resources the policy applies to (like an S3 bucket or EC2 instance).
• Effect: Determines whether the action is allowed (Allow) or denied (Deny).
• Conditions: Optional, but they add an additional layer of control by specifying conditions under which the policy is in effect (for example, restricting actions based on the requester's IP address or the time of day).

IAM Policy Document Structure

To fully understand the structure of an IAM policy, let us see the default template provided by AWS and look at all the fields one by one.

1. Version-ID: This is a compulsory field in a policy that is uniquely used to identify a JSON policy.
2. Statement: It defines the permission for a single resource.
3. Sid: Is short for statement id. It is a unique identifier for a statement.
4. Effect: It defines the Allow/Deny prospects to a resource.
5. Action: This is used to state what service can perform what all actions.
6. Resource: It consists of the list of resources that are impacted by the policy.

For example, below is the policy for an Auto Scaling Service, that allow read permission on all resources:

Now, if you attach this iam policy to an Auto Scaling Group (ASG) service that you provision, that particular instance of ASG would have read permission on all resources.

Creating a New Policy or Use an Existing

Step 1: Open the AWS Management Console

Step 2: Search for IAM in the search bar and Click the IAM icon

Step 3: Navigate to the Policies section

Step 4: Choose the policy you want to use

Step 5: Create the policy according to your needs if there isn't one.Click on the 'Create Policy' Button.

Validating IAM Policies

AWS offers IAM Access Analyzer with enhanced policy checks and recommendations to optimize your policies. When creating or editing a policy in the JSON tab, a policy validation pane appears below, highlighting various findings. These findings are categorized into Security, Errors, Warnings, and Suggestions, helping you identify potential issues. You can use this information to adjust your policy and address the findings to ensure improved security and compliance

The following represents the first step in creating a policy in which you can specify permissions. Choose the 'JSON' button in the navigation bar and the services that you want to create a policy for. Next, list the action you want to add to this policy. After successfully creating the policies, click on the 'NEXT' button.

Next, you can 'Review and Create' the policy.

Hence have we have successfully managed to create a policy.

Versioning IAM Policies

Versioning IAM policies is an important feature that allows you to manage and track changes to your IAM policies over time. AWS Identity and Access Management (IAM) policies are JSON-based documents that define what actions are allowed or denied on specific AWS resources. By implementing versioning, you can ensure better control, security, and flexibility when managing policies in AWS IAM policy versioning allows you to create multiple revisions of a policy and set one as the default version. This feature is particularly useful when you want to make changes to a policy without losing the original version. Each policy can have up to five versions stored, but only one version is considered active or default at a time.

Versioning provides several benefits:

1. Change Tracking: You can keep track of changes made to a policy over time, allowing for easy rollback to previous versions if necessary.
2. Improved Security: With versioning, you can test new policies without directly impacting production environments. Once validated, the new version can be set as the default.
3. Policy Testing: This feature allows you to test and verify changes before making them live, ensuring that the policy works as expected.

Best Practices for Versioning IAM Policies

• Test Before Deployment: When creating a new policy version, it’s good practice to thoroughly test it in a sandbox or development environment before making it the default.
• Maintain a Change History: Use versioning to keep a clear record of changes to your policies. This is useful for audits and troubleshooting.
• Limit Permissions Gradually: When making restrictive changes, versioning allows you to implement new security controls gradually, ensuring minimal disruption to users or services.

Conclusion

Thus, in the above article, we have seen why policies are needed and their importance. Next, we looked at the definition of policies, their types and structures. Then we looked at how we can create a new policy or use an existing one. Though you can use one policy for all your needs, it is generally considered best practice that you create different policies for SDK Access, users, group and services. Also, appropriate naming conventions are very important to help distinguish one policy from another. This way, you can effectively see who has access to what, which is the real need of policies and take away any permission that someone doesn't need anymore.