AWS Identity and Access Management deep dive series
AWS Identity and Access Management (IAM) is a web service that helps you securely control access to AWS resources. You use IAM to control who is authenticated (signed in) and authorized (has permissions) to use resources.
AWS IAM is such an important service and it can be considered as a foundational service for any other AWS operations and services.
In cloud computing era, the importance of identity and access management is recognized greatly by cybersecurity industry. In my personal opinion, it is definitely one of the first service you should learn before start using other AWS services.
In my cloud engineer journey, I’ve seen too many times that best security practice rules got broken and AWS access keys and secrets got compromised and caused big damage.
The most notable case of keys being compromised through this method is from the 2016 breach of Uber, where attackers gained access to a Git repository of Uber’s and were able to pull AWS credentials that were being stored in it (source).
Imagine one day, when you wake up and check your email, one of the following email showed up in your mailbox, how would you feel?
What if the actual amount was $1M dollars? Will you regret not learning IAM in the first place? There is no time machine in the world and you cannot go back time, so before the incident actually happens, you should learn IAM.
I know since IAM is a foundational service, it has a lot of to learn and that takes time. If you want to become a IAM master before you start using any AWS services, that could take years, and that’s not practical at all.
But you should at least get familiar with IAM, understand its basics, and focus on the services that you want to deploy to AWS first, apply best security practices, and then continue to learn along with your cloud journey.
AWS IAM Basics
AWS IAM provides the infrastructure necessary to control authentication and authorization for your account. The IAM infrastructure includes the following elements:
- Principal
- Request
- Authentication
- Authorization
- Actions or operations
- Resources
The IAM request flow and architecture looks like:
Pic from aws docs
If you are a new or intermediate IAM user, the above request flow picture might look complicated to you, don’t worry, you don’t need to memorize the flow at this point, just keep learning, one piece at a time, everyday, if you keep going, this will become your muscle memory.
In order to help you understand the AWS IAM element, I drew the following diagram:
IAM Principal
A principal is a person or application that can make a request for an action or operation on an AWS resource. As a best practice, do not use your root user credentials for your daily work. Instead, create IAM entities (users and roles). You can also support federated users or programmatic access to allow an application to access your AWS account.
For example, user “txu” is a principal below:
Request
When user “txu” tries to use the AWS Management Console, the AWS API, or the AWS CLI, that user sends a request to AWS. The request includes the following information:
- Actions: The actions or operations that the principal wants to perform.
- Resources: The AWS resource object upon which the actions or operations are performed.
- Principal: The person who made the request
- Environment data: Information about the IP address, user agent, SSL enabled status, or the time of day.
- Resource data: Data related to the resource that is being requested
Below is an example of listing AWS S3 bucket request:
Authentication
A user or app must be authenticated using their credentials to send a request to AWS. To authenticate from the console as a root user, you must sign in with your email address and password. As an IAM user, provide your account ID or alias, and then your user name and password. To authenticate from the API or AWS CLI, you must provide your access key and secret key.
Authorization
You must also be authorized to complete your request. From your request context, AWS will get the IAM policies that applied to the request. I will cover IAM policy in details in later articles. For now, you just need to know that IAM policy are documents that defines permissions for IAM principles.
The IAM permission evaluation logic follows the following general rules:
- By default, all requests are denied.
- An explicit allow in any permissions policy (identity-based or resource-based) overrides this default.
- The existence of an Organizations SCP, IAM permissions boundary, or a session policy overrides the allow. If one or more of these policy types exists, they must all allow the request. Otherwise, it is implicitly denied.
- An explicit deny in any policy overrides any allows.
Actions
Actions defines that what you can do to a resource in your request. Typical actions are viewing, creating, editing, and deleting. For example, the following diagram defines AWS S3 bucket readonly access:
Resources
A resource is an object that exists within a service. Examples include an Amazon EC2 instance, an IAM user, and an Amazon S3 bucket. The service defines a set of actions that can be performed on each resource.
