Simplifying AWS Identity and Access Management (AWS IAM) — Part 1

AWS IAM working

AWS IAM helps you securely control access to AWS resources, it helps in controlling authentication (signing into the AWS account, which is the Identity part of IAM) and authorisation (giving permissions to use resources, which is the access management part of IAM).

With IAM, you can grant other people permission to use resources in your AWS account without having to share your password or access key. You can grant different permissions to different people for different resources.

For example, you might allow some users complete access to Amazon EC2, Amazon S3, etc. For some other users, you might allow read-only access to just a few S3 buckets and nothing else, and for a few other users, you might give permission to administer just a few EC2 instances, or to access your billing information but nothing else.

Concepts to understand how AWS IAM works:

As you read through the concepts, it will be beneficial to review the diagram above.

• Principal: a person or application that can make a request for an action or operation on an AWS resource.
• Authentication: signing in to AWS account. A principal must be authenticated using their credentials in order to be able to send a request to AWS. To authenticate from the console as a root user, you must sign in with your email address and password. As an IAM user, provide your account ID or alias, and then your user name and password. To authenticate from the API or AWS CLI, you must provide your access key and secret key.

AWS recommends that you use multi-factor authentication (MFA) to increase the security of your account.

• Request: To be able to use the AWS Console, API, or CLI, the principal sends a request to AWS. The request includes the actions or operations that the principal wants to perform. It also includes the resources upon which the actions or operations are performed, and information about the principal, etc.
• Authorization: Permissions to use resources. AWS uses several types of policies to authorise a request. Identity-based policies are attached to an identity (IAM user, group, or role). These policies let you specify what that identity can do (its permissions). Resource-based policies are attached to a resource. For example, you can attach resource-based policies to Amazon S3 buckets, Amazon SQS queues, and AWS Key Management Service encryption keys. For a list of services that support resource-based policies, see AWS services that work with IAM. Permission boundaries are policies that define the maximum permissions that the identity-based policies ( not resource policy) can grant to an entity.

The evaluation logic for a request within a single account follows these general rules:

1. By default, all requests are denied.
2. An explicit allow in any permissions policy overrides this default.
3. Permissions boundary overrides the allow.
4. An explicit deny in any policy overrides any allows.

• Actions or operations: things that the principal can do to a resource, such as viewing, creating, editing, and deleting that resource. After your request has been authenticated and authorized, AWS approves the actions or operations in your request.To allow a principal to perform an operation, you must include the necessary actions in a policy that applies to the principal or the affected resource.
• Resources: an object that exists within a service. Examples: an Amazon EC2 instance, an Amazon S3 bucket, etc. After AWS approves the operations in your request, they can be performed on the related resources within your account. The service defines a set of actions that can be performed on each resource.

Note that “IAM User” is also an object within the IAM service, and hence a resource.

Users:

• Root user: When you first create an AWS account, you create a root user identity (with root user credentials: email address and password), which you use to sign in to AWS. With your root user credentials, you have complete, unrestricted access to all resources in your AWS account, including access to your billing information and the ability to change your password. This level of access is necessary when you first set up your account.

Best practice: Do not use your root user credentials for your daily work. Instead, create IAM entities (users and roles).

• IAM user: Instead of sharing your root user credentials with others, you can create individual IAM users within your account that correspond to users in your organization. IAM users are not separate accounts; they are users within your account. Each IAM user can have its own password for access to the AWS Management Console. An IAM user doesn’t have to represent an actual person; you can create an IAM user in order to generate an access key for an application that runs in your corporate network and needs AWS access.

Best practice: Create an IAM user for yourself and then assign yourself administrative permissions for your account. You can then sign in as that user to add more users as needed

• Federating existing users: If the users in your organization already have a way to be authenticated, you don’t have to create separate IAM users for them. Instead, you can federate those user identities into AWS.

Different ways of federation:

• Your users already have identities in a corporate directory (Enterprise Identity Federation)

1. If your corporate directory is compatible with Security Assertion Markup Language 2.0 (SAML 2.0), you can configure your corporate directory to provide single-sign on (SSO) access to the AWS Management Console for your users.
2. If your corporate directory is not compatible with SAML 2.0, you can create an identity broker application to provide single-sign on (SSO) access to the AWS Management Console for your users.
3. If your corporate directory is Microsoft Active Directory, you can use AWS Directory Service to establish trust between your corporate directory and your AWS account.

• Your users already have Internet identities (Web Identity Federation)

If you are creating a mobile app or web-based app that can let users identify themselves through an Internet identity provider like Login with Amazon, Facebook, Google, or any OpenID Connect (OIDC) compatible identity provider, the app can use federation to access AWS.

Groups:

A collection of IAM users. With groups, you can specify permissions to multiple users. That makes it easier to manage the permissions for those users. For example, you could have a group called Admins and give certain permissions to that group. Any user in that group automatically has the permissions that are assigned to the group. If a new user joins your organization and needs administrator privileges, you can add the user to that group. And, if a person changes jobs in your organization, instead of editing that user’s permissions, you can simply remove the person from the old groups and add him/her to the appropriate new groups.

Roles:

Roles are similar to an IAM user, but instead of being uniquely associated with one person, a role is intended to be assumable by anyone who needs it. A role does not have standard long-term credentials such as a password or access keys associated with it. Instead, when you assume a role, it provides you with temporary security credentials for your role session. You can use roles to delegate access to users, applications, or services that don’t normally have access to your AWS resources. Roles can be used by the following:

1. An IAM user in the same AWS account as the role
2. An IAM user in a different AWS account than the role
3. A web service offered by AWS such as Amazon EC2
4. An external user authenticated by an external identity provider (IdP) service that is compatible with SAML 2.0 or OpenID Connect, or a custom-built identity broker.

Cross account access:

A user that assumes the role, temporarily gives up his or her own permissions and instead take the permissions of the role. Cross-account access with a resource-based policy has some advantages over cross-account access with a role. With a resource that is accessed through a resource-based policy, the principal still works in the trusted account and does not have to give up his or her permissions to receive the role permissions. In other words, the principal continues to have access to resources in the trusted (user’s) account at the same time as he or she has access to the resource in the trusting (cross) account. This is useful for tasks such as copying information to or from the shared resource in the other account.

Conclusion

This post covers the basics of AWS IAM and related concepts. In the next blog, we will cover the policies and permissions in IAM.