Groups and Roles
Last updated
Last updated
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
Creating Group with Administrator privileges:
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:
An entity requests to assume a role by calling the AssumeRole API operation or assumes the role via the AWS Management Console.
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.
Once authorized, AWS generates temporary security credentials for the entity, granting access based on the permissions defined in the role’s policies.
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:
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.
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
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:
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
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 here.
IAM services can interact with each other using IAM Role example: AWS Serverless LAMP stack
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
Follow the steps to revoke the steps from here: https://www.linkedin.com/pulse/aws-under-hood-day-10-how-revoke-temporary-iam-exposed-lakhera-efa7c
