Identity & Access Management

Identities are required to authenticate to AWS accounts.

Username = identity Password = verification

Access management relates to what an identity can access once its been authenticated.

The AWS IAM service is used to centrally manage and control security permissions.

• Users: These are objects within IAM identifying different users.
• Groups: These are objects that contain multiple users.
• Roles: These are objects that different identities can adopt to assume a new set of permissions.
• Policy Permissions: These are JSON policies that define what resources can and can’t be accessed.
• And Access Control Mechanisms: These are mechanisms that govern how a resource is accessed.

IAM is a global service.

Users, Groups, and Roles

Users represent a real person who requires access to operate and maintain your AWS environment.

Or it can be an account used by an application that requires permissions to access your AWS resources programmatically.

To create a user we:

• Create a username
• Set the AWS Access Type
• Define a password
• Permission assignment through the use of policies or inherited from a group
• Review and confirm the information
• Download .csv for security credentials

It’s best practice to use groups over assigning individual permissions.

IAM groups

Used to authorise access via policies.

IAM groups have IAM users and have IAM policies associated. These are either AWS managed policies or customer managed policies.

Groups are normally created to relate to a specific requirement or job role.

Any users who are members of that group inherit the permissions applied to that group.

It makes it easier to modify permissions for multiple users at once.

AWS has a default maximum limit of 100 groups. A user can only be associated to 10 groups.

IAM Roles

IAM roles allow users to adopt a set of temporary IAM permissions.

Roles don’t have access keys or credentials. They are dynamically assigned by AWS.

We may want to temporarily grant access to a permission for a user, we can allow the user to assume a role which replaces their existing permissions temporarily.

There are 4 different types of roles:

• AWS Service Role (used by other services). Some examples are EC2, Directory Service, Lambda.
• AWS Service Linked. Associated to certain AWS services. Pre-defined and permissions cannot be altered. Examples are “Amazon Lex - Bots” and “Amazon LEx - Channels”.
• Roles for cross account access. Providing access to an account we own, and providing access to an account we own from a third party access. Allows cross-account access to resources.
• Role for identity provider access. Such as Google, Cognito, Amazon. Grants access for Simple Sign on (SAML). And grants API access to SAML providers.

IAM Policies

Used to assign permissions and are wriitten in JSON.

There are two types of policies available.

• AWS Managed Policies
• Customer Managed Policies

Assigning to a user is not best practice. AWS Managed is preconfigured by AWS to help us with the most common issues we may come across.

If we make changes to an AWS managed policy, it becomes a customer managed policy.

There are 3 ways to make a customer managed policy.

1. Copy any AWS managed policy
2. Policy Generator - make by series of drop down boxes
3. Create your own policy - we can write it in JSON ourselves

Inline policies do not show up under the policy list but are directly attached to your IAM object. We use them when we dont want to risk the permissions being used by others.

What happens when there are conflicting permissions?

1. All access to resource is denied
2. Access only allowed if specific “Allow” has been specified
3. If a single deny exists in any policy that deny will override any previous deny. An explicit deny will always take precedence over an explicit allow.

Identity Federation

Allows us to manage and access AWS even if we don’t have an IAM user account.