Search for a command to run...
Do you find AWS IAM User Groups, Policies, or Roles confusing? It's all about who can access what.
An architect by trade, practicing architecture in the Cloud. 7x AWS Certified, AWS Community Builder, Serverless advocate, Vue enthusiast.
A clean serverless pattern for streaming real-time AI workflow responses with Server-Sent Events and AWS Lambda
Emails not reaching the inbox due to template Rendering Failure
A secure, efficient, and hassle-free way to run data analytics queries
How to run your AWS Lambda functions with a fixed IP up to 10x cheaper.
Using the API Gateway - SQS integration to create scalable webhook listeners and validate the requests at the API Gateway level
Amazon Web Services (AWS) Identity and Access Management (IAM) controls who can use our AWS resources (authentication) and what they can do with those resources (authorization).
Think of your AWS account as an office building, you're the owner.
Your building has great amenities such as a gym, a fancy cafe, an underground garage, an electric car charging station, conference rooms, a technical room, and so on. Those are the AWS resources.
You don't want just anyone to be able to come into your building use the gym, grab a coffee, and mess stuff in the technical room, right?
So, you have locks on the doors and you only give an access card to people you trust, like your company employees or contractors.
AWS IAM works in a similar way, AWS resources have "locks" and require permissions to be accessed.
You can then give users (or programs) "keys" to access your AWS resources.
You can give different keys to different users or programs, and you can also decide what they can do with your resources.
General Concepts:
IAM User - an identity type - single principal (human or an application)
IAM User Group - a collection of users
IAM Role - an identity type - multiple principals (human, application, AWS service)
IAM Policy - a document specifying permissions
Some examples of AWS resources include EC2 instances, S3 buckets, RDS databases, Lambda functions, etc.
The IAM User is a user account that is created within the AWS IAM system.
Each IAM User is given a unique username (within your AWS account) and can authenticate themselves using an access key and/or a password.
The access key is for programmatic access - users that will access your resources via AWS API, CLI, or SDK using an access key ID and secret access key.
The access key is usually for technical users such as developers, sys admins, and other applications (e.g. GitHub).
The password is for AWS Management Console - users that will access your resources via a graphical interface.
An IAM User has no permissions by default but can have both access types enabled, access key and password.
IAM User Groups are like a club that the IAM Users join and get special privileges to do certain things. For example, all IAM Users in the "DB Managers" group have permission to add and change things in a database.
So, IAM User Groups are a way to manage and organize IAM Users.
You can create groups and assign users to them, and then apply IAM policies to the group to grant or restrict access to AWS resources.
This is a useful way to manage permissions for large numbers of users, as you can make changes to the group policy and have it apply to all users in the group.
It is also a way to simplify the process of granting permissions to new users, as you can simply add them to the appropriate group instead of having to individually assign permissions.
Okay, so think of IAM Policy as a document that contains all the actions you're allowed to perform, or not.
For example, your HVAC contractor will have a policy that allows access to the building but only to the underground garage, the technical room, and the roof.
Similarly, by creating different IAM policies for different IAM users or groups, you can control who has access to which resources in your AWS account.
This helps you make sure that only the right identities have access to the resources they need, and helps you keep your AWS account secure.
IAM policies are written JSON and tell AWS which actions a user or group of users is allowed to perform on which resources.
In the example below the IAM User that has attached that IAM Policy will only be allowed to view the yearly-report.xlsx file from the reports S3 bucket. They won't be able to view the other files or update the report.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowLatestReport",
"Effect": "Allow",
"Action": ["s3:GetObject"],
"Resource": "arn:aws:s3:::reports/yearly-report.xlsx"
}
]
}
IAM Role is probably the most confusing type of identity, at first.
Remember the cafe in your office building? A catering company supplies it with food and drinks daily and manages the service of the cafe equipment. The number of delivery agents can vary and they're not the same each day, and sometimes they bring in a technician.
You trust the catering company employees to assume the "catering" role and obtain temporary access to the underground parking, the elevator, and the cafe to do their job.
An IAM Role works similarly, it's used to grant specific privileges to specific entities for a set duration of time.
An entity can assume a role only if it's allowed by the Trust Policy.
Each time a role is assumed the entity will get assigned a set of temporary (up to 12 hours) security credentials that will allow to access the AWS resource if that's allowed by the Permissions Policy.
For example, you can have all the EC2 Instances in your account assume an IAM Role that will allow writing logs and metrics into AWS CloudWatch. You don't have to do that individually.
Use IAM User when you can identify the single principal to that you want to grant specific privileges for the longer term.
The IAM User can be a human or an application. They will authenticate using an access key id & secret access key or username & password and be authorized by the IAM Policy to perform certain actions on AWS resources.
Use IAM Role when you have multiple principals or when you don't know the number of entities that you want to temporarily grant specific privileges.
The entity assuming an IAM Role can be an IAM User or Group, an AWS service or account, a federated identity, etc.
The entity can assume an IAM Role only if it's specified in the role Trust Policy, and then it will be authorized by the IAM Policy to perform certain actions on AWS resources.