you will learn what AWS Identity and Access Management (IAM) is and how it sets the foundation for all interactions among the resources in your AWS account. We’ll also cover the various access methods to the AWS IAM services:
You will also learn how to protect and secure your AWS Cloud environments using features such as multifactor authentication (MFA) and other best practices.
AWS Identity and Access Management (IAM) provides a set of APIs that control access to your resources on the AWS Cloud. AWS IAM gives you the ability to define authentication and authorization methods for using the resources in your account.
When you create your account, you receive a single identity that gives you full access to the resources in the account. The login information is in the form of an email address. This identity is called the root account or root user, and due to its high set of permissions, AWS recommends restricting the access to these credentials to a few people and using it only on rare cases. For additional security, AWS recommends that you enable MFA on your root account and don’t create root access keys to make programmatic requests to AWS. You cannot reduce the permissions associated with your AWS root account, unless service controls policies (SCPs) are used in accounts different from the admin account in an AWS Organization.
AWS IAM empowers you to define strict access rules for individuals and other systems for manipulating resources in a specific account. For example, you can specify that a user can call a specific API from a specific IP address only during a certain period of the day. AWS IAM makes access to AWS resources possible for applications that are running on-premises or in the AWS Cloud. Such granularity allows systems administrators to comply with security and regulations that are relevant for their organizations.
We will also cover the various principals that can interact with AWS and how they are authenticated. We will then discuss how to write policies that define permitted access to services, actions, and resources, and how to associate these policies with authenticated prin- cipals. Finally, we will explore additional AWS IAM features that can help you secure your infrastructure, including MFA, rotating keys, federation, resolving of multiple permissions, and AWS IAM roles.
AWS IAM is designed to protect the resources in your AWS account and it should not be used as an identity provider (IdP) for your applications. If you are planning to migrate your on-premises application to the AWS Cloud and it already has its own IdP, you should continue to use it. For example, if your application uses Microsoft Active Directory (AD) as its IdP, you can extend it into AWS by using the AWS Directory Service, an Active Directory–compatible directory service that is capable of integrating with your on-premises AD. On the other hand, if you plan to implement a new web application or mobile app, you may consider Amazon Cognito for identity management for your application.
The AWS IAM service provides the necessary infrastructure for you to implement authentication and authorization in your AWS account. To better understand the AWS IAM architecture, let’s explore the main elements that comprise it.
A principal is an AWS IAM entity that has permission to interact with resources in the AWS Cloud. Whether it is permanent or temporary, this principal can represent a human user, a resource, or an application. There are three types of principals: root users, IAM users, and roles (or temporary security tokens).
When you create your first account on AWS, the account is known as the root user iden- tity, since it allows you to sign in to AWS. You can log into the AWS Console using the email address and password that you provided when you created your account. This set of information is also known as your root user credentials.
The root user credentials give you unrestricted access to all the AWS resources in your account. This access covers (but is not limited to) viewing billing information, changing your root account password, and performing the complete termination of your account and deletion of its resources.
For daily operations in your AWS account, it is not necessary to use the root user. Moreover, AWS highly recommends that you not share the root user credentials with anyone, simply because doing so gives them unrestricted access to your account. There is no way to restrict the access given to the root user in the master account. However, if the account is a member of an AWS Organization, it’s possible to use SCPs to restrict root user account permissions.
Once you have set up your AWS account, the most important thing that you should do is protect your root user credentials by following these recommendations:
Similar to IAM users, IAM roles can have a permission policy that determines what the IAM role can and cannot do in AWS. IAM roles are not exclusively associated with an IAM user or group; they can also be assumed by other entities, such as applications or services. Additionally, IAM roles do not have long-term credentials or access keys directly assigned to them during creation. When a role is assumed, it is granted temporary credentials by a service called AWS Security Token Service (STS). Such temporary credentials are valid throughout the role session usage. The default lifetime of temporary security tokens issued by STS is one hour and can be configured from 15 minutes to 36 hours. Roles can be used to delegate access to resources that services, applications, or users do not normally have. For example, you can allow an application to assume a role that pro- vides access to a resource in a different AWS account even if its original permissions did not allow such access. Another example would be if your user only has access to a development account and you grant them the ability to publish content in the production account by assuming an IAM role. Yet another example is if you grant an external application access to AWS resources, but instead of using fixed credentials inside the application (which are easy to extract and hard to rotate once deployed), you can leverage an IAM role for this purpose. Furthermore, if you want to give access to users who already have identities on your cor- porate directory or from another IdP, it is possible to change these credentials to IAM role credentials that provide them with temporary access to AWS resources. IAM roles can be used in the following scenarios:
The AWS Security Token Services (STS) is designed to provide trusted users and services with temporary security credentials that control access to AWS resources. This service provides the foundation for other features such as cross-account access, AWS service roles for an EC2 instance, and identity federation.
The main differences between long-term access keys and temporary security credentials issued by AWS STS are as follows:
When you issue a temporary security credential, you can specify the expiration interval of that credential, which can range from a few minutes to several hours. Once expired, these credentials are no longer recognized by AWS, and any API requests made with them are denied.
Temporary credentials are dynamic and generated every time a user requests them. A user can renew the temporary credentials before their expiration if they have permission to do so.
Roles for cross-account access grant users of one AWS account access to resources in a dif- ferent account. Such a procedure enables a different set of scenarios such as API or CLI calls or AWS Console access.
One common use case can be two AWS accounts, such as Dev and Prod, where users from the Dev account must access the Prod account. The regular permissions to a developer in the Dev account do not allow them to directly access the resources in the Prod account. However, it’s possible to define a trust policy that allows a developer in the Dev account to assume a role in the Prod account. Once the trust policy is attached to the Prod role, a Dev account with the permission to assume the production role (with a sts:AssumeRole directive) can access the Prod account with the permissions defined by the role assumed.
AWS service role for an EC2 is an IAM role that can be attached to multiple Amazon EC2 instances, which allows your applications to securely make API requests from your instances without the need to manage the security credentials that applications use.
To further understand what this feature actually does, imagine a scenario where an application running on an Amazon EC2 instance needs to post a message to Amazon Simple Queue Service (SQS). In this scenario, you do not need to set up an IAM user with the required policies to post a message to Amazon SQS and then share the user’s access keys with the developer to manage directly inside the application configuration file. Instead, you can create a role for an EC2 instance and attach a policy to the role (with the required permission to access Amazon SQS), allowing the application to assume the role and perform the actions with temporary credentials.
When running your applications on Amazon EC2 instances, always use AWS service roles for an EC2 instance to give your applications access to AWS resources.
Access to AWS resources is managed through policy documents, which are attached to IAM identities or AWS resources. A policy is a JavaScript Object Notation (JSON) file that defines all the permissions that an identity or a resource has. When an identity or a resource makes an API request to other services, the AWS Cloud evaluates its permissions and allows the request to go through or denies it, based on a policy definition. Here are the key points you should learn to understand how the AWS Cloud evaluates policies during API requests:
The AWS Certified Security – Specialty exam requires you to understand the JSON syntax and the policy document structure. When designing simple policies, you can use the visual editor available in the AWS Console, which covers most of the everyday scenarios. Nonetheless, in situations where you need to write more complex policies, you should leverage the JSON editor that is also available in the AWS Console.
The JSON policy document consists of the following elements:
AWS provides a set of policy types that are available to use in different scenarios. For the remainder of this section, we are going to cover the most common ones.
Identity-based policies are JSON permissions policies that you can attach to an identity such as IAM users, IAM groups, or IAM roles. These policies define the actions that the principal can perform, and for which resources and in which conditions it might do so. AWS categorizes these policies into three different types:
AWS-Managed Policies These are policies provided and managed by AWS. They are essentially curated policies that allow you to quickly start setting up permissions to IAM entities and cover the most common use cases. For example, you can find policies by job function such as Administrator, Billing, and Database Administrator. These policies may change based on AWS’s discretion, such as when a change to the actual policy might impact customers if applied to an existing policy.
Customer-Managed Policies These are policies that you create and manage in your AWS account. Once you have better understanding of your users and applications, you can start defining fine-grained permissions policies that are reusable within your AWS account.
Inline Policies This type of policy is directly embedded in the entity. For example, when you create an IAM user and attach an inline policy to it, that policy will live within that entity and cannot be shared. If you delete the entity, the policy is also deleted. This type of policy gives the administrators a 1-to-1 relationship between the IAM entity (user, group, or role) with its permission policy.
Managed policies provide you with features that make the day-to-day administration activities easier. These policies are as follows:
A resource-based policy allows you to directly attach permissions to AWS resources, such as an Amazon SQS queue or an Amazon S3 bucket. It also allows you to specify who has access to that resource even if it does not have an explicit identity-based policy that says so. The next figure shows an example of a resource-based policy for Amazon S3.
In the figure, user John does not have explicit permissions to perform the GetObject operation on the Amazon S3 bucket. However, the policy attached to the Amazon S3 bucket allows full access to the user John within the AWS account, which allows the request to complete successfully.
Cross-account resource access is used in scenarios where you need to access resources in different accounts. For example, say SalesApp needs to send a message ( SendMessage ) to an Amazon SQS queue in the Message Broker AWS account. You should explicitly allow the role attached to SalesApp to make requests to the Amazon SQS queue on the Message Broker account. Additionally, you must add a resource-based policy to the Amazon SQS queue that allows SalesApp to perform the actions required, in this case SendMessage.
Permissions boundaries allow you to define the maximum permissions a user or application can be granted by IAM identity-based policies. You can use a customer-managed or an AWSmanaged policy to set the permissions boundaries for an IAM user or role.
