Mastering Access Control in AWS: IAM Roles for Enhanced Security
Overview
In a given scenario, one AWS resource is attempting to access, create, or modify another AWS resource. For instance, as depicted in the image below, three EC2 instances (AWS resources) are attempting to access an S3 bucket (another AWS resource).
IAM Role
An IAM Role is similar to the IAM user. It allows you to provide access from an AWS service resource to another service resource without the access keys. Be known that an IAM Role does not have the credentials like password, access key, and secret access key, but gains temporary credentials. It is much recommended to use IAM Role when providing access between AWS service and resources.
IAM Policy
There is another entity in AWS known as an IAM policy. An IAM policy is a JSON-formatted object in AWS. It can contain multiple statements that allow or deny access to a set of AWS resources and associated actions. These statements are referred to as Permissions Policies, which serve as access control rules. They are depicted in the image below.
Once policy is created we can attach it with any other IAM entity such as IAM user, IAM group or IAM role as shown below
There are three types of IAM policies:
- Customer Managed Policies: These are policies that are custom-written according to specific requirements.
- AWS Managed Policies: These are ready-made policies provided by AWS to simplify the process. These policies are designed to make our tasks more convenient.
- AWS Managed Job Function Policies: These policies are tailored for specific job roles. For instance, if we need to grant someone administrative privileges, or if a person in our organization is a data scientist, these policies are designed to provide the necessary permissions for their role and responsibilities.
Permission Boundary
It imposes restrictions on the available permissions. However, the permissions specified in the policy are necessary. As shown in the illustration below, Joanne has full permissions for the IAM service, but due to the permission boundary’s “restriction on the granted permissions,” she is unable to create an IAM user, as the permission boundary does not permit this action.
AWS organizations and AWS SSO
AWS IAM operates at the account level, but in an organization with numerous AWS accounts created for individuals across diverse teams, orchestrating control at the organizational level becomes crucial. The approach for overseeing all these accounts collectively is illustrated below: Account 1 and 2 fall under the Training Team, while Account 3 and 4 are under the Dev Team. All these accounts are interconnected with Account 5, which serves as the root account.
This structural setup offers several advantages. For instance, consolidated billing for Account 1, 2, 3, and 4 can be efficiently managed through Account 5, the root account. Furthermore, access management can be centralized, empowering the allocation of permissions to different organizational units via the root account.
Up until now, we have delved into IAM roles, IAM policies, permission boundaries, and AWS organizations. We’ve covered the concept of IAM roles, and now it’s time to delve deeper into this aspect of IAM roles.
Usecase of IAM Role
In the presented scenario, our application is deployed on an EC2 instance, and frequently, sensitive “secrets/keys” are incorporated within the application source code. Subsequently, the application employs these keys to authenticate various AWS services, such as S3 buckets in our case. Unfortunately, there are instances when developers store this code on open-source repositories such as GitHub, Bitbucket, and others. Regrettably, this leads to the inadvertent exposure of these keys/secrets along with the code. Consequently, unauthorized individuals might exploit these keys to gain access to our AWS services. This poses a substantial security risk that needs to be addressed.
To address this security concern, AWS has introduced an ingenious solution using IAM roles. This involves associating an IAM role with our EC2 instance, which then grants temporary access keys to authenticate with an S3 bucket. One of the remarkable features of an IAM role is its ability to automatically rotate these credentials periodically.
This approach eliminates the need to store access keys within our application’s source code. Instead, the IAM role securely provides these keys at a designated location within the EC2 instance. When our application initiates an API call to the S3 bucket, it can seamlessly utilize the keys or secrets furnished by the IAM role.
This strategy not only enhances security but also streamlines the management of access credentials, offering a more robust and convenient way to interact with AWS resources.
