AWS Identity and Access Management (IAM)
IAM is a feature of your AWS account offered at no additional charge.
It is an essential topic with regard to the AWS foundational concept. First, we will get the theoretical understanding of Identity and Access Management (IAM), IAM users and groups, IAM Policy, and then create an IAM user. Let's first start with what IAM is.
Table of Contents
Introduction to IAM
IAM is the abbreviated form of Identity and Access Management. It is a global service, which means it is not associated with any AWS region — most AWS services have a region scope. However, a handful of them has global scope — IAM has global scope. It deals with the management of users, groups, and their permissions. In other words, using the IAM service, we can create users and groups and assign them permissions means what the users and groups can do on that AWS account.
You already used the IAM service when you signed up for AWS. When you sign up for AWS, an AWS root account is created. AWS root account is created default when you sign up for AWS. You should use your AWS root account in very rare situation. In fact, you should create another user, and use that user account instead of the root user account. And do not share your root user account user id, password, and access keys with anyone.
Amazon IAM service allows you to securely control access to AWS services and resources. You can create and manage AWS users and groups using IAM. You can set up permissions to allow and deny their access to AWS resources.
The IAM service provides fine-grained access control across your AWS account. With IAM, you can specify access permissions — who can access what services and resources. With IAM policies, you manage access permissions to your workforce and systems to ensure the least privilege permissions. These features do IAM a critically important service for your account's overall security of AWS resources. IAM is secure by default; users cannot access AWS resources until permissions are explicitly granted. You also require strong password practices, such as complexity level, avoiding re-use, and enforcing multi-factor authentication (MFA).
For workloads that require systems to have access to AWS, you can enable secure access to IAM through roles, instance profiles, identity federation, and temporary credentials. You can use federation with your existing directory service.
Now we know that IAM is used for the management of users, groups. In other words, we can create users and groups using the IAM service.
How it Works
Screenshot Reference: https://aws.amazon.com/iam/
IAM Users and Groups
Let’s understand the IAM users and groups concept. Before going into details, I just wanted to clarify that you might hear both AWS and IAM users. Both are the same. Depending on the context, one is generally used over the other. AWS user is a more general term; however, we use the term IAM user when referring specifically to the context of IAM. Semantically both terms are the same.
You should create separate IAM users for each person in your organization. In other words, an AWS account/person in your organization. However, it's good practice to create a group for the users if they do similar operations. Why? Because that way, if you need to add additional permission, just add that permission to the group, and it will be assigned to all group users. On the same token, if you remove permission from the group, it will be removed for all group users.
Let's try to understand the AWS users and groups concepts. Suppose we have a startup organization with seven employees. Tom, Marcus, and Jack are in the Engineering group; Bob and Amy are in the Sales & Marketing group; Pat is in Finance, and Steve is CEO.
In this scenario, we will have to create 7 IAM users — one for each employee. Since Tom, Marcus, and Jack are in the engineer's group, we will need to create an Engineering group and add them to the engineering group.
Since Bob and Amy are in Sales & Marketing, we will create a Sales & Marketing group and add Bob and Amy to the Sales & Marketing. Now Steve is CEO. Being CEO, sometimes, he helps the Engineering group, and sometimes he allows the Sales & Marketing group. So, we will add Steve to both groups. Pat will be in no group as he takes care of the Finance department alone until he extends his fiancé group to add more employees.
As you can see, an AWS user could be in more than one group. For example, suppose you later created a DevOps group and if Marcus and Jack are part of the DevOps group. Then, you can add Marcus and Jack into the DevOps Group. So, we got the idea, we need one IAM user per person, and users could belong to a group if they perform similar operations. One IAM user may be in more than one group, which is generally good, making user management easier. You cannot have one group in another group.
IAM Group
IAM group is used to group the collection of IAM users. IAM group makes IAM users' permission management easier. If new permission needs to be added or revoked, just do it from the IAM group, and the change is applied to all users in the group immediately.
IAM Policy
Now how will we allow AWS users and groups to use AWS? To enable users or groups, to do what they are allowed to do, we will have to assign permissions. How will we assign permissions? Well, there is a concept of IAM policy, which contains a set of permissions.
IAM policy is written in JSON as you can see in the screenshot. JSON is easy to understand. It is structured written in a key-value format separate as a colon. For example, the JSON statement in the picture says that all EC2 actions are allowed if any resource”*” represents any or all. If this permission is assigned to an IAM user or group, the user or group can perform any EC2 operation on any resource.
The main point to understand here you assign permissions to an IAM user or a group using the IAM policy. IAM policy is a set of permissions, as you can see in the document. The individual lines, which are also called statements, are given within the curly brackets. So, for example, you have one set of permissions for EC2 and another set for elastic load balancing and so on. For each permission set, you provide action that you are considering, Effect which could Allow or Deny, and on which resource or resources you would want the defined action to be applied upon.
If we assign this policy to any user or group, then that user or group will perform operations based on the approach. An IAM user or group cannot do anything unless a policy is assigned. More than one policy can be assigned to a user or group.
You should not assign more permissions than a user needs it. The is called the principle of least privilege, which helps in your overall AWS account security. If you didn't follow this principle, you could have situations where users could be doing or trying out something, for example, launching hundreds of EC2 instances, and organizations would get surprised charges on the AWS bill. Additionally, there could be potential security-related issues as well. Now we will learn how to create an IAM user.
Mandatory Elements of an IAM Policy (Effect, Action)
Most policies are stored in AWS as JSON documents. Identity-based policies and policies used to set permissions boundaries are JSON policy documents that you attach to a user or role. Resource-based policies are JSON policy documents that you attach to a resource.
A JSON policy document includes these elements:
- Optional policy-wide information at the top of the document
- One or more individual statements
Each statement includes information about a single permission. The information in a statement is contained within a series of elements.
- Version – Specify the version of the policy language that you want to use. As a best practice, use the latest 2012-10-17 version.
- Statement – Use this main policy element as a container for the following elements. You can include more than one statement in a policy.
- Sid (Optional) – Include an optional statement ID to differentiate between your statements.
- Effect – Use Allow or Deny to indicate whether the policy allows or denies access.
- Principal (Required in only some circumstances) – If you create a resource-based policy, you must indicate the account, user, role, or federated user to which you would like to allow or deny access. If you are creating an IAM permissions policy to attach to a user or role, you cannot include this element. The principal is implied as that user or role.
- Action – Include a list of actions that the policy allows or denies.
- Resource (Required in only some circumstances) – If you create an IAM permissions policy, you must specify a list of resources to which the actions apply. If you create a resource-based policy, this element is optional. If you do not include this element, then the resource to which the action applies is the resource to which the policy is attached.
- Condition (Optional) – Specify the circumstances under which the policy grants permission.
IAM Role
An IAM user's credential is a long-term credential. An IAM role, however, is a short-term credential to which one or more than one IAM policy is assigned. An IAM role is an IAM identity that you can create in your AWS account having specific permissions. An IAM role is similar to an IAM user; however, instead of being uniquely associated with one user, a role is intended to be assumable by anyone who needs it. More importantly, a role does not have standard long-term credentials such as a password or access keys associated with it. Instead, when assume an IAM role, it provides temporary security credentials for the session.
An IAM role, a short-term credential to which one or more than one IAM policy is assigned. Using an IAM is a best practice for accessing AWS resources from an EC2 instance. An EC2 instance can assume an IAM role when accessing AWS resources. When assuming rule to access a resource, a temporary credential is generated to access the AWS resource. You should use IAM roles to grant access to your AWS account by relying on short-term credentials, a security best practice. Authorized identities, AWS services, or users from your identity provider can assume roles to make AWS requests.
Using an IAM role is a best practice for accessing AWS resources from an EC2 instance. An EC2 instance can assume an IAM role when accessing AWS resources. When assuming the rule to access a resource, a temporary credential is generated to access the AWS resource. You should use IAM roles to grant access to your AWS account by relying on short-term credentials, a security best practice. Authorized identities, AWS services, or users from your identity provider can assume roles to make AWS requests.
Don't share security credentials between accounts to allow users from another AWS account to access resources in your AWS account — instead, use IAM roles. You can define a role that specifies the IAM users' permissions in the other account. You can also designate which IAM users are allowed to assume the role.
Using IAM Role on EC2 Instance
Applications that run on an EC2 instance, and if they need to communicate with other services or resources, must include AWS credentials in the AWS API requests. One of the approaches is that developers could store AWS credentials directly within the EC2 instance and allow applications in that instance to use those credentials. But the issue with this approach is that developers would then have to manage the credentials and ensure that they securely pass the credentials to other instances or services. They will also have to update the credentials when it's time to rotate the credentials.
That's a lot of additional work. Instead, you should use an IAM role to manage temporary credentials for applications that run on an EC2 instance. When using a role, you don't have to distribute long-term credentials (username/password or access keys) to an EC2 instance. Instead, the role supplies temporary permissions that applications can use when making calls to other AWS resources. When you launch an EC2 instance, you specify an IAM role to associate with the instance. Applications that run on the instance can use the role-supplied temporary credentials to sign API requests.
IAM Use Cases
Screenshot Reference: https://aws.amazon.com/iam/
IAM Access Keys
Access keys are long-term credentials for an IAM user or the AWS account root user. You can use access keys to sign programmatic requests to the AWS CLI or AWS API (directly or using the AWS SDK). Access keys consist of two parts: an access key ID (for example, AKIAIOSFODNN7EXAMPLE) and a secret access key (for example, wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY). As a user name and password, you must use both the access key ID and secret access key together to authenticate your requests. Access Keys are secret, just like a password. You should never share them.
Use Access Key ID and Secret Access Key to access AWS resources programmatically.
Access keys are long-term credentials for an IAM user or the AWS account root user. You can use access keys to sign programmatic requests to the AWS CLI or AWS API (directly or using the AWS SDK). Access keys consist of two parts: an access key ID and a secret access key. As a user name and password, you must use both the access key ID and secret access key together to authenticate your requests. When you create an access key pair, save the access key ID and secret access key in a secure location. The secret access key is available only at the time you create it. If you lose your secret access key, you must delete the access key and create a new one.
Use Multi-Factor Authentication to access AWS resources programmatically – For increased security, AWS recommends that you configure multi-factor authentication (MFA) to help protect your AWS resources. You can enable MFA for IAM users or the AWS account root user. MFA adds extra security because it requires users to provide unique authentication from an AWS supported MFA mechanism in addition to their regular sign-in credentials when they access AWS websites or services. MFA cannot be used for programmatic access to AWS resources.
Use IAM Groups to access AWS resources programmatically – An IAM Group is a collection of IAM users. Groups let you specify permissions for multiple users, which can make it easier to manage the permissions for those users. IAM Group is for managing users and not for programmatic access to AWS resources.
Best Practices for IAM Service
Enable MFA for all users. AWS recommends that you require multi-factor authentication (MFA) for all users in your account. With MFA, users have a device that generates a response to an authentication challenge. Both the user's credentials and the device-generated response are required to complete the sign-in process.
Rotate credentials regularly. AWS recommends that you change your own passwords and access keys regularly, and make sure that all IAM users in your account do as well. That way, if a password or access key is compromised without your knowledge, you limit how long the credentials can be used to access your resources. You can apply a password policy to your account to require all your IAM users to rotate their passwords.
When you create IAM policies, grant the least privileges required to perform a task. When you create IAM policies, follow the standard security advice of granting the least privileges, or granting only the permissions required to perform a task. Determine what users (and roles) need to do and then craft policies that allow them to perform only those tasks.
Start with a minimum set of permissions and grant additional permissions as necessary. Doing so is more secure than starting with permissions that are too lenient and then trying to tighten them later.
Don't share security credentials between accounts, use IAM roles instead. Don't share security credentials between accounts to allow users from another AWS account to access resources in your AWS account. Instead, use IAM roles. You can define a role that specifies what permissions the IAM users in the other account are allowed. You can also designate which AWS accounts have the IAM users that are allowed to assume the role.
AWS IAM security best practices
screenshot from: https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html
IAM Access Advisor
IAM Access advisor provides information about the service permissions granted to a user and when those services were last accessed. You can use this provided information to revise your policies. This can be used to identify unnecessary permissions so that you can revise your IAM policies accordingly.
IAM Credentials Report
You can generate and download a credential report that lists all users, and the status of their various credentials such as passwords, access keys, and MFA devices in you AWS account. However, the report is not used to review permissions granted to a user.
Exam Tips
• AWS recommends that user account credentials should not be shared between users.
• AWS recommends granting the least privileges required to complete a certain job and avoid giving excessive privileges which can be misused.
• The access key for your AWS account root user gives full access to all your resources for all AWS services, including your billing information. You cannot reduce the permissions associated with your AWS account root user access key. You should never share these access keys with any other users, not even the administrators
References
SK Singh is the founder, a software, cloud, and data engineer. He has been involved in the software industry for around 25 years. He has a bachelor's degree in computer science and engineering from India and a master's degree in software engineering from the Pennsylvania State University. SK has been involved in a wide range of software projects for many governments, private, start-ups, and large public companies in various software engineering roles. He has many professional certifications such as AWS, Hadoop, Kafka, Oracle, Unix, Java, Java-related frameworks, and many others related.
