All you need to know about AWS IAM roles

Imagine a hospital where various health care professionals—doctors, nurses, and technicians—work together to save lives. Each of these professionals has a specific role that grants them access to certain areas and resources within the hospital.

For instance:

• Surgeons have full access to the operating rooms and surgical tools.

• Pediatricians can access the children's ward but not the operating room.

• Nurses assist in multiple areas but don’t perform surgeries.

• Pharmacists manage the medicine inventory but don’t interact with patients directly.

• Janitors have access to all areas for cleaning but don’t interact with medical records or equipment.

Just as structured access in a hospital ensures everyone can perform their duties effectively, AWS IAM roles provide precise access control to resources, enabling secure and efficient operations in the cloud.

Regarding AWS, IAM roles define who (or what) can access specific resources and what actions they can perform. One of the biggest advantages of cloud computing is the on-demand availability of resources. This accessibility allows organizations to reduce on-premises costs and use a wide range of services without worrying about physical infrastructure. However, this convenience also introduces security challenges, as these resources can be vulnerable without strict access controls.

Resources must be tightly controlled to address these risks, granting access only to authorized users with a genuine need. Organizations face significant risks without proper checks and balances on resource access, including unauthorized data exposure, security breaches, and resource misuse. This can lead to increased costs, uncontrolled resource usage, compromised financial stability, and potential compliance and security vulnerabilities.

This is where Identity and Access Management (IAM) comes into play, providing a way to define who can access specific resources and what actions they can take. Each cloud provider has its own IAM solution to control access effectively: AWS offers AWS IAM, Azure provides Microsoft Entra ID, and Google Cloud includes Google Cloud IAM.

In this blog, we’ll explore AWS IAM with a specific focus on IAM roles, exploring what they are, how they work, and why they’re crucial for secure cloud operations on AWS.

AWS IAM#

AWS Identity and Access Management (IAM) is a powerful web service designed to secure and manage access to AWS resources. AWS IAM works by setting up fine-grained controls over who can access specific AWS resources and what actions they’re allowed to perform. It ensures that only authorized users—individuals, applications, or services—can access designated resources, like verifying credentials at the event entrance.

IAM roles take this concept a step further, offering temporary access to resources for specific tasks so that users and applications don’t rely on long-term credentials. This approach boosts security while allowing you to manage access across AWS services and users efficiently and securely.

Core components of IAM#

AWS IAM is built around several key components that enable robust access management. Here’s a quick look at each:

• Users: Individual accounts representing people or applications with unique credentials for accessing AWS resources.

• Groups: Collections of users that share similar permissions, making it easier to manage access by grouping users based on roles or responsibilities.

• Roles: Temporary access permissions for users or AWS services allow secure resource access without long-term credentials.

• Policies: JSON-based documents that define what actions are allowed or denied for users, groups, and roles within AWS.

• Access analyzer: A tool that helps monitor and analyze permissions, identifying resources that may be unintentionally exposed outside your account.

• Identity providers: External identity sources, like Microsoft Active Directory or Google, allow users to authenticate and access AWS resources without creating separate AWS credentials.

These core components control who can access what in your AWS environment, ensuring security and compliance across your resources.

IAM roles#

IAM roles are a flexible way to manage access to AWS resources. Roles are not attached to a particular entity, unlike IAM users, which are tied to specific individuals. Instead, they can be assumed by any trusted user, application, or service—either within your AWS account or from external accounts. IAM roles are ideal for granting temporary, secure access to AWS resources without sharing long-term credentials. A role is not attached to a specific entity and can be used by multiple entities simultaneously to get the required access.

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

But how do IAM roles provide restrictive access? To understand this, we must examine the policies attached to the role.

Policies associated with an IAM role#

IAM role dictates the scope of permissions of the role and the entities that are allowed to use the role using the following two policies:

• Trust policy: This resource-based policy specifies the entities allowed to assume 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.

• Permissions policy: This identity-based policy specifies the permissions of the role.

Types of IAM roles#

AWS IAM roles are designed to provide secure, temporary access to AWS resources based on specific use cases. Let’s break down the main types of IAM roles based on the use case:

Service roles#

