Identity and Access Management (IAM)

AWS Identity and Access Management (IAM) enables you to manage access to AWS services and resources securely. IAM is global, and this means when you create users, groups and roles, they will be accessible in any region.

User

An IAM user is an entity that you create in AWS. The IAM user represents the person or services who uses the IAM user to interact with AWS. A user in AWS consists of a name, a password to sign into the AWS Management Console, and up to two access keys that can be used with the API or CLI. An IAM user has permanent long-term credentials and is used to directly interact with AWS services.

An IAM user can have many IAM permission policies attached to them at the same time, either directly attached or through groups.

When you first create an AWS account, you begin with a single sign-in identity that has complete access to all AWS services and resources in the account. This identity is called the AWS account root user, and is accessed by signing in with the email address and password you used to create the account. Anyone who has root user credentials for your AWS account has unrestricted access to all the resources in your account, including billing information.

The AWS Knowledge Centre says that if you suspect your account is compromised you should do the following:

• Change your AWS account root password
• Delete or rotate all root and AWS IAM access keys
• Delete any potentially compromised IAM users, and change the password for all other IAM users
• Delete any resources on your account you didn’t create, such as EC2 instances, AMIs, EBS volumes, snapshots and IAM users

Group

A group is a collection of IAM users. It is primarily a management convenience to manage the same set of permissions for a set of IAM users.

Role

An IAM role does not have any credentials (password or access keys) and cannot make direct requests to AWS services. An IAM role is an IAM entity that defines a set of permissions for making AWS service requests. IAM roles are meant to be assumed by authorised entities, such as IAM users, applications, or an AWS service such as EC2. An IAM user can assume a role to temporarily take on different permissions for a specific task. A role can be assigned to a federated user who signs in by using an external identity provider instead of IAM. AWS uses details passed by the identity provider to determine which role is mapped to the federated user.

IAM roles allow you to delegate access with defined permissions to trusted entities without having to share long-term access keys. You can use IAM roles to delegate access to IAM users managed within your account, to IAM users under a different AWS account, or to an AWS service such as EC2.

Policy

You manage access in AWS by creating policies and attaching them to IAM identities (users, groups, or roles) or AWS resources. A policy is an object in AWS that, when associated with an identity or resource, defines their permissions. These permissions determine whether any request is allowed or denied.

The following policy types, listed in order of frequency, are available for use in AWS.

• Identity-based policies - Attach AWS managed, customer managed or inline policies to IAM identities (users, groups to which users belong, or roles). Identity-based policies grant permissions to an identity.
• Resource-based policies - Attach inline policies to resources. The most common examples of resource-based policies are Amazon S3 bucket policies and IAM role trust policies. Resource-based policies grant permissions to a principal entity that is specified in the policy. Principals can be in the same account as the resource or in other accounts.
• Permissions boundaries - Use a managed policy as the permissions boundary for an IAM entity (user or role). That policy defines the maximum permissions that the identity-based policies can grant to an entity, but does not grant permissions. Permissions boundaries do not define the maximum permissions that a resource-based policy can grant to an entity. An explicit deny in any of these policies overrides the allow.
• Organizations SCPs - Use an AWS Organizations service control policy (SCP) to define the maximum permissions for account members of an organization or organizational unit (OU). SCPs limit permissions that identity-based policies or resource-based policies grant to entities (users or roles) within the account, but do not grant permissions.
• Access Control Lists (ACLs) - Use ACLs to control which principals in other accounts can access the resource to which the ACL is attached. ACLs are similar to resource-based policies, although they are the only policy type that does not use the JSON policy document structure. ACLs are cross-account permissions policies that grant permissions to the specified principal entity. ACLs cannot grant permissions to entities within the same account.
• Session Policies - Pass an advanced session policy when you use the AWS CLI or AWS API to assume a role or a federated user. Session policies limit the permissions that the role or user’s identity-based policies grant to the session. Session policies limit permissions for a created session, but do not grant permissions.

The following flow chart provides details about whether a request is allowed or denied within an account:

Understanding Policies

The AWS talk in the Useful Links section talks about the PARC model, with PARC standing for Principal, Action, Resource and Condition.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "effect",
            "Principal":"principal",
            "Action": "action",
            "Resource": "arn",
            "Condition":{
                "condition"{
                    "key":"value"
                }
            }
        }
    ]
}

• Effect - is Allow or Deny
• Principal - you don’t see this often, as you attach a policy to a principal so you know who it is. When you use a bucket policy which you attach to a resource, you will want to specify the principal which is the who
• Action - is the type of access that is allowed or denied
• Resource - is the Amazon resource(s) the action will act on using ARN
• Condition - are the conditions under which the access defined is valid and true

Policy Types and Core Use Cases

Service Control Policies do not grant access. By default every organisation starts up with an allow *

Permission Boundaries prevents developers from being able to escalate privileges above a certain level. Controls the maximum permissions employees can grant.

Useful Links

Become an IAM Policy Master Re:Invent 2018

• IAM
• Policy