IAM Roles

IAM Roles

In this tutorial we are going to explore about the AWS IAM Roles. AWS IAM Roles are identities in AWS that provide temporary permissions for users, applications, or services, allowing them to interact with AWS resources. Unlike IAM users, roles do not have long-term credentials (like passwords or access keys); instead, they provide temporary security credentials, making them a secure and flexible way to grant permissions.

Lets explore how to provide access to your AWS resources to an entity within or outside of an AWS account using IAM Roles.

An IAM role is an AWS identity similar to IAM users with an identity-based policy specifying its access. However, unlike the IAM users, IAM roles can be used to provide access to any entity within or outside the AWS account. A role is not attached to a specific entity and can be used by multiple entities at the same time to get the required access.

IAM Roles

IAM roles provide this access for a limited amount of time in the form of sessions. The maximum time for this session can be 12 hours. By default, the value for this session is one hour. Temporary security credentials are associated with each of these sessions, which expire when the session ends.

Policies associated with an IAM roles

There are multiple policies associated with an IAM role that dictate the scope of permissions of the role and the entities that are allowed to use the role. These policies are as follows:

  • Trust policy: This is a resource-based policy that specifies the entities allowed to assume an IAM role.
  • Permissions policy: This is an identity-based policy that specifies the permissions of the role.
Policies attached with IAM roles

An IAM role can have multiple permission policies attached to it, but there can only be one trust policy attached to it. Also, we can create an IAM role without a permission policy, but specifying a trust policy is required during the creation of an IAM role.

Principal entities for an IAM role

Only the entities that are specified as the principal entities in the trust policy of an IAM role can assume that role. These principal entities are of multiple types. The types of principal entities for an IAM role are as follows:

  • AWS services: An AWS service cannot use another service without proper authorization. That authorization is provided using the IAM roles. The Principal element of the trust policy is set to the service principal of the service in this case.
  • IAM identities: Both IAM users and IAM roles can assume an IAM role to get the permissions provided to that role. The Principal element of the trust policy is set to the ARN of the IAM identity in this case.
Using IAM role to gain access to AWS
  • AWS accounts: Both the current and external accounts can use an IAM role to get the associated permissions. In this scenario, the Principal element of the trust policy is set to the ID of the account.
  • Web identities: Users authenticated by specific external web identity providers can also be the principal entity for an IAM role. In this case, the Principal element of the trust policy is set to the DNS of the identity provider.
  • External users: External users authenticated by an external identity provider (IdP) service that is compatible with SAML 2.0 OpenID Connect or a custom-built identity broker can also be specified as the principal entity in the trust policy of an IAM role.
How IAM roles work

Following is the sequence of steps illustrating how a principal entity utilizes the IAM role:

  • Assuming a role: An entity can assume an IAM role by making an AssumeRole API request or by assuming the role using temporary security credentials provided by another trusted entity.
  • Temporary credentials: When an entity successfully assumes an IAM role, it receives temporary security credentials consisting of an access key ID, a secret access key, and a session token. These credentials are valid for a limited duration specified by the role’s configuration.
Using IAM role to gain temporary access to AWS services

IAM roles are powerful tools for managing access to AWS resources securely. By understanding their purpose and components, we can effectively leverage IAM roles to grant temporary, fine-grained permissions to entities within and outside our AWS account, ensuring secure and efficient resource access.

1. Role Creation

  • Define the role and specify permissions through policies.
  • Specify trusted entities that are allowed to assume the role.

2. Assuming the Role

  • A trusted entity (like an EC2 instance or another AWS account) assumes the role.
  • AWS generates temporary security credentials, allowing the entity to perform the role’s specified actions on resources.

3. Credentials Expire Automatically

  • Temporary security credentials expire after a specified time (up to 12 hours), requiring the entity to re-assume the role to continue accessing resources.
Key Components of IAM Roles
  1. Policies: Policies attached to roles define the permissions, specifying which actions the role can perform on which AWS resources.
  2. Trusted Entities: Trusted entities, also known as principals, are the users, services, or accounts allowed to assume the role. Examples include:
    • AWS services (e.g., EC2, Lambda)
    • AWS accounts
    • Federated users (such as those from corporate directories)
  3. Temporary Security Credentials: When a trusted entity assumes a role, AWS issues temporary security credentials for the role, which include an access key, secret key, and session token. These credentials are time-bound and allow the entity to access resources based on the role’s permissions.
Types of IAM Roles

1. Service Roles

  • Used by AWS services, allowing them to perform actions on your behalf.
  • Example: An IAM role for an EC2 instance enables it to access S3 or DynamoDB without embedding credentials in the instance’s code.

2. Cross-Account Roles

  • Allow access between different AWS accounts.
  • Example: You can create a role in Account A that trusts Account B, enabling users from Account B to access resources in Account A.

3. IAM Role for SAML-Based Federation

  • Enables access for users from an external identity provider (IdP) using SAML (Security Assertion Markup Language).
  • Useful for integrating corporate directories, allowing employees to access AWS without separate AWS credentials.

4. IAM Role for Web Identity Federation

  • Enables users to sign in using web identity providers (e.g., Google, Facebook, Amazon).
  • Commonly used in mobile or web applications where end-users need temporary access to AWS resources.

5. Custom Lambda Roles

  • Designed specifically for Lambda functions, granting them access to other AWS resources.
  • Example: A Lambda role with permissions to read from DynamoDB and write to S3.
    Example Scenario: Using an IAM Role with EC2 to Access S3

    1. Create an IAM Role for EC2

    • Specify that EC2 instances can assume the role.
    • Attach a policy that grants s3:PutObject permission to a specific S3 bucket.

    2. Attach the Role to an EC2 Instance

    • When launching an EC2 instance, assign the created IAM role to the instance.

    3. Access S3 from the EC2 Instance

    • The EC2 instance, using the role’s permissions, can now write files to the specified S3 bucket without hardcoding credentials.
      Benefits of Using IAM Roles
      1. Enhanced Security: Roles use temporary security credentials, reducing risk if credentials are compromised.
      2. Simplified Credential Management: No need to store or rotate credentials manually; AWS automatically handles credential creation and expiration.
      3. Cross-Account and Cross-Service Access: Roles enable seamless access between accounts and AWS services, making it easier to manage permissions across different entities.
      Best Practices for IAM Roles
      1. Follow the Principle of Least Privilege: Grant only the permissions required by the role.
      2. Use Roles for Applications Instead of Hardcoded Credentials: This makes your applications more secure and easier to manage.
      3. Regularly Review and Audit Role Policies: Ensure that permissions align with current requirements and reduce unnecessary access.
      4. Enable Logging and Monitoring: Use CloudTrail to monitor role usage and detect any suspicious activity.
      5. Apply Conditions Where Possible: Add conditions (e.g., based on IP, time of day, or MFA) to further restrict permissions.

      IAM roles are a powerful and flexible way to manage permissions in AWS, allowing you to securely and easily grant access to resources across services, accounts, and external providers.

      That’s all about the IAM roles. If you have any queries or feedback, please write us at contact@waytoeasylearn.com. Enjoy learning, Enjoy AWS Tutorials.!!

      IAM Roles
      Scroll to top