IAM Basics Overview

Cool, we just figured out what IAM is in general and what it is used for. But by itself, IAM is a pretty big service, and obviously, we don't need to know everything about it at this stage. Let's see the main entities.

Users

In the Getting Started section, we configured MFA for the root user and mentioned that it shouldn't be used. That is exactly where IAM users come to our rescue.

Yes, besides the root user, your account can have a number of IAM users with more fine-grained permissions to services and particular workloads.

The rule of thumb is that one person must have an IAM user. No one should share credentials.

Credentials

Each IAM user has two types of credentials:

• To access the UI console - name and password

• Programmatic access (via CLI or SDK) - access key ID and secret access key

At the same time, one user can have multiple programmatic credentials, just in case you have multiple devices and want to have full control over their access.

Permissions

To provide the user with the necessary permissions, you can attach roles, groups, or inline policies to it. We will talk more about that below.

Policies

A policy is a JSON document describing who and how can use particular services. It consists of effect (allow or deny), actions, and resources that we're allowing or denying access to.

Remember that a policy doesn't provide permissions by itself and cannot be attached to any resource. It just describes them.

A simple IAM policy looks like that:

{
  “Version”: “2012–10–17”,
  “Statement”: {
    “Effect”: “Allow”,
    “Action”: [
      “s3:Get*”,
      “s3:List*”
    ],
   “Resource”: “*”
  }
}

In this example, the policy allows read-only access to any S3 bucket created within the account.

Roles

In general, the IAM role - is a container for policies. Besides working with policies, they can provide access from other AWS accounts and federated users with SAML and other web-based identities. But for now, we will only learn how to work with AWS services.

Now we're considering IAM roles with trusted entity type set to AWS service. They provide access described in the attached policies to entities (for example, IAM users).

One IAM role can have multiple policies attached.

Best practices

Well, we just reviewed the main building blocks of Amazon IAM. Here are some best practices when you're configuring access for your users or workloads:

• One person - one IAM user. Never share credentials with multiple users as you narrow down your control over permissions.

• Don't attach inline policies to IAM users and roles. Always create a policy and then attach it to a user or a role.

• Try not to mix multiple services within one policy.

• Use wildcards in action names and resources only when needed. Keep everything explicit.

• Again, don't use your root user. Use IAM users instead.