All Notes
AWS
AWS
  • AIM
  • General Stuff about AWS
  • AWS Global Infrastructure
  • Interacting with AWS
  • AWS Identity and Access Management
    • AWS Organizations
    • Users
    • Policies and Permissions
    • Groups and Roles
    • Federation
    • Access Control (via available tools)
    • AWS Cognito
    • AWS IAM Identity Center
  • Networking and Content Delivery in AWS
    • AWS VPC
    • AWS Route 53
    • Elastic Load Balancing
    • AWS CloudFront
    • Amazon API Gateway
  • AWS Storage Services
    • Amazon EBS
    • Amazon EFS
    • Amazon FSx
    • S3
    • AWS Databases Services
      • Amazon RDS
      • Amazon DymanoDB
      • Amazon Elasticache
      • Amazon RedShift
      • Amazon DocumentDB
  • AWS Compute Services
    • EC2
    • Elastic BeanStalk
    • AWS Lambda
    • Container Services
      • ECR and ECS
      • EKS
      • AppRunner
  • Other AWS Services
    • CloudFormation
    • AWS Key Management Services (KMS)
    • AWS Secrets Manager
    • AWS Certificate Manager (ACM)
    • AWS Messaging Services
      • AWS SNS (Simple Notification Service)
      • AWS Simple Queue Service (SQS)
    • AWS Systems Manager
      • Application Management
      • Node Management
    • Logging and Monitoring
      • AWS CloudTrail
      • AWS CloudWatch
    • AWS Macie
    • AWS Inspector
    • AWS GuardDuty
Powered by GitBook
On this page
  • IAM Groups
  • Group Creation
  • IAM Roles
  • Service Role
  • Role Creation
  • PassRole
  • Delegation - For Cross Account Access
  • Effective Use case
  • Revoking a session
  1. AWS Identity and Access Management

Groups and Roles

PreviousPolicies and PermissionsNextFederation

Last updated 6 months ago

IAM Groups

An IAM Group is a collection of IAM Users. This is used to prevent applying common policies (bunch of permissions) to users individually and instead apply them to the group, of which the users will be part of. This works, because the policies are flow down to individual users, as inheritance of the group membership. Hence, any policy changes done to an AWS Group will automatically be reflected to AWS IAM Users within the particular group.

Note that IAM Group doesn't have unique identifier i.e. ARN

There is no concept of group within a group in AWS i.e. Groups nesting is not present

Group Creation

Creating Group with Administrator privileges:

IAM Roles

IAM Roles are temporary permissions given to either people or apps to perform a certain task. Consider IAM Role as a hat, whoever assumes it, gets the permissions attached to the role.

An example of It being particularly useful is to consultants or contractors who join the company for a specific project and don't need permanent access to the client's company.

They are a also popular choice for Applications i.e., whatever application requires, give it via an IAM role.

IAM Role can be assigned to an AWS service or AWS IAM user account (same account or even different AWS account) or a federated identity (both Web based or SAML 2.0).

Benefits:

  • No long term credential

  • No requiring embedding of permanent credentials to applications

  • No IAM user creation for consultants/contractors or other AWS account users

  • Allows for federation

AWS AssumeRole enables entities like IAM users or AWS services to temporarily acquire the permissions and access rights of another AWS entity by assuming a specific role. This delegation is defined through a trust policy, which specifies the trusted entities that can assume the role.

Here’s how it works:

  1. An entity requests to assume a role by calling the AssumeRole API operation or assumes the role via the AWS Management Console.

  2. AWS validates the entity’s permissions against the trust policy attached to the role. The trust policy specifies who can assume the role, typically within the same or different AWS accounts.

  3. Once authorized, AWS generates temporary security credentials for the entity, granting access based on the permissions defined in the role’s policies.

  4. The entity can now perform actions and access resources using the temporary credentials, limited to the permissions of the assumed role.

To assume an IAM role, one needs a trust relationship that will be configured in trust policy. Just like MSFT Active Directory, there is a trusting account (whose resources are accessed) and there is trusted account (that contains the users accessing the resources of the trusting account).

