Identity and Access Management (IAM) is crucial when starting to use AWS outside your private playground and want to give users rights to use services in your account. IAM is free of charge and all configuration is global, not tight to any specific Region.

Identity sources

IAM holds different types of identities:

• Root account – that is the email address and password that you provided when creating account in AWS, it has all possible rights.
• Local users and groups – users can be created within your AWS account to get access to AWS Management Console or API. Users can be assign to a group for easier management.
• SAML federated users – most probably you have already Active Directory in your enterprise and you don’t want to recreate all users and manage them separately in each AWS account. Instead you can leverage your current AD using Active Directory Federation Services (ADFS) and SAML protocol to federate with AWS.
• Web based federated users – users can sign in using a well-known third party identity provider such as Login with Amazon, Facebook, Google using OpenID Connect (OIDC).

Roles

A role is an entity that has its own set of permissions, but that isn’t a user or group. Roles can be assumed by other entities like IAM user or AWS services like EC2. The main difference between user and role is that role does’t have their own permanent set of credentials. Instead, if a user assumes a role, temporary security credentials are created dynamically and provided to that user. Roles can be assumed by:

• User – either from your account or another AWS account. This is useful when you need to grant access to your resources from another account. You don’t need to create separate user in your account, just create role and specify external accounts that can use this role.
• Other AWS services. For example for EC2 – IAM dynamically provides temporary credentials to the EC2 instance, and these credentials are automatically rotated. This enables applications running on EC2 to make requests to AWS services like S3 without you having to copy AWS access keys to every instance.
• Federated users don’t have permanent identities in your AWS account. When a federated user signs in to AWS, the user is associated with the role and is granted the permissions that are defined in the role.

When you create a role in IAM, the role must have two things: The first is a trust policy that indicates who can assume the role (for example EC2 instance). The second is a permission policy that indicates what they can do with that role. After role is created it can be assumed by specified entity (like our specific EC2 instance).

Policies

IAM policy is a set of rules that, under the correct conditions (WHEN), define what actions (WHAT) the policy principal (WHO) can take to specified AWS (WHICH) resources. There are tow types of policies, identity based policies and resource based policies.

Identity based policies

Identity-based policies are policies that you can attach to a principal, like an IAM user, role or group. Again, exists two types of identity base policies:

• Managed policies (created by AWS or customer) – policies in IAM that are managed by customer or predefined AWS policies that covers common use cases, for example AmazonS3FullAccess.
• Inline policies – not visible in IAM, assigned directly to one user, group or role.

Resource based policies

Resource-based policies are policy documents that you attach to a resource such as an Amazon S3 bucket.

Users or groups can have multiple policies attached to them that grant different permissions, final policy will be a summary of all attached policies, with assumption that Block has higher priority than Allow. If the user has not been granted an explicit permission for an action and a resource, the user does not have those permissions.

HERE is great post about IAM policies, I won’t repeat it, just read it!

Example

Here is simple example how to create user that has rights to read all objects in one S3 bucket.

1. Create S3 bucket.
2. Create policy with two possible actions: s3:GetObject (to read object) and s3:ListBucket (to list all objects in the bucket). You have to specify also to which bucket you want to grant access: “arn:aws:s3:::YOUR-BUCKET-NAME”, and what files should be accessible. In our case all files should be readable so I used asterisks: “arn:aws:s3:::*/*”. Principal is not needed as we later attach this policy to a group (so this is identity based policy).

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "s3:GetObject",
                "s3:ListBucket"
            ],
            "Resource": [
                "arn:aws:s3:::YOUR-BUCKET-NAME",
                "arn:aws:s3:::*/*"
            ]
        }
    ]
}

3. Create user and assign him to a group.
4. Assign policy to that group.
5. To access this bucket you need to have URL to it as you don’t have rights to perform list-bucket action.

Reference Materials

AWS on the road
AWS IAM documentation
Podcast Datanauts 086: AWS Identity & Access Management Policies
IAM Policies in a nutshell