These roles are created for AWS services like EC2 or Lambda to perform actions on your behalf. For example, you can assign an IAM role if an EC2 instance needs access to files in S3. This role grants the necessary permissions (e.g., read, write, or delete objects in specific S3 buckets) without requiring long-term credentials to be stored on the instance, enhancing security by avoiding hardcoded credentials.

Cross-account roles#

Cross-account roles enable secure access between different AWS accounts, making them ideal for organizations managing multiple accounts across departments or projects. These roles allow users in one account to assume a role in another without sharing long-term credentials.

For instance, a developer in account A can use a cross-account role to access resources in account B, facilitating tasks like deploying applications or securely accessing shared resources. You can grant access without sharing long-term credentials by creating a cross-account role.

Federated roles#

Federated roles enable users from external identity providers, such as Active Directory or Google, to access AWS resources without needing individual AWS credentials. This is particularly useful for organizations with established user directories, allowing them to extend access seamlessly.

For example, an employee from a partner organization can use their existing credentials to assume an IAM role and gain temporary access to your AWS resources.

Assumed roles#

These are temporary roles that users or applications can assume to access resources as needed without needing long-term credentials. For instance, a developer could temporarily assume an admin role to perform certain tasks, adding an extra layer of security by reducing the risk of misuse over time.

Service-linked roles#

Service-linked roles are pre-defined IAM roles created and managed by AWS services, specifically designed to work with that service. These roles simplify permissions management because they come with all the necessary permissions to perform operations on behalf of the AWS service they are linked to. For instance, Amazon RDS can create a service-linked role that grants it permissions to back up databases or monitor performance without requiring you to manually configure permissions.

The illustration below shows the ECS service-linked role (AWSServiceRoleForECS), which allows Amazon ECS to perform operations on our behalf, such as registering tasks with load balancers, pulling images from ECR, scaling tasks, and sending logs to CloudWatch. AWS automatically creates and manages this role, simplifying permissions and ensuring secure integration with other AWS services.

These roles enable flexible access control, allowing users, applications, and services to interact with AWS resources securely and according to your organization’s specific requirements.

Example scenario#

Let's consider a scenario where an organization operates multiple AWS accounts for different business units. The Development account (Account A) manages EC2 instances, while the Production account (Account B) stores critical data in S3. Developers in Account A need temporary access to specific S3 buckets in Account B to fetch data during deployments. Additionally, the organization uses an external monitoring service that requires limited access to both accounts to monitor system health.

We would need to fulfill the following requirements:

• Developers in Account A need secure, temporary access to S3 buckets in Account B.

• The external monitoring service requires permissions to gather metrics but should only access specific resources.

So, let’s create one IAM role for monitoring service and the other for cross-account access to the resources.

IAM role 1: Service role for monitoring service#

We’ll need a service role in each account for the external monitoring service. This role will allow the monitoring system to collect logs and metrics securely.

The role will have the external monitoring service as the trusted entity, which will monitor the logs of the resources that CloudWatch generates. The permissions for the role will look like:

• Line 5: The Effect statement in the first block grants permission to the action listed in the Action block on line 7 (cloudwatch:PutMetricData), allowing the user or service to publish custom metricsMetric data represents the numerical values or statistics collected over time to monitor the performance and health of resources or applications in AWS. to CloudWatch.

• Line 9: The Resource statement in the first block specifies that the cloudwatch:PutMetricData action is restricted to a specific metric within the namespace, defined by the ARN in the format arn:aws:cloudwatch:region:<Account_ID>:<metric-name>/<namespace>.

• Line 14: The Effect statement in the second block grants permission to the listed actions in the Action block on lines 16–17 (logs:CreateLogStream and logs:PutLogEvents), enabling the creation of log streams and uploading log events to CloudWatch Logs.

• Line 19: The Resource statement in the second block indicates that the logs:CreateLogStream and logs:PutLogEvents actions are restricted to a specific log groupLog groups are logical containers in Amazon CloudWatch Logs that organize and store log events generated by resources like EC2, Lambda, or other AWS services. and its streams, defined by the ARN in the format arn:aws:logs:region:<Account_ID>:log-group:<Log_Group_Name>:*.