So, to summarize, for IAM Roles to be effective, there are two types of Policy that are required:

  • Permission Policy - Define what actions and resources for an IAM Role

  • Trust Policy - Define who is allowed to assume an IAM Role. Note in trust policy, another role is also allowed, i.e. role within a role or role chaining.

A Trust policy looks as below:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::123456789012:user/AnotherUser"
            },
            "Action": "sts:AssumeRole"
            "Resource": "arn:aws:iam::123456789012:role/Role-A"
        }
    ]
}

Service Role

AWS services assume the service role to perform action on user's behalf. Two types of service roles, with the difference between the two is that one is user defined (service role) and other can be AWS predefined (example EC2 Autoscaling, CloudFormation etc). Note it is usually not possible to delete AWS managed Service-linked policy even by the root account

Note that instead of creating long term credentials, as shown in the above image, the EC2 instance profile assumes an role that has access policy to S3 buckets. So, by the virtue of presence of applications on the EC2 instances, they are able to generate temporary credentials to access S3. Here, the EC2 has that trust relationship in form of service role, this means that if tomorrow instead of XYZ application, ABC application gets deployed on that EC2 instance, they will still be able to access the S3 bucket as they are associated with the EC2 rather than long-term credentials which can be hardcoded in the application. This also means, if more than one application is hosted on EC2, every app would be able to access the s3 bucket.

Basically, the applications access the s3 bucket using IMDS (Instance Metadata Service) endpoint on a link-local address of 169.254.169.254 to get short term credentials at runtime and access s3 using that.

Role Creation

Note, for role creation, first ensure that AWS Policy is created as shown on below link:

The sample role can then be attached to an IAM role in EC2 as shown below during EC2 instance launch configuration:

Note that you can also attach the role in existing EC2

PassRole

There is something called IAM:PassRole, which allows users to delegate permissions in form of Roles to AWS Services so that they can access other resources or AWS Service. Note that usually the IAM Admin create these roles and allow users to delegate the role to AWS services. Visually, it can be demonstrated as follows:

// Generated by ChatGPT

[ User/Service ] --( PassRole )--> [ IAM Role (EC2ReadS3Role) ]
        |                                           |
        |                                           v
        |                                  [ EC2 Instance ]
        |                                           |
        |------------------------------------------> [ S3 Bucket ]

Delegation - For Cross Account Access

Just like in MSFT's Active Directory, there is concept of delegation in AWS, i.e., permissions can be given to resources a user controls. As said earlier, the resource holding account is trusting account and users of the account who will access are trusted accounts and therefore trust policy is gonna be required. So, in short, cross account Role is used for delegation

Effective Use case

IAM services can interact with each other using IAM Role example: AWS Serverless LAMP stack

Revoking a session

Sometimes due to unforseen circumstances, an IAM Role assumed session has to be revoked. AWS does that by attaching explicit deny to that session, so that when any action is evaluated, it would be denied

Steps are not given as it requires opening and signing up another AWS account, so due to economical constraints, request you to follow the guide .

Follow the steps to revoke the steps from here:

here
https://www.linkedin.com/pulse/aws-under-hood-day-10-how-revoke-temporary-iam-exposed-lakhera-efa7c
https://notes.radifine.com/aws/aws-identity-and-access-management/policies-and-permissions#policy-creationnotes.radifine.com
Source:
Source:
Source:
Source:
Source:
https://miro.medium.com/v2/resize:fit:640/format:webp/1*e_faUe39DVwrnAlg2nSOfg.png
https://anjanashankar.com/2021/05/20/role-based-access-aws/
https://anjanashankar.com/2021/05/20/role-based-access-aws/
https://d2908q01vomqb2.cloudfront.net/1b6453892473a467d07372d45eb05abc2031647a/2020/06/01/Screenshot-2020-06-01-at-17.59.43.png
https://docs.aws.amazon.com/images/IAM/latest/UserGuide/images/roles-usingrole-ec2roleinstance.png