IAM Role Creation and Management in AWS

An IAM Role is an AWS Identity and Access Management (IAM) identity with specific permission policies that can be assumed by a trusted entity. Unlike an IAM User, a Role does not have its own long-term credentials like a password or access keys.

When a trusted entity assumes a Role, AWS provides it with temporary security credentials for that session. This is the core of its security model: it eliminates the need for static, long-lived keys.

Every IAM Role is defined by two critical policies:

1. Permissions Policies (The "What"): These are the standard JSON policies that define what actions the Role is allowed to perform (e.g., s3:GetObject, ec2:DescribeInstances). This dictates the Role's power.
2. Trust Policy (The "Who"): This is the most important part. The Trust Policy defines who is allowed to assume the Role. The trusted entity, or Principal, can be an AWS service (like EC2), another AWS account, a web identity provider, or a SAML-based identity provider.

The Principle of Least Privilege: A Core Security Tenet

Before creating any permissions, it's crucial to understand the Principle of Least Privilege. This security concept dictates that you should only grant the absolute minimum permissions necessary for an entity to perform its required task, and nothing more.

For example, if an application only needs to read objects from an S3 bucket, its Role should only have the s3:GetObject permission. It should not have s3:DeleteObject or administrative permissions like s3:*.

Why is this so important? It limits the "blast radius." If a resource with a least-privilege Role is ever compromised, the potential damage an attacker can do is severely restricted to only the permissions that Role possessed.

Creating IAM EntityAlreadyExists

EntityAlreadyExists it is an error you may encounters this while your are trying to create an IAM entity such as user, group or role. Following are the steps that are useful to resolve the error.

Step 1: Check for Existing Entity.

Use the following command in the AWS CLI whether the entity with the same name already exists.

aws iam list-users
aws iam list-groups
aws iam list-roles

• Choose a Unique Name
• Delete or Rename Existing Entity
• Check for Deletion in Progress
• Retry the Creation
• Review AWS Service Limits.

Crafting Custom IAM Roles for Your Unique AWS Needs

The following are the methods for using Roles:

1. AWS Management Console 
2. Assume-Role CLI
3. Assume-role-with-web-identity
4. Console URL Construct with AssumeRoleWithSAML

Steps to Create an IAM role for the EC2 Instance

Step 1. First, we need to go to the IAM table Dashboard, and then we will go to the roles option and click on Create roles.

Step 2. Next under trusted entity type we will select AWS services and under Use case, we will select EC2 and click on next.

Step 3. Next under permission policies, we will search for S3 policies and will select S3readonly policy, and click on next.

Step 4. Next we will give our role a name and review all the changes and will click on next.

Now we need to add Permission 

Step 5. Now our IAM roles are created and if we click on the role that we just created we will be welcomed to this screen. Here we can see the details of our role. We can see that our myS3Role has been created.

Step 6. Next, we will go to the EC2 dashboard and create an EC2 instance:

We need to create a new instance 

Step 7. While creating the EC2 instance under configure instance we will select the IAM role that we just created and we will proceed with our EC2 instance creation:

Note: we have to select IAM role we created earlier inside Iam role tab

while creating EC2 in Add storage add 8 GB(GIB) and volume type General purpose SSD

During launching the instance download the key pair RSA file and launch the instance

Step 8. Next, we will connect to the EC2 instance that we just created

Secure Shell also known as SSH is a cryptographic network protocol that helps secure network services over an unsecured network.  It securely helps users to log in to a server with SSH than using a password alone. SSH keys are nearly impossible to decipher by brute force alone unlike passwords

Step 9. Now we will use the command “aws s3 ls” which will then let us see all the S3 buckets we created because we have set the policies of the IAM role to S3readonly through this we can just read our S3 buckets:

Step 10. Now in order to avoid any charges we will delete our ec2 instance and our s3 bucket.

Managing and Rotating IAM Roles

• Naming and Tagging: Always use a clear and consistent naming convention for your roles. Use tags to categorize roles by project, environment, or owner for easier management and cost tracking.
• Regularly Review Permissions: Periodically review the permissions attached to your Roles. Use tools like AWS IAM Access Analyzer to identify overly permissive or unused permissions and tighten them according to the principle of least privilege.
• Automatic Credential Rotation: The key benefit of Roles is that credential rotation is handled for you. When an entity assumes a Role, the AWS Security Token Service (STS) issues temporary credentials that are valid for a limited time. This dramatically reduces the risk associated with stolen or leaked long-term keys.
• Use Custom Policies: While AWS-managed policies are convenient, for production workloads it is a best practice to create your own customer-managed policies that grant only the specific permissions your application needs.

Troubleshooting Common Errors

• EntityAlreadyExists: This error occurs if you try to create a role with a name that already exists in your account. Either choose a unique name or delete the old role if it is no longer needed.
• Access Denied: If an EC2 instance with a role receives this error, it's almost always one of two issues:
  1. The Permissions Policy does not include the specific action the application is trying to perform.
  2. The Trust Policy is misconfigured and does not list the service or entity that is trying to assume the role.