AWS IAM Service

Introduction

IAM (Identity and Access Management) stands out as a global AWS service, distributed across all regions, serving as the foundational service for managing access to resources within your AWS account.

When users seek to perform actions on resources, such as creating an EC2 instance, specific permissions are required. IAM empowers the creation of users and enables precise control over permissions and authorizations through IAM policies.

An IAM User is designated as an identity, and the system introduces two additional identity types: Roles and Groups. These identities provide enhanced flexibility in access management, offering a comprehensive approach to permissions and organizational control.

IAM Policies

An IAM Policy serves as a mechanism to either grant or deny permissions to identities within the AWS environment. These policies, presented in JSON or YAML format, are linked to specific identities.

Once a policy is attached, the associated identity operates strictly within the boundaries defined by the policy. Here's a simple example of an IAM Policy:

In this example, we create an IAM Policy that grants create, stop, and terminate EC2 instances:

Version: This specifies the version of the IAM policy language. In this case, it's set to "2012-10-17," which is a standard version.
Statement: This is an array of policy statements. Each statement in the array represents a set of permissions.
Effect: This indicates that the specified actions are allowed. You could also use "Effect": "Deny" to explicitly deny the actions.
Action: This lists the AWS actions that are allowed. In this case, the policy allows the actions of running, stopping, and terminating EC2 instances.
Resource: This specifies the resource to which the actions apply. Replace your-region with the AWS region code where your instances reside, and replace your-account-id with your AWS account ID. The instance/* at the end indicates that these permissions apply to all EC2 instances (* is a wildcard for any instance ID).

In this example, we are granting permissions specifically for handling EC2 instances. It's important to note that, in IAM, the order of evaluation follows a specific sequence: Explicit Deny, Explicit Allow, and finally, Implicit Deny. This means that if an action is not explicitly allowed for EC2 instances, it will implicitly be denied. Careful attention to this order is crucial for crafting policies to ensure that only intended actions are permitted, and that security measures are in place.

Evaluate multiple policies

when multiple policies are attached to an identity (user, group, or role), the policies are evaluated based on a specific order of precedence. The priority follows these rules:

Explicit Deny Overrides Explicit Allow:

If there is an explicit Deny statement in any of the attached policies, it takes precedence over any Allow statements. This means that if any policy explicitly denies an action, it will override an explicit allow from another policy.

Policy Evaluation Order:

Policies are evaluated based on the order in which they are attached to the identity. Policies attached later in the list take precedence over policies attached earlier.

User Policy vs. Group Policy:

If a user is a member of multiple groups and both the user's policy and group policies grant permissions for the same action, the user's policy takes precedence.

Explicit Allow in a Policy:

If a policy explicitly allows an action, and no other policy explicitly denies the same action, the action is allowed.

Implicit Deny:

If there are no policies attached that explicitly allow an action, and there is no explicit allow at the identity level (e.g., on the user or group), then the action is implicitly denied. It's crucial to design policies carefully to avoid unintended consequences. Explicitly denying specific actions can be a useful security practice, but it requires careful consideration to prevent accidental denial of necessary permissions. Additionally, understanding the order of evaluation helps in crafting policies that align with the desired access control model.

Types of policies

In AWS Identity and Access Management (IAM), there are mainly two types of policies:

Managed Policies

AWS Managed Policies: These are policies created and managed by AWS. You can attach these policies to multiple users, groups, or roles in your AWS account.

Customer Managed Policies: These are policies that you create and manage. You can attach them to multiple users, groups, or roles in your AWS account.

Inline Policies

These are policies that you create and manage directly within a user, group, or role. Unlike managed policies, inline policies are embedded directly into the resource's definition and are deleted when the resource is deleted. Policies, whether managed or inline, define the permissions for identities (users, groups, or roles) in AWS, specifying what actions are allowed or denied on what resources.

IAM Users

An IAM user is the principal identity in IAM. Each user possesses their own set of credentials, including access keys. Users serve as a means of long-term access to AWS resources, enabling human access to the AWS Cloud through the console. Additionally, they can be utilized by applications to access resources via the access that you can create after the user creation process.

Example of creating a user to access AWS S3 via the CLI:

1: Create a user through the AWS console

2: Create Access Keys for the user

Then install the AWS CLI on your machine if it's not already installed and open a Terminal or Command Prompt and type the following command and press Enter

You'll be prompted to enter your AWS Access Key ID and Secret Access Key and specify the AWS region you want to use as the default. Enter the code for your preferred region (e.g., us-east-1).

After entering all information, the AWS CLI will display a message indicating that the configuration was successful.

Now we are ready to try it:

it works 🥳🥳

There is a hard limit of 5000 users per account. To overcome this limitation, IAM roles come into play as another type of identity.

IAM Roles

IAM roles in AWS (Identity and Access Management) are a way to grant permissions to entities that you trust. Roles are not associated with a specific user or group; instead, they are assumed by trusted entities, such as AWS services, applications, or users from other AWS accounts.

Key points about IAM Roles

Purpose: Roles are used to delegate permissions, allowing entities to perform actions in your AWS account on your behalf.

Temporary Credentials: When a role is assumed, it provides temporary security credentials, including an access key, secret key, and session token. These credentials are used to make AWS service API requests.

Cross-Account Access: Roles are commonly used for cross-account access, enabling users or services in one AWS account to access resources in another account.

Service Roles: Roles can be assumed by AWS services. For example, an EC2 instance can assume a role to access other AWS services securely.

Trust Policy: A role has a trust policy that specifies who can assume the role. It defines the trusted entities (AWS accounts, IAM users, or AWS services) that are allowed to assume the role.

Permissions Policy: The role also has an associated permissions policy that defines the actions allowed or denied when someone assumes the role.

Here's an example of a trust policy for a role:

In this example, the role can be assumed by the EC2 service.

Roles provide a secure and flexible way to manage access to AWS resources, especially in scenarios involving third-party applications, cross-account access, and temporary permissions.

IAM Groups

A group is a collection of IAM users. Groups let you specify permissions for multiple users, which can make it easier to manage access in your AWS environment. Instead of attaching policies to individual users, you can attach policies to a group, and users added to that group inherit the permissions.

Key points about IAM Groups

User Management: users can be added to multiple groups, and each group can have different policies attached, allowing for flexible access management. When a user is added to a group, they inherit the permissions assigned to that group.

Policy Attachment: policies are attached directly to groups, and users in the group inherit those policies. This helps in applying a set of permissions consistently to multiple users.

Simplifies Access Management: group membership simplifies access management, especially when dealing with a large number of users who require similar permissions.

No Credentials: a group itself doesn't have credentials or access keys so you can't login to AWS account via a specific group. Users within the group have their own credentials.

Policy Inheritance: users inherit the permissions of all the groups they belong to, as well as any individual policies that are attached directly to the user. IAM groups are a fundamental component of IAM that helps in organizing and managing user permissions efficiently in AWS.

Conclusion

IAM is a vital AWS service, globally distributed, managing resource access. Users, roles, and groups, controlled by IAM policies, offer flexible access management. IAM policies, in JSON or YAML, grant or deny permissions, ensuring secure resource handling. IAM groups streamline access management, providing a cohesive structure for permissions.