Chapter 2
Authentication, Identity, and Access Management
This chapter covers the following subjects:
Overview of IAM: Understanding Identity and Access Management (IAM) and using it correctly is a key to the correct design and security of any application running in AWS. The initial section of this chapter looks at the basics of IAM, which are described in more detail in later sections of the chapter.
Identity Principals in IAM: The second part of this chapter introduces the users, groups, roles, and policies that you use in IAM to assign and grant permissions.
Identity Providers and Federation: Applications with huge numbers of users and applications with functionality outside AWS need to be authenticated. For these types of use cases, IAM supports federation with external identity providers.
Implementing Application Authentication and Authorization: Building on the knowledge gained in the previous sections of this chapter, this section describes how to implement authentication and authorization into an application by using AWS IAM and federated directories.
Encryption in AWS Services: Encryption is another key part of securing application data. The last section of this chapter provides some architectural understanding of how and where encryption can be implemented in AWS.
This chapter covers content important to the following exam domain:
Domain 2: Security
2.1 Make authenticated calls to AWS services.
2.2 Implement encryption using AWS services.
2.3 Implement application authentication and authorization.
The ability to provide access to any application in the most secure manner possible is a crucial aspect of applications running in the cloud. To provide secured access, we need to have the ability to authenticate and authorize users and systems that interact with any component of our application. In this chapter, we take a look at different ways we can perform authentication, authorization, and granting of access in AWS.
“Do I Know This Already?” Quiz
The “Do I Know This Already?” quiz allows you to assess whether you should read the entire chapter. Table 2-1 lists the major headings in this chapter and the “Do I Know This Already?” quiz questions covering the material in those headings so you can assess your knowledge of these specific areas. The answers to the “Do I Know This Already?” quiz appear in Appendix A, “Answers to the ‘Do I Know This Already?’ Quizzes and Q&A Sections.”
Table 2-1 “Do I Know This Already?” Foundation Topics Section-to-Question Mapping
Foundations Topics Section |
Questions |
Identity Principals in IAM |
1, 6, 10 |
Identity Providers and Federation |
2, 5 |
Implementing Application Authentication and Authorization |
3, 7, 8 |
Encryption in AWS Services |
4, 9 |
1. When using IAM, to which of the following IAM principles can you assign long-term credentials?
User
Group
Role
Policy
2. When delivering federated access to an application, how does the user gain access to AWS services?
Via delegated policy based on the user’s group or pool membership
Via role assumption based on the user’s group or pool membership
Via federated policy based on the user’s group or pool membership
Via shared role based on the user’s group or pool membership
3. When assigning strict permissions for accessing S3 to a mobile application, how could you lock down the permissions to exactly one action?
Allow the action in the bucket policy for all users. All other actions are implicitly denied.
Allow the action in the bucket policy for all users. Explicitly deny all other actions by using a “Not” condition.
Allow the action in the role policy. All other actions are implicitly denied.
Allow the action in the role policy. Explicitly deny all other actions by using a “Not” condition.
4. Encryption in transit can be achieved through which of the following?
TLS
Client-side encryption
IPsec VPN
All of these answers are correct.
5. You are writing code for a mobile application. You need to allow the application to access an S3 bucket. What would be the most secure way to access the AWS resource?
Create an ACL and apply it to the bucket. Create a bucket policy that allows the ACL access to the bucket.
Create an IdP that authenticates the user of the application and provides it with a role. Create a bucket policy that allows the role access to the bucket.
Create an IdP that authenticates the user of the application and provides it with a role. Create an IAM policy with access to S3 and attach it to the role.
Authenticate the user of the application through IAM and provide it with a role. Create an IAM policy with access to S3 and attach it to the role.
6. To allow an application on an EC2 instance to use S3, which of the following is the safest way to distribute credentials?
Using secret access key and access key ID in the ./aws/credentials file
Storing credentials in the code
Using the environment variables
Using a role
7. For which of the following can you use IAM? (Choose all that apply.)
Authenticating and authorizing access to the AWS Management Console
Authenticating and authorizing access to RDS databases
Authenticating and authorizing access to EC2 operating systems
All of the above
8. What is the maximum number of IAM users?
Unlimited
10,000
5000
50,000
9. Which service encrypts all data at rest by default?
S3
RDS
Glacier
SQS
10. Which of the following objects can groups contain?
Users
Roles
Other groups
All of these answers are correct.
Foundation Topics
Overview of IAM
The ability to authenticate and authorize users to access services in AWS gives you a lot of flexibility and also provides an underlying layer of security for your applications. Having only known actors accessing, reading, and writing data is always preferable to anonymous access in most use cases being solved by modern applications. The ability to identify the user and give him or her granular permissions for any type of action within AWS or even within your application can be an invaluable resource when designing against best practices and in achieving the highest level of security.
Having the ability to identify the user means you can identify and record each action taking place in your AWS environment. Since AWS is designed as a set of APIs, all calls to AWS can easily be recorded and traced. As discussed in Chapter 1, “Overview of AWS,” you can build an application with a combination of low-level infrastructure services and higher-level, abstracted platform services. When you make use of platform services, you get an added benefit of built-in authentication. All application actions to the service are also sent through the service API. Any users, applications, or external systems using your services need to be authenticated to access the AWS services through their APIs. Once a user is authenticated, you can use the built-in IAM capabilities to either allow or deny the actions being requested on the API.
The permissions are evaluated for each action separately. This gives you complete control at the level of each request and allows you to set permissions very granularly—and also quickly remove access if any kind of security breach is identified. When you need strict security and the ability to authenticate and track every action on your AWS application, making use of as many platform services as possible can alleviate the need to design your own authentication mechanisms by securing your APIs, encrypting the traffic, and tracking usage on a per-request basis.
Identity Principals in IAM
Several identity principals are defined in the IAM environment. The identity principals are designed to allow for any type of authentication and authorization scenario. To identify who is using your application, you can use either a user or a role. When creating a user, you can assign long-term credentials; in contrast, a role does not have any credentials assigned to it but can be used to retrieve temporary credentials. A role essentially allows you to temporarily delegate access to users and systems that would otherwise not have access to the AWS services. If you did not have the ability to create roles, you would have to use an IAM user to permit any kind of access to AWS, even between AWS resources. Figure 2-1 shows the three different types of identity objects and the policies that are attached to them that allow you to control access to AWS resources.
Figure 2-1 IAM Identity Principals
To assign permissions, you use policies. In a policy, you define which identity principal will be allowed to perform actions over resources. You can also specify under which conditions an action will be allowed or denied. Figure 2-2 shows the process of authentication and evaluation being performed by IAM before a user is granted access to AWS resources.
Figure 2-2 IAM Identities and Permissions
Two types of actions can be allowed over AWS resources via a policy:
Management of AWS resources: This type of permission allows users to read the state or change and delete resources created in AWS. For example, a user might have permissions to create and manage S3 buckets, change configurations, and delete configurations. Management permissions can be granted over any AWS service.
Access to the contents of an AWS resource: This type of permission can allow access to the content held in an AWS resource through IAM authentication and authorization. With it, you can allow access to the contents of a database or a storage layer, access to post or read from a service, and so on. For example, you can allow a user to create, update, or read items in a DynamoDB database. Access permissions are not available for all AWS resources because some of the resources cannot be IAM integrated. An example of a resource where access permissions cannot be granted is an EC2 instance operating system.
These permissions can be granted very granularly to ensure that the user has the exact level of permissions required (so that, for example, the user is only able to create but cannot delete S3 buckets or is only able to read content from DynamoDB).
When assigning permissions, you use statements within a policy that have one or more actions over one or more resources allowed or denied. You can also include conditions that can define an even narrower scope of operation, such as how, when, or where the action can be executed. Figure 2-3 shows an example of an IAM policy with granular permissions and multiple actions being allowed over multiple resources.
Figure 2-3 IAM Policy Statement with Two Actions
To assign permissions to a large number of users, you can use groups. The ability to group users who require the same type of access into a functional object enables you to ensure that these users have exactly the same permissions and makes the management of the user-based permissions much easier. The use of group-based permission distribution is also a best practice. This chapter takes a detailed look at users, groups, roles, and policies.
Users
A user in AWS represents an identity principal that can be independently authenticated and that can hold long-term credentials. With a user, you can uniquely identify any person, system, or other resource that connects to AWS and performs any kind of action over AWS resources. This can be very useful when you need to track the exact principal calling the APIs of your AWS resources or when individual identities are required due to compliance with laws, regulations, and security standards.
The IAM user gives us the ability to easily create, manage and use AWS resources as well as access the content within the resources. It is always advisable to create an IAM user and use AWS resources with an IAM user instead of using the root user created for the account. The root user does not necessarily need any specific identity, whereas each IAM user has a well-defined identity and is usually named after and assigned to a user or system.
When you create a user, you only need to specify a username. This username initially does not have any permissions or credentials assigned to it.
Access Keys, Secret Keys, and Passwords
When you assign credentials to a user, you need to explicitly specify what type of credentials you would like to assign to the user. Credentials allow users to log in to the AWS environment and issue calls against an AWS API. Each call that the user makes needs to be signed with an associated credential. The signing process allows the AWS environment to authenticate the user and authorize the action for each and every request made against an AWS API. Two types of credentials can be created for a user:
Password: In combination with a username and an account ID, a password can be used to authenticate against the AWS Management Console. If the user requires access to the console to manage resources from the AWS GUI, a password should be assigned to the user. Once a user is authenticated, a temporary token is generated that is used by the web interface so that the user does not need to continuously enter the username and password for each and every request.
Access key ID and secret access key: This pair of credentials allows for direct access to the AWS APIs or use of the AWS CLI and the AWS SDKs to perform actions against AWS resources. These two credentials can be used to call up AWS resources and sign each request being sent to the API. When using the CLI and SDKs, the signing of each request to the AWS APIs is built in.
To ensure that the passwords assigned to users are compliant with your enterprise security policy, you can introduce a password policy that addresses the complexity, length, expiration, and reuse of passwords as well as the ability for users to change their own passwords.
When defining a password policy, you should include the latest best practices from the security community and define a password policy that will allow users to create passwords that are relatively easy to remember and hard for attackers to guess or crack. In recent years, the computing power available has grown substantially, and it has been proven that shorter and more complex passwords do not increase the security of systems as short passwords are easy to crack no matter the complexity. Rather than introducing complexity, you should look at password length as the best way to ensure protection and help users remember their passwords.
For example, when you design a security policy, you might simply specify the minimum password length as 16 characters, which is commonly considered a length that is hard to crack and suitable as a minimum length for secure passwords. You can then instruct your users to come up with a sentence made up of three- to 6-letter words that make sense to them. For example, a password could be made up of a name, an action, a fruit, and a place. This would force the user to come up with an easy-to-remember and hard-to-crack password. Table 2-2 provides some examples of passwords that the users might come up with based on instructions like the ones given here.
Table 2-2 Ideas for Strong IAM Passwords
Name |
Action |
Object |
Place |
Password |
Length |
Anna |
Ride |
Bike |
Road |
annaridesabbikeontheroad |
24 |
Jimmy |
Eat |
Apple |
Park |
jimmyeatsapplesinapark |
22 |
Suzy |
Make |
Wood |
Fork |
suzymakingwoodenforks |
21 |
Bob |
Read |
Book |
Bed |
bobreadsabookinbed |
18 |
This very simple-to-remember approach ensures that the passwords easily exceed the 16-character minimum. With complex passwords, users often start with a commonly used password and then just add a capital letter and a number at the end. The word may be the name of a pet or some other easy-to-remember word, preceded by a capital letter and followed by the number representing the month and a special character. For example, if the existing password Fluffy01! were expiring, the user might simply increment the number to match the current month (for example, Fluffy02! for February). Unfortunately, such a practice completely defeats the purpose of the complex password mechanism and makes the password relatively easy to guess. If you implement long passwords with no complexity requirements, the rotated passwords have a higher likelihood to be much more unique and much harder to guess than passwords with a number incremented to match the month.
When programmatic access is required, best practice also dictates the rotation of the access key IDs and secret keys issued to the users. Regularly rotating the keys makes it possible to catch and block any applications where credentials were hardcoded into the code and forces developers to practice using roles instead of using hardcoded credentials in the application design.
MFA
To ensure an even higher level of security than is available with standard credentials for users, a multifactor authentication (MFA) approach can be implemented. When accessing the Management Console, a software or hardware authentication device or token can be used to provide multifactor authentication. Several different providers are supported by the AWS Management Console, and most software tokens can be implemented without incurring any additional expense. Best practice dictates that you secure any account that has any kind of significant ability to configure, deploy, and delete resources with an MFA device or token. Figure 2-4 shows part of the creation process for a virtual MFA. A user simply needs to scan the QR code to enable the virtual MFA.
Figure 2-4 Adding a Virtual MFA Device in AWS
MFA is supported when a temporary access key ID or secret access key is being issued through federation or through Security Token Service (STS). The MFA challenge is issued when the initial authentication request is made to AWS, and it is used throughout the lifetime of the temporary credentials. When the temporary credentials expire and new ones are requested, a new MFA challenge is also sent out during authentication so that the user can again authenticate with the MFA. With software MFA tools, this process can be automated to such a degree that the code can ask the STS for temporary credentials and then request a response for the MFA challenge from the central MFA server. With this approach, even automatic tasks can have multifactor authentication applied against them, which increases the security of the application and diminishes the possibility of an attacker stealing and misappropriating the temporary credentials.
Creating a User by Using the CLI
To create a user by using the CLI, you need to first configure the environment. If you have not done so yet, take a look at the configuration procedure described in the section “Accessing AWS” in Chapter 1, “Overview of AWS,” and make sure the output is defined as json. When the AWS CLI is configured, you can create a user by simply issuing the iam create-user command and specifying a username with the --user-name option, as shown in this example:
$ aws iam create-user --user-name Developer01
This command creates a user named Developer01 in the account. The account ID in this example is 999888777666. The output of the command in JSON is as follows:
{
"User": {
"UserName": "Developer01",
"Path": "/",
"CreateDate": "2019-06-01T18:02:15.521Z",
"UserId": "AJDEIX4EE8UER4",
"Arn": "arn:aws:iam::999888777666:user/Developer01"
}
}
As you can see, the output shows the following:
The username:
"UserName": "Developer01",The path where the user is created:
"Path": "/",The date of creation:
"CreateDate": "2019-06-01T18:02:15.521Z",The ID of the user:
"UserId": "AJDEIX4EE8UER422794",The ARN:
"Arn": "arn:aws:iam::999888777666:user/Developer01"
When the user is created, it has no other attributes (such as group membership or permissions). The sections that follow look at how to add the Developer01 user to a group and assign some permissions.
Groups
When working with users who perform the same tasks or who are simply required to have the same permissions and assignments across one or more AWS resources, you can use groups. Groups help organize and compartmentalize your users to make management easier. When you apply a policy to a group, you get the benefit of those permissions being inherited by any user who is a member of that particular group. Each user can be a member of one or more groups, and the permissions are always combined with a logical AND. Figure 2-5 shows different users as members of different groups in IAM. You can see, for example, that Tatyana is a member of Admins and Testers, and Sam is a member of Admins and Developers. The policies attached to these groups combine to give these users effective permissions.
Figure 2-5 IAM Group Memberships
When a change to the permissions is created at the group level, it is enacted immediately. Because the permissions for each API call are determined at the time of the call, any users belonging to this group will see the change in permissions as soon as they issue a request after the change to the group permissions has taken place.
Creating Groups by Using the CLI
To create a group by using the AWS CLI, you simply need to use the iam create-group command followed by the --group-name option. The following command creates a group called Developers:
$ aws iam create-group --group-name Developers
The output is similar to that of the --create-user command output shown earlier in this chapter:
{
"Group": {
"GroupName": "Developers ",
"Path": "/"
"CreateDate": "2019-06-01T18:05:52.134Z",
"GroupId": "AGPAYNEJ234IJVKUUJ89AF",
"Arn": "arn:aws:iam::999888777666:group/ Developers ",
}
}
As you can see, the output shows the following:
The group name:
""GroupName": "Developers ",The path where the group is created:
"Path": "/",The date of creation:
"CreateDate": "2019-06-01T18:05:52.134Z",The ID of the group:
"GroupId": "AGPAYNEJ234IJVKUUJ89AF",The ARN:
"Arn": "arn:aws:iam::999888777666:group/ Developers ",
To add a user to this group, you use the iam add-user-to-group command. With it, you can specify which user to add to the group by using the --user-name switch and which group to add the user to by using --group-name, as shown in this example:
$ aws iam add-user-to-group --user-name Developer01 --group-name Developers
This command does not have any output. To verify that the user has been added to the group, you can issue the iam get-group command and specify the group by using the --group-name switch, as shown here:
$ aws iam get-group --group-name Developers
The output of this command includes a description of the group and the users belonging to the group:
{
"Group": {
"GroupName": "Developers ",
"CreateDate": "2019-06-01T18:05:52.134Z",
"GroupId": "AGPAYNEJ234IJVKUUJ89AF",
"Arn": "arn:aws:iam::999888777666:group/ Developers",
"Path": "/"
},
"Users": [
{
"UserName": " Developer01",
"Path": "/",
"CreateDate": "2019-06-01T18:02:15.521Z",
"UserId": "AJDEIX4EE8UER4",
"Arn": "arn:aws:iam::999888777666:user/Developer01"
}
],
"IsTruncated": "false"
}
As you can see, the "Group" section of this output displays the group information, and the "Users" section shows information about all the users in the group. At the bottom of the output, the "IsTruncated" entry tells you whether the output of the command is listing the complete group contents or whether the content was truncated due to a filter or another operator being added to the command.
Roles
In certain cases, using a username and password or a secret key and access key ID just isn’t viable. In AWS, you can provide users, systems, and AWS services with temporary credentials that allow them to access the AWS APIs and perform management or data access actions in the AWS environment.
A role is a piece of metadata that can be specified in a request for authentication, and in return IAM can provide the requestor with temporary credentials that allow the requestor to perform actions that he or she would usually not be able to perform. This means that using a role is essentially a way to elevate a user’s access level without needing to store credentials that allow elevated access. This process is called role assumption.
Why IAM Roles and Role Types
Roles help with both the distribution of credentials and the securing of any elevated privileges being granted to users and other systems. They enable you to centrally manage permissions and allow a large group of users, a cluster of servers, other AWS accounts, or any number of instances of an AWS service to assume a role and perform an action that is allowed within the policy attached to that role. A user grants access to a specific user, whereas a role grants access on a broader identity scale, such as to a service.
User-Based Roles
Because a role assumption is an API call and can be tracked with the AWS CloudTrail service, you can create roles with elevated permissions and track each request to assume those roles. Having the insight into who is assuming the role and when allows you to maintain control over your environment at any time as any role assumption will be logged and can be automatically acted upon through alerts. The temporary credentials issued when assuming a role can also be immediately invalidated if the user assuming the role is performing the role assumption in an unauthorized manner.
For example, when you would like to perform any administrative action, you can create a role with the necessary permissions to perform that action. You can then allow certain users or groups the ability to assume that role. By assuming the role, a user releases his or her usual permissions and is granted the permissions of the role. You can create a process to record who is authorized to assume the role and when and create an alarm that triggers an automated check of those records. If a user is allowed to assume the role at that time, the system takes no further action; however, if the user is assuming the role out of the scope of the predefined timetable, the system can alert an incident response team and also invalidate the temporary credentials issued to the user upon assuming the role. This essentially locks the user out of the system and drops the user back to his or her original scope of permissions.
Using the approach described here, you can have users who are given read-only or very limited permissions as well as permission to assume certain roles. You can tightly control all actions being taken by these individuals through the logging of role assumptions, and you can lock out users who try to assume roles without prior authorization to do so.
Service Roles
Roles have many other uses beyond those described so far. For example, you can assign a role to a service. Service roles can be used by any compute service, such as EC2 instances, ECS containers, Lambda functions, and EMR clusters. When any of these services are started with a role, any applications running in the environment are able to retrieve the temporary credentials from the instance metadata. This means you can distribute AWS access credentials to the instance without having to hardcode them into the application code. Using service roles to grant permissions to AWS services is a best practice.
In addition to being a best practice, using roles can help you ensure that your applications are compliant with certain laws and regulations. This applies both when credentials cannot be stored locally and when credentials need to be rotated frequently. With the role assumption API, call you can specify the length of the temporary credential validity from 15 minutes up to 12 hours. By default, the credentials issued via role assumptions are valid for 60 minutes.
Cross-Account Access and Federation Roles
You can use roles when granting access to users external to your account. There are two ways to grant access to external users:
Cross-account access: You can allow users from other AWS accounts to access resources in your account. You simply send the role Amazon Resource name or ARN to the administrator of the other AWS account, and that admin can grant his or her users, groups, or roles permissions to assume the role. To assume the role, the administrator simply needs to specify the role ARN. Then those who assume the role gain access to the resources specified in the role policy. This is especially beneficial when you have multiple accounts and would like to manage them from a central account or when a third-party security, auditing, or compliance company needs read-only access to your account.
Federation: When you federate with external directories, you need to use a role to apply permissions. The user is authenticated by the external directory, and his or her group or pool membership is mapped to a certain role. The user can then use the AssumeRoleWithExtrenalDirectory API call and request temporary permissions from AWS IAM.
Creating Roles by Using the CLI
To create a role by using the CLI, you use the iam create-role command with the --role-name option to specify a name for the role and the --assume-role-policy-document option to specify the a policy that you wish to apply to the role. For example, say that you want to use the following policy that grants the EC2 service to assume a role:
{
"Statement": {
"Effect": "Allow",
"Principal": {"Service": "ec2.amazonaws.com"},
"Action": "sts:AssumeRole"
}
}
This statement would be followed by one or more other statements specifying the access granted to this role.
You need to save the policy to the iam.json file in the working directory and specify the name for the role by using the create-role command. In this example, the name is iamrole:
aws iam create-role --role-name iamrole --assume-role-policy- document file://iam.json
The output of the create-role command looks as follows:
{
"Role": {
"AssumeRolePolicyDocument": {
"Statement": {
"Action": "sts:AssumeRole",
"Effect": "Allow",
"Principal": {
"Service": "ec2.amazonaws.com"
}
}
},
"RoleId": "AROA4TKFDVDJMLTUVFSHG",
"CreateDate": "2019-06-01T18:28:00Z"
"RoleName": "iamrole",
"Path": "/",
"Arn": "arn:aws:iam::999888777666:role/iamrole"
}
}
As you can see, the output shows the following:
The statement of the role:
"Statement": {"Action": "sts:AssumeRole", "Effect": "Allow", "Principal": { "Service": "ec2.amazonaws.com" }The role name:
"RoleName": "iamrole",The path where the group is created:
"Path": "/",The date of creation:
"CreateDate": "2019-06-01T18:28:00Z",The ID of the role:
"RoleId": "AROA4TKFDVDJMLTUVFSHG",The ARN:
"Arn": "arn:aws:iam::999888777666:role/iamrole"
After the role is created, you can use it by specifying its name when creating EC2 instances.
Policies
To grant permissions in AWS IAM, you use policies. You have already seen a policy at work when creating a role. A policy is essentially a document that contains a statement. In the statement, you have an effect (either allow or deny), an action, and a resource. A policy can additionally have an identity principal specified and a condition that determines the effect.
Figure 2-6 helps you examine components of a simple policy that allows read-only access to an S3 bucket when the condition is met.
Figure 2-6 Simple Policy with Read-Only Access Based on Conditions
As you can see, the syntax of the policies is quite easily readable, and understanding the effect of the policy is not a complicated manner.
Types of Policies
Several types of policies can be created in AWS:
Identity-based policies: These are attached directly to identities and can be of the following types:
AWS-managed policies: These policies are created by AWS and managed centrally in IAM.
Customer-managed policies: These policies are created by the customer and managed centrally in IAM.
Inline policies: These policies are created by the customer and attached and managed directly at the identity principal. With managed policies, any changes are applied to all identity objects that have the policy attached, whereas with inline policies, the changes need to be managed on each policy individually. Inline policies, however, can be very useful when you need to establish a strict 1:1 relationship between a user, a group, or a role and the exact permissions that need to always be explicitly defined for that object.
Resource-based policies: These are inline policies attached and managed directly at the resource. For example, you can apply a resource-based policy to an S3 bucket and define the security principals that are allowed to access the bucket. This can allow you to manage the resource in a much easier manner because any changes to the bucket policy are applied only to that exact bucket.
Permissions boundaries: These can be applied to user or role identities and can define the maximum permission levels that can be assigned to the identity within one AWS account. Permission boundaries control only what kind of permissions can be applied and do not apply any permissions by themselves. You can use permission boundaries to control the scope of access before any access is granted and prevent administrators from overprovisioning the level of access required for a certain user or role.
Organizations service control policies: When using AWS Organizations, you can use a service control policy (SCP) to define the permissions boundaries for the organization member accounts and organizational units. SCPs work in the same way as permissions boundaries but can be applied in a dynamic structure across multiple accounts.
Session policies: When assuming a role or using federated access, session policies limit the permissions granted by a role to a user within a single session.
Access control lists (ACLs): Although ACLs are not IAM objects, they can be used in combination with IAM policies to determine the access to a particular resource in AWS. ACLs are very coarse access control mechanisms that can be applied to some AWS objects, such as S3 buckets. ACLs are always treated as public and cannot define access for any IAM entities within the syntax. ACLs do not use JSON and are defined at the resource level in a similar manner as resource policies.
Creating a Policy by Using the CLI
To create a policy with the AWS CLI, you can use the iam create-policy command and specify the policy file that you create. For example, you can use the file s3readonly.json to create a policy named s3readonly with the following command:
aws iam create-policy --policy-name s3readonly --policy-document file://s3readonly.json
The command returns the following output:
{
"Policy": {
"PolicyName": "s3readonly ",
"CreateDate": "2019-06-01T19:31:18.620Z",
"AttachmentCount": 0,
"IsAttachable": true,
"DefaultVersionId": "v2",
"PolicyId": "UWA6U32TTMNSSHA1MU53WV",
"Path": "/",
"Arn": "arn:aws:iam::999888777666:policy/s3readonly ",
"UpdateDate": "2019-06-01T19:31:18.620Z"
}
}
As you can see, the output shows the following:
The policy name:
"PolicyName": "s3readonly ",The date of creation:
"CreateDate": "2019-06-01T19:31:18.620Z",The number of principals it is attached to:
"AttachmentCount": 0,Whether the policy can be attached:
"IsAttachable": true,The number of principals it is attached to:
"DefaultVersionId": "v2",The policy ID:
"PolicyId": "UWA6U32TTMNSSHA1MU53WV",The path where the group is created:
"Path": "/",The ARN:
"Arn": "arn:aws:iam::999888777666:policy/s3readonly ",When this policy was last updated:
"UpdateDate": "2019-06-01T19:31: 18.620Z"
Identity Providers and Federation
As mentioned earlier in this chapter, in certain scenarios you need to use an external identity provider to authenticate users while granting them access through standard AWS IAM approaches. Federation can be a good way to provide users with a Single Sign-On (SSO) scenario. To enable federation with IAM, you need to first establish trust with an external identity provider. An identity provider is any type of supported identity system that you would like to use for the authentication part of the session. Basically, with a federated identity, you delegate authentication externally from AWS but still handle the authorization via IAM roles within AWS.
This approach allows you to extend the way you use AWS IAM identity principals and credentials out of AWS. Once you establish trust with the identity provider (sometimes abbreviated in AWS as IdP), you simply direct the users to log in to the identity provider’s directory. Once a user is logged in, the IdP either prompts the user to share his or her identity with AWS or allow access to the AWS services based on the group or user pool membership. Each group or other type of user pool within the IdP directory directly maps to an IAM role, and the service essentially allows an externally authenticated application or system to assume a role and request temporary credentials. When the temporary credentials are received, the application can connect to the AWS services. Figure 2-7 shows the authentication flow of a user accessing AWS through IAM federation.
Figure 2-7 Example of Federation with IDP
In Figure 2-7, the following actions take place:
The user browses to the corporate portal and selects the AWS Management Console as the application.
The portal sends an authentication request to the corporate identity store.
Once the user is authenticated, the portal generates a SAML assertion for the user, including the group membership that will help IAM determine the role to use.
Using the SAML assertion, the client is redirected to the AWS SSO endpoint.
The SSO endpoint retrieves the credentials for the user from STS.
The SSO endpoint responds with the credentials and a redirect URL to the AWS Management Console.
The client is able to access the AWS Management Console with the permissions defined in the role mapped to the group the user belongs to.
To issue the temporary credentials, Security Token Service (STS) is used in AWS. STS can issue two types of temporary credentials:
Temporary access key ID and secret access key: Issued directly to the user to gain access to AWS services in a programmatic manner. The application or service can use the temporary credentials to perform standard API calls to the AWS APIs.
Temporary access token: Issued to an identity broker and passed to the browser to establish a session with the AWS console without the need to reenter credentials; enables SSO to the corporate directory only.
Web Identities
Because IAM is integrated into AWS, using it is the perfect way to provide the complete cycle of authentication and authorization for users and applications running in AWS. IAM has some limitations, however. While the service can seamlessly authenticate any system in AWS and allow it to assume a role, any systems outside AWS require a secret key and access key ID or a username and password to be able to interact with AWS services. In addition, there is a limitation of a maximum of 5000 users in one account in IAM. To overcome both of these limitations in one go, you can use federation with a web identity. A web identity is an external directory accessible on the web, such as Amazon.com, Facebook, Google, or Twitter. These directories can authenticate a virtually unlimited number of users and can also allow you to authenticate users and devices running code outside AWS.
For example, a mobile application that requires access to DynamoDB to record access data, record its state, and perform other functions can simply be granted permissions through federation with a web identity. The back end in AWS can provide the login page from which the user can select a web identity service to log in with. The user is then redirected to the web identity provider, and the provider authenticates the user and returns an authentication token that can then be exchanged for AWS temporary credentials through the use of STS. Figure 2-8 shows the authentication flow when federating with an Internet identity provider.
Figure 2-8 Example of Web Federation
In Figure 2-8, the following actions take place:
The app requires the user to authenticate to the web identity. The web identity issues a token to the app.
The app creates an AssumeRoleWithWebIdentity request to STS with the token that was returned by the web identity. There are more steps involved, depending on the type of authentication and the broker, but in a nutshell, STS sends the token to the web identity to verify it. Once verified, STS returns AWS credentials (secret key and access key ID or AWS STS token) to the app.
The app is then able to use the temporary credentials to access resources in AWS.
To enable the back end to provide full functionality, you can either write your own authentication broker or use the Amazon Cognito service. Cognito allows you to easily federate an application with multiple directories, and it acts as a broker between multiple web identity providers and your application. Cognito can also be used as an identity store and can map users to Cognito user pools that can then be further mapped to different roles in IAM that provide the ability to retrieve credentials to access the AWS services.
OpenID
One of the authentication protocols supported by AWS web identities is OpenID Connect. With OpenID Connect, you have the ability to connect any compatible IdP to federate the identities with your application. OpenID Connect is based on the OAuth 2.0 standard and allows the complete authentication process to take place within the scope of REST API calls and responses between the identity provider, the identity broker, and the user or application requesting access. Designed for the web, it uses a standard HTTPS-based communication model for all steps of the authentication process. OpenID authentication is based on session tokens.
To authenticate and authorize a user request via an OpenID-compatible identity provider, the following steps need to take place:
The user logs in to the identity provider.
The identity provider returns an identity token.
The user uses the identity token to talk to the broker in AWS. This can either be Cognito or a custom broker designed by you.
The broker validates the token with the web identity.
Once the token is validated, the broker returns an additional token that will be used by the application in future calls.
When the application requires access to AWS services, it can request the credentials from the broker by specifying the broker token.
The broker validates the token internally and issues a request to STS for temporary credentials.
STS returns the credentials to the broker.
The broker forwards the credentials to the user.
The user is able to access AWS services directly with the STS-issued credentials.
LDAP and Active Directory
To federate an LDAP-based directory, you need to write a custom broker that connects to the AWS services and requests tokens directly from STS. The broker needs to use a trusted identity to get access to STS. On the other hand, if the service you are using is Active Directory, you can use Active Directory Federation Services 3.0 to provide the brokering of credentials between the users and the AWS IAM and STS. In both cases, the internal identity store is used as the authentication base, and the broker retrieves and passes the AWS credentials to the user during the final stage of the login.
SAML 2.0
To simplify the integration between AWS and corporate directories even further, you can use an SAML 2.0–compatible directory or portal. With a SAML 2.0–compatible portal, you can create an SSO solution that allows you to seamlessly integrate any AWS services or the AWS Management Console directly to the user side of the application. With a SAML 2.0–compatible approach, you simply log in to the portal, and the portal provides a SAML assertion that can be used in the calls to AWS. The SAML assertion can be included in the API request for credentials to STS directly by the user side, thus eliminating the load of the broker when requesting credentials. With a SAML approach, the credentials are issued directly to the user, which also reduces the scope of attack in case the portal is breached by a rogue actor.
Implementing Application Authentication and Authorization
By now you can see how to implement authentication and authorization with very little effort, using the features described in the previous sections of this chapter. But before jumping into an OpenID or SAML federation scenario, you need to answer a few questions:
Is federation required? Do the IAM users, groups, and roles provide all the features you require? Do you have more than 5000 potential users?
What type of federation can you use? Are you confined to a corporate directory, or can you use multiple IdPs?
Can you use an existing broker, or do you need to write your own?
Would it make sense to use a web identity?
What is the maximum credential lifetime required?
Using IAM with Applications
Whenever you can, you should implement IAM authentication within your applications. The authentication mechanisms built in to AWS can easily be used to provide full access control over any application running within AWS. It does not matter whether it is EC2 instances, ECS containers, or Lambda functions; all processing units within AWS can be identified by AWS and granted execution roles so that they can interact with AWS resources.
With federation, you can go a step further by providing identities outside the scope of AWS and granting permissions to users authenticated in operating systems, mobile devices, IoT pools, and other external systems. With AWS, you have the ability to organically grow your application from being a simple, IAM-integrated application to being fully federated with multiple external IdPs.
Encryption in AWS Services
This final section of the chapter looks at encryption in AWS. Encryption is not handled centrally in AWS since encryption capabilities might differ among services. But generally speaking, there are two types of encryption in AWS:
Encryption of data at rest
Encryption of data in transit
Encryption at Rest
For any data to be compliant with security regulations, it usually needs to be encrypted when stored on any kind of storage back end. Most, if not all, AWS services support encryption of data while it is stored. Whether the storage is temporary or permanent, encryption can be used to protect the data from a potential breach. The way you handle encryption at rest depends on the service you are using. The AWS services provide several types of encryption with different approaches to managing encryption keys:
Built-in encryption: Many services, such as AWS Glacier, provide built-in encryption. This can be configured by default when an object is created in the service. With built-in encryption, AWS handles both the encryption and decryption transparently by using an AWS-managed encryption key. Figure 2-9 shows an example of built-in encryption using S3.
Figure 2-9 Example of Using Built-in Encryption with the S3 Service
KMS integrated encryption: Key Management Service (KMS) can be used to create custom encryption keys for some services. With KMS, a customer can control the payload of the encryption keys and the rotation of the keys, but the master encryption key is still managed and rotated by AWS. Figure 2-10 shows an example of KMS-supported encryption.
Figure 2-10 Example of Using KMS Encryption with the S3 Service
CloudHSM integrated encryption: Some services additionally support encryption using a hardware security module (HSM). In this case, the customer has full control of encryption keys and manages the encryption keys from the root key onward. The HSM can be a great solution where the complete chain of custody of encryption keys needs to be specifically defined and fully managed by the customer.
Encryption in Transit
The second level of security involves providing encryption of data when in transit. The transit encryption is crucial not just to applications with specific compliance requirements but to essentially any modern application operating over the Internet. With hardware acceleration of encryption, there is no excuse to not use encryption in applications. There are several different options for providing encryption in transit for the applications running in AWS:
Web TLS: Access to any AWS API can easily be encrypted using TLS. You simply need to use the HTTPS API address, and all calls are protected by TLS encryption. In addition, you should be implementing TLS encryption on any HTTPS endpoints on any applications that you host on the web. If you are using a load balancer, an API gateway, or a CloudFront distribution, you can get a free X.509 certificate that can be applied directly to one of these AWS services and automatically renewed and rotated at no additional cost. This can be a great benefit because it can increase the security of your application dramatically.
Database TLS and TDE: TLS or TDE can and should be used to connect to RDS databases to ensure that the traffic is encrypted end-to-end.
Client-side encryption: If you are unable to use any of the standard encryption technologies and still need to secure data in transit, you can use client-side encryption. This basically means you encrypt the request, file, or data on the client side and decrypt it after it is received by the server or back end. Client-side encryption also works for database contents; you can simply encrypt the contents before storing them to the database; however, this increases the difficulty of any search, filtering, and analytics capabilities of your database back ends. Figure 2-11 shows an example of client-side encryption.
Figure 2-11 Using Client-Side Encryption with the S3 Service
IPsec VPNs: When transmitting data from an on-site environment to AWS, you can establish an IPsec VPN and thus encrypt the data at the transport layer. This gives you much more flexibility in terms of the choice of protocols in the VPN connection. IPsec VPNs can be established both over the Internet and over Direct Connect connections when transport layer encryption is required.
Exam Preparation Tasks
To prepare for the exam, use this section to review the topics covered and the key aspects that will allow you to gain the knowledge required to pass the exam. To gain the necessary knowledge, complete the exercises, examples, and questions in this section in combination with Chapter 9, “Final Preparation,” and the exam simulation questions in the Pearson Test Prep Software Online.
Review All Key Topics
Review the most important topics in this chapter, noted with the Key Topics icon in the outer margin of the page. Table 2-3 lists these key topics and the page number on which each is found.
Table 2-3 Key Topics for Chapter 2
Key Topic Element |
Description |
Page Number |
Ideas for coming up with strong IAM passwords |
43 |
|
Code example |
Creating a user by using the CLI |
44 |
Code example |
Creating a group by using the CLI |
46 |
Code example |
Creating a role by using the CLI |
49 |
Code example |
Creating policy by using the CLI |
52 |
Define Key Terms
Define the following key terms from this chapter and check your answers in the glossary:
Q&A
The answers to these questions appear in Appendix A. For more practice with exam format questions, use the Pearson Test Prep Software Online.
1. True or false: An AWS user can have both a username and password and one or two secret keys and access key IDs assigned.
2. What security principal does not have credentials directly assigned to it?
3. Complete this sentence: ________ can be assigned to an AWS service to allow it to access other AWS services.
4. If a user is a member of a group that denies that user access to S3, can you grant access to a specific bucket by assigning an inline policy to the user?
5. What is a web identity?
6. When federating IAM with an IDP, how are permissions granted to the user?
7. Complete this sentence: One of the benefits of federation with IAM is that you can support ______ any number of users.
8. True or false: By default, a Lambda function can access all the resources within your AWS account in an unrestricted manner.
9. What types of encryption would you recommend for a MySQL database when end-to-end encryption is required?
10. When connecting to an EC2 instance in AWS, what encryption options would you be able to use?