We’ll create a log group and associate the resources we want to monitor with that log group. We can restrict the metrics we want the external service to access with the metric data permission. This policy enforces strict access control by limiting actions to specific CloudWatch metrics and log groups instead of all resources in the account.

The monitoring service assumes this role, obtaining temporary credentials to push metrics and logs without needing static AWS keys.

IAM role 2: Cross-account role for developer access#

We will configure a cross-account role in Account B (Production) to grant developers in Account A temporary access to specific S3 buckets.

The trusted entity for this role will be Account A, and the policies for the role are as follows:

Access policy#

• Line 7: The s3:GetObject permission in the action section allows access to the bucket's contents.

• Lines 10–13: We restrict access to objects in the S3 bucket with the name production-data-bucket while restricting access to all other buckets.

Note: If we use * instead of specifying production-data-bucket in the resources section, the developer would have access to all buckets in the account, exposing them to the entity.

Trust policy#

Next, we need a trust policy to specify that only Account A can assume this role. For that, we’ll need a trust policy:

• Lines 6–7: Specifies who can assume the role. Here, the principal is the root identity (all users and roles) of the AWS account identified by arn:aws:iam::<AccountA-ID>:root.

Security best practices for IAM roles#

Implementing security best practices for AWS IAM roles is crucial for protecting your cloud environment and sensitive data. Here are some essential strategies to enhance the security of your IAM setup:

Principle of least privilege#

The principle of least privilege (PoLP) is a fundamental security concept that dictates that users, applications, and services should only be granted the minimum level of access necessary to perform their tasks.

To implement this principle effectively:

• Regularly evaluate the permissions assigned to each IAM role and ensure they align with current job functions.

• Avoid granting broad permissions or using wildcard characters (e.g., *) in policies, as this can inadvertently expose sensitive resources. Instead, define specific actions and resource ARN (Amazon Resource Names) to limit access.

Use IAM roles over long-term credentials#

One key advantage of IAM roles is that they provide temporary access without relying on long-term credentials. Long-term credentials, such as IAM user access keys, can pose security risks if exposed or compromised.

Regular review of IAM roles and policies#

Maintaining an effective security posture requires monitoring and reviewing IAM roles and policies. Regularly auditing IAM configurations helps identify unused roles, overly permissive policies, and potential security gaps.

Establish a routine to review IAM roles at least quarterly, focusing on:

• Unused roles: Identify, deactivate, or delete roles no longer needed to reduce the attack surface.

• Policy attachments: Ensure that policies are aligned with the principle of least privilege and do not provide excessive permissions.

• Role assumptions: Review which users or services assume roles and validate that those accesses are still appropriate.

Monitoring and auditing access with CloudTrail#

AWS CloudTrail is a powerful tool for monitoring and auditing API calls made within your AWS account. CloudTrail logs continuously monitor and retain account activity related to IAM roles, providing valuable insights into how resources are accessed and by whom.

With CloudTrail, you can:

• Track changes: Monitor changes to IAM roles and policies, helping you identify unauthorized modifications or suspicious behavior.

• Analyze access patterns: Review access logs to understand how roles are being used, which can reveal potential misuse or access violations.

• Set alerts: Integrate CloudTrail with AWS CloudWatch to set up alerts for unusual access patterns, such as failed login attempts or access from unexpected IP addresses.

Implementing these security best practices for IAM roles helps protect your AWS resources and fosters a culture of security awareness within your organization. By keeping IAM roles and policies in check, you can proactively address potential vulnerabilities and maintain a secure environment.

Additionally, monitoring and auditing access using AWS CloudTrail provides a significant advantage by offering detailed logs of API activity, enabling you to detect unauthorized access, troubleshoot issues, and ensure compliance with organizational security policies

Test your knowledge of IAM roles#

Conclusion#

Implementing IAM roles is highly recommended for establishing secure, fine-grained access control within AWS environments. By using IAM roles, organizations can minimize the risk of long-term credential exposure, enforce the principle of least privilege, and securely manage temporary access for users, applications, and services. Roles enable administrators to control permissions precisely, granting only the necessary access for specific tasks while ensuring robust security and compliance. Embracing IAM roles as a core practice strengthens an organization’s security posture, reduces vulnerability to unauthorized access, and enhances overall operational efficiency across cloud resources.