Get started with IAM

Interactions with AWS services and resources by developers and entities require:

What is Identity and Access Management?

AWS provides and uses a service called Identity and Access Management (IAM) for authentication and authorization. IAM is used to manage developer accounts and secure the interaction between services and resources.

Fundamentals

With IAM, developers attach policies, JSON documents that define granular permissions, to resources. IAM provides pre-built AWS managed policies for common access levels. You can also define your own policies with the least-privilege level necessary to complete tasks.

Information about IAM policies may come at you fast. If it gets to be too much, put it in PARC:

At a high level, these four terms should be enough to get you started connecting serverless resources.

Account prerequisites

But, before you start, you need an AWS account. The following sections provide the best practice steps to create an account and an administrative user.

A common confusion arises when signing in to AWS. Remember, for day to day activities, you should not be signing in as the root user.

Principals

IAM implements authentication, proving who an entity claims to be, with principals, which are entities such as IAM users, federated users from Google, Facebook, etc, IAM roles, AWS accounts, and AWS services.

A loose analogy for IAM roles are that of professional uniforms: a surgeon's scrubs, a firefighter's hardhat, or a startup CTO's favorite hoodie. Many people can assume the role of a surgeon, firefighter, and startup CTO, which identifies them with a certain job function.

One of the most useful things about IAM roles is they can be associated not only with human entities, but also with AWS services. These types of roles are known as service roles. This means you can assign an IAM role directly to a service. With an IAM role assigned to the service instance, you can then associate specific IAM policies with the instance role, so that the service instance itself can access other AWS services. This is extremely useful for automation.

Authorization - PARC

So far we've been talking about principals. Principals represent the authentication component. For authorization, you will attach JSON documents called IAM policies to principals.

Principals

As mentioned, principals are the entities that are allowed or denied access.

Actions

Actions are the type of access that is allowed or denied. Actions are commonly AWS service API calls that represent create, read, describe, list, update, and delete semantics.

Resources

Resources are the AWS resources the action will act upon.

All AWS resources are identified by an Amazon Resource Name (ARN) . Because AWS services are deployed all over the world, ARNs function like an addressing system to precisely locate a specific component. ARNs have hierarchical structures:

arn:partition:service:region:account-id:resource-id
arn:partition:service:region:account-id:resource-type/resource-id
arn:partition:service:region:account-id:resource-type:resource-id

Related resource(s):

Conditions

Conditions are specific rules for which the access is valid.

Other Elements

Policies

When you set permissions, you attach a JSON policy to a principal. In the following example, an AWS managed policy named AWSLambdaInvocation-DynamoDB will be attached to a role that is related to a Lambda function:

You can also create customer policies that apply to specific actions, resources, and custom conditions. The following policy example includes a condition that applies to an IP range:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [ 
                "ec2:DescribeInstances", 
                "ec2:RunInstances"
                ...
                <additional actions>
            ],
            "Resource": "*",
            "Condition": {
                "IpAddress": { "aws:SourceIp": "12.34.56.78/32"}
            }
        }
    ]
}

First, notice there is no Principal element in the policy. This is because attaching a policy to a principal implicitly specifies the principal to which the policy applies. Policies can exist apart from principals, so that common policies can be re-used for many roles, services, etc.

The Effect is Allow, so this is a policy that explicitly grants access. This is the most common type of policy. You can write policies that explicitly Deny access as well.

The Action is an array of multiple actions that permit using EC2 to run instances and describe instance metadata. Actions can be a single action, or multiple actions in an array like depicted here.

There is no specific ARN in the Resource field, but instead *, which is a wildcard character that means this policy applies to all resources.

Finally, we have a Condition set that applies this policy only if the caller's IP address matches exactly 12.34.56.78. Conditions are optional, and do not need to be specified if the policy is to be applied unconditionally.

IAM policies can be combined, each with varying degrees of sensitivity and specificity. The net effect of combining policies is fine-grained access control for every resource in an AWS account.

How policies are evaluated

For IAM principals, requests to AWS are implicitly denied. This means that if no policies are attached to a principal, IAM's default behavior is to deny access.

Next, if the principal does have an attached policy, and there is an explicit allow, the implicit deny is overridden. However, an explicit deny in any policy overrides any allows. In complex situations, there can be additional steps, but the following diagram represents this simplified model of how IAM evaluates identity based policies:

Advanced topics

You can do a lot just using AWS managed policies. As you progress on your journey, you should explore the following more advanced topics.

Resource-based policies

When you create a permissions policy to restrict access to a resource, you can choose an identity-based policy or a resource-based policy.

Identity-based policies are attached to a user, group, or role. These policies let you specify what that identity can do (its permissions). For example, you can attach the policy to the group named RemoteDataMinders, stating that group members are allowed to get items from an Amazon DynamoDB table named MyCompany.

Resource-based policies are attached to a resource. For example, you can attach resource-based policies to Amazon S3 buckets, Amazon Simple Queue Service queues, VPC endpoints, and AWS Key Management Service encryption keys.

With resource-based policies, you can specify who has access to the resource and what actions they can perform on it.

Related resource(s):

IAM permissions boundaries

With a permissions boundary, you set the maximum permissions that an identity-based policy can grant to an IAM entity.

When you set a permissions boundary for an entity, the entity can perform only the actions that are allowed by both its identity-based policies and its permissions boundaries. Permissions boundaries limit the maximum permissions for the user or role.

For example, assume that the role named CoreServiceAdmin should be allowed to manage only Amazon S3, Amazon CloudWatch, and AWS Lambda. To enforce this rule, you can set a policy to set the permissions boundary for the CoreServiceAdmin role.

Related resource(s):

Additional resources

Official AWS documentation:

Resources from the serverless community:

Next Steps