What is AWS IAM? Introducing the Basics - Become a Better Developer (2023)

Learn more about AWS IAM fundamentals. Just enough to get you started, not too much to overwhelm you with details. This article is intended for beginners, but it can also be a useful refresher for experienced users.

In my opinion, AWS IAM is a fundamental service for any cloud operator. It is one of the first, if not THE first AWS service to learn, along with the big ones like Amazon S3 or DynamoDB.

In this blog post, I'll walk you through the basics of AWS IAM. I'll go into enough detail to get you off to a good start on your AWS journey. But I won't burden you with the finer details.

We'll start by reviewing the main ideas of IAM:Resources, Actions and Policies.

From there, I describe the IAM authorization process using an example. We'll briefly review the various methods of interacting with AWS that IAM supports (via the console, the aws CLI, or programmatically).

After that, let's dive a little deeper into features, actions, and policies by looking at a policy document. Finally, I'll explain some other important concepts, includinggroups, roles,YTrust relationships.

Let's start...

Do you prefer a video format? Check out my YouTube video on this subject.Here.

a quick primer

Before getting into the details, I want to take a moment to explain some of the basics to outline what's to come.

First, let's demystify IAM. ANDidentityYaccess managementand is the service that controls access to AWS resources. Since accessing resources is one of the most basic things you can do on AWS, it's understandable why this topic is so important.

How does IAM do this? Well, it turns out there are 3 basic ideas at play.

Central Idea 1 – Resources

resourcesare the entities you create in AWS. This can include things like an S3 bucket, an S3 object, or a DynamoDB table. All resources on AWS are represented by something calledARNoAmanRResourcenorteand me. You've probably seen one of these identifiers before, they look a bit like this:arn:aws:s3:::test-website-aws simplified.

Throughout our time with AWS, we will continue to reference ARNs. They are how we as users uniquely identify the things we build on AWS.

Central Idea 2 – Actions

Behaviorare the operations that users attempt to perform on resources. For example, if I created a Lambda function, you might want to update its configuration. To do this I need to use an API calledlambda:UpdateFunctionSettings. To perform this action, I need permissions to call this API. But how do I get the permissions?

The answer is in thePolicy…

Central idea 3: policy/policy document

At the heart of AWS IAM is thePolicy. IAM policies refer to specific JSON documents that define user permissions to access a resource. In other words, permission to perform aActionis determined by whether or not the user has the appropriatepolicy documentwith associated permissions.

You might be a little confused about these concepts, but don't worry, we'll clear that up shortly. For now, remember that IAM is about securing access toresourcescontrolling who can performBehavioruser basedPolicy document.

Example: Manage Access to Create a Lambda Function

Let's take a closer look at these concepts with an example.

Suppose for a moment that we had afrom the user(tell me Daniel) trying to create a lambda function in the AWS console. How does AWS determine if I'm eligible?

See Also

▷ What is AWS IAM? | AWS Identity and Access Management [2023]

The answer is inPolicycurrently associated with this user. In IAM, when a useryou do not have explicit permission to access a resource, you cannot. This means that AWS IAM takes a proactive approach; by default it denies everything unless you specify that something should be allowed.

Sidebar – There is also an option to explicitly deny access to a resource. Explicit denying involves writing an entry in your policy document that specifically calls an API or set of APIs that the user should NOT have access to. Explicit denies always take precedence over allow. Therefore, if there is a conflict, negation wins.

Returning to our main point: AWS determines whether we are allowed to perform an action on a resource if we have the provided policy document associated with that user.

if a usernoUpon gaining access (implicit or explicit), the user is greeted with the dreadedaccess deniedError. If you haven't seen this glitch yet on your cloud journeys, get ready because I guarantee you will.

For this user to accesslambda:CreateFunctionbased on user policy document. So what does a policy document look like? Let's look at one now.

Search for an IAM policy document

The image above is apolicy documentthis will give our user permission to create a lambda function, but not much else.

Let's look at some of the elements.

execution- This is a random mystery value and rarely changes. Literally, its value is always 2012-10-17. For all intensive purposes, it doesn't matter.

opinion– The statement contains the core of the policy document. As seen in the image, a single policy document can contain multiple directives that define access to different resources.

S.I.D.- RepresentaSdeclarationI WENT. Just a unique identifier for your claim.

It is made– two possible values,To allowoTo deny. Allow is used to grant access, Deny to explicitly restrict access.

Action– The AWS operation you are trying to perform, usually 1:1 with the API name. The service assigns namespaces to actions. For example, the S3 action to create a bucket is, you guessed it, s3:createBucket.

Resource– The resource is the element to which we protect access. We can specify a resource-specific ARN to define granular access controls. If we want to be more liberal, we can use wildcards separated by asterisks (*).

School principal- An optional value. Principals help us create policies that can be applied to specific users.

We hope this basic example is clear to you and helps you understand some of the basics of securing access to AWS through IAM. I want to take a quick break and describe some of the other methods you can use to identify yourself to AWS so that AWS can determineOMSYou are (also known as authentication). Because our IAM policies are based primarily on the user concept, it's important to understand some of the access vectors.

Access AWS through your IAM user

To interact with AWS, we basically have three options:

1. Via console UI- Probably the same way you started using AWS, by digging through the AWS Management Console. When logging into the console you can do likeRoot-Benutzer(also known as logging in with your original account creation email) or as usualfrom the userthrough the account-level access portal. All accounts have a unique URL to log into the console with their user credentials. Users have policy documents stored, so their permissions in AWS are limited to the content of the document.
2. Through the AWS CLI– Probably the second most popular way to access AWS. When using the AWS CLI, we must provide our ownaws-access-keyYaws-secret-key-accessas a configuration step. These are alphanumeric strings unique to each user and serve as credentials when accessing AWS programmatically. Using the CLI, we can issue commands to call AWS APIs. Again, our access is limited to what is contained in the user policy document.
3. programmatic use an sdk- The last way is through an SDK to call AWS APIs. There are many SDKs provided by AWS in many popular programming languages. When we try to access an API programmatically and with an SDK, we need to create a client and usually instantiate it with our own.aws-access-keyYaws-secret-key-access.

Another Example: Managing Access to a DynamoDB Table

Let's look at another, more interesting example that uses other IAM features. This policy document is attached toAllow Read Access to Specific Columns in a DynamoDB Table.

This policy document is similar to the example we saw above, but with some interesting features. First, note that inActionSection we list several actions here. In addition, we use a placeholder for thedynamodb:BatchGet* Action.

It is important to note here that wildcards can be used in many parts of the policy document, from the core feature to part of the actions themselves. This notation indicates that each action starts withBatchGetis permitted under this policy document. For example,LotObterItemwould be a permissible action here.

Also note belowResourceSection We use other advantages of wildcards in this statement:arn:aws:dynamodb:*:*:tabla/MiTabla. The two *s here correspond to the region and account number. HeMesa/MiMesaThe section states that these actions only apply to that specific table (or any matching pattern). The * is used here as a substitute forRegion(for example, us-east-1) and account number (for example, 755018473).

This means that the actions in this policy apply to a table name being accessedMy tablethat can exist in any region and under any account. This is a useful policy if you have a multi-stack environment and you are trying to create a policy that allows read access to each of these tables.

Finally, thatConditionsThe Policy section enables some interesting features.Conditionswe will provide the context in which this policy takes effect.

In the above directive, the parties belowForAllValues: StringEqualsand the attributes listed below tell IAM that we want to restrict our permissions to just a specific set of column names as part of our table. There are some other condition keys we can use besidesdynamodb:Atributo. This one in particular is unique to Dynamo and allows us to restrict access at the column level.

the last part,StringEqualsIfNotExistsand consequentlydinamodb: selectis another requirement for enabling column-level access control for Dynamo.

Don't worry if you don't understand much about it.Conditions. You can really go far on your AWS journey with little or no knowledge of it. For now, all you know is that they exist and what they generally do. If you want to know more about this, you can read the IAM condition documentation.Here.

Other important concepts: groups, roles, and trusts

So far I've talked enough about AWS IAM to get you pretty far, but there are a few other concepts you might encounter that you should be aware of. Let's explore them now.

The group

IAM groups are simply a collection of AWS users. They are an important set of organizational tools that allow you to assign similar permissions to a collection of users all at once. You can visualize this concept in the following image:

Groups allow you to associate users added to the group with a standard IAM policy. This is very useful when you have collections of users that require shared permission levels. For example, I can create an "Internal Developers" group that has very permissive policies on the account. On the other hand, I might have a "Contractor" group that has some limited permissions that only apply to the project they're working on.

You can use groups in a variety of ways to organize users and control access to resources at the same time. Consult the documentation for more information about groups.Here.

rollo

Roles are similar to users in that we can assign IAM policies to them. Unlike users, however, roles are intended to grant short-term access to resources. In other words, if I want to grant a user short-term access to provide a specific job role, for example B. as an administrator, I can give him the opportunity to do soshow offa specific role. The user has all permissions defined in the accepted rule's policy document. Roles can be used by many different users at the same time if necessary.

Roles can be assumed by users and other AWS services. For example, when we create a Lambda function, we need to specify arollowhich will be used by the Lambda function. For example, if our function needs access to DynamoDB, I need to add dynamodb-specific information.Behaviorto the role policy document.

i like to think aboutrolloto wear many different hats. We may take on different roles at different times based on our job role or something we're trying to get done on a short-term basis. Interestingly, we can also create roles that allow users to access our resources.andersAWS account, which is our next topic of discussion.

trust relationships

trust relationshipsThey're not so much a core concept of IAM as they are a source of problems many developers face, so I think they're worth discussing.

trust relationshipsallow us to createrollothat allow users of ANOTHER AWS account to access it temporarily. For example, consider an example like the following where we have an account with a DynamoDB table and a user in another account wants to access it.

The ability to grant access to a user in another account is not immediately clear. To achieve this, we must help each othertrust relationshipsYrollo. First, we need to access the IAM console and create a trust between these two accounts. This process is two-way: account 1 needs an entry that says "I trust account 2", and account 2 needs an entry that says "I trust account 1".

Additionally, Account 1 (which contains the resource being accessed) must create arollowho has the necessary access. From there, we need to give the specific user on Account 2 the ability to do this.show offthis article A more complete diagram of this process can be seen below:

In general, you must not provide third parties with direct access to your AWS resources; this usually must be done by exposing an API. However, there are some circumstances where shared access makes sense, and trusts are the means by which AWS makes this possible.

Pro tips (learned from my frustration)

Before closing, I want to take a moment to share some pro tips I've collected over the years. These tips are the result of years of experience with AWS and hours of frustration as I banged my head against the keyboard trying to figure out "why can't my X access my Y?".

Tip 1: Protect your root account

They aresourceThe account is the AWS "owner" account. Access is usually gained by going to the AWS sign-up page and signing in with the email address you originally used to register your account.

The root account is special, it's like the top node in an organizational hierarchy. Using it gives you special abilities like the ability to revoke ANY other user account or access account-level billing information.

If a malicious actor gains access to your root account, you have no choice but to call or email AWS for assistance. If so, you might be in trouble and dealing with some pretty awesome AWS bills.

Take my advice and create an account for your daily activities. Give admin access and move on.NoUse your root account for daily access, you'll thank me later.

Tip 2: Explicitly Deny wins Explicitly Allow

As mentioned above, AWS IAM has two access control modes:allow or deny. If for some reason you get stuck in a scenario where policies are assigned against you that affect the same resource, deny always wins. This can happen especially if you're taking on a role you're not familiar with, so keep that in mind.

This problem caused me headaches and trauma for many hours. Hope I can save you some time.

Tip 3: Use the Least Privilege Model

The least privilege model is a general security approachGrant only the level of access necessary to perform the required function, and no more.. In other words, don't be too generous with your IAM policies and grant access to actions like:Dinamodb:*for example (this grants access to all DynamoDB actions).

This leaves your application unduly exposed to attack vectors and vulnerabilities if an attacker accidentally accesses one of your IAM roles or users. Protect yourself in advance and only grant access to what you need.

Tip 4 – Use AWS Policy Simulator for IAM debugging

AWS Policy Simulator is a useful AWS tool that you can use to simulate actions for your IAM policy. It's especially useful when you're stuck in a scenario where you're rethinking your policy.it shouldHave access to a specific resource, but no.

The tool allows you to select the IAM users that you have created in your account and test access permissions as shown in the following diagram to run simulations.

The policy simulator can be accessed at https://policysim.aws.amazon.com. Make sure you are signed in to your AWS account so that you can access the IAM user profiles currently in your account so that you can run simulations.

Summary

In this article, I've introduced the most important fundamentals of IAM so you can start learning AWS. As a quick summary of most of the things we've learned, remember the following:

We createdfrom the userwho uses theirscredentialsthat grant access based on the content of theirpolicy document.

We createdrollowhat can be assumedentitieswithin or outside account limits with atrust relationship.

(Video) An Introduction to AWS CDK (and why you should be using it!)

If you liked this article, check out the others I have on this site, and if you have any questions or comments, be sure to leave them below.