- [Instructor] In this lecture we introduce and explore the Identity and Access Management Service, or IAM, which is a very important security service offered by AWS. Let's first ensure we understand the security context that the Identity and Access Management Service and ensure we understand what the service is and is not. IAM is a web service that allows you to control access to your AWS resources. So to fully understand how this works let's first ensure that we know the difference between authentication, authorization, and access control. Many people assume these words mean the same thing with no obvious distinction between them. This is, however, untrue. And as a result, people often use the wrong term to describe their security mechanisms.

Before we delve further into what the IAM service does for security and AWS, let's first review each of these concepts so you understand the differences. It's important to know these differences in order to control access to your cloud resources effectively and with the appropriate level of security. Let's start by looking at authentication. The authentication process is comprised of two parts of information. The first part of this process is to define who you are, effectively presenting your identity. An example of this would be your login user name to your AWS account or environment.

This identification is a unique value within the system that you are trying to authenticate to. And in this example, AWS would not allow two identical user accounts to be created within the same single AWS account. The second part of the authentication process is to verify that you are who you say you are in the first step. This is achieved by providing additional information, which should be kept private and secret for security purposes. However, this priority information does not have to be a unique value within the system. So in the example I just gave, whereby you provide your identity in the form of a user name to your AWS account, which will be a unique value, the next step would be to verify the identity by providing a password.

Putting AWS and the cloud to one side for a moment, user names and passwords are not the only form of authentication from identity and verification process. In our everyday lives we are presented with multiple forms of authentication methods. For example, credit debit cards and pin numbers. So when we use these to pay for something we authenticate to our banks. In this process we firstly identify ourselves by providing the credit debit card details with our personal information. And then verify the information by entering a private secret pin number. This combination then allows authentication to our bank.

Authentication is not just for verifying human access to systems. Authentication takes place by systems that require access to other systems. For example, one AWS service requiring access to another to perform a function. In this instance the same authentication principles and process is followed. Identify first, and then verification of the identity. Now that we have a clear definition of authentication, let's take a look at authorization and see how authentication and authorization differ from each other.

Authorization only takes place once an identity has been authenticated. So there is a clear order as to which these two operate. Authentication takes place before the correct level of authorization can be obtained. Authorization is the process in which the system you have authenticated to establishes what you can access and at what level. So here we're really looking at your access privileges and permissions. Staying with our AWS example, we have authenticated ourselves by providing the correct identity and password.

Now AWS security features, and in this case AWS IAM, Identity and Access Management Service, defines the level of authorized access assigned to the identity within the AWS environment. Each identity can have a different level of authorization properties associated to it. It's these properties that determine what that identity can then access. So IAM is the service that controls access to your AWS resources by controlling authentication and authorization of users and systems.

IAM is not, however, an identity store or authorization system for your applications. It's important to remember that IAM does not enable you to manage the permissions within your applications. IAM is a global service, meaning that you don't have to create rules for each region. The identities that you create are valid throughout all AWS regions used by your AWS account. Now that we have a basic understanding of how IAM works in the context of cloud security, next I'll show you how to get started using this service in the AWS Console.

However, before we do that let's define a few key concepts. There are three principles in the IAM service. First we have the root user. The root user is the most powerful access credentials in an AWS account. The root user is associated to a unique to the account record, and it cannot be restricted in any way. It's recommended best practice to strictly limit the use of the root user credentials to privileged tasks only, such as billing and entity management. The second principle is the IAM user.

IAM users are persistent identities controlled via IAM. This means you can associate roles and policies to an IAM user, thereby restricting or allowing access to services or resources. In a corporate account you might have 20 IAM users, each with different access policies and groups attached. IAM users are identities that we can create within the IAM service. In the context of IAM, a user can be anything. As the name suggests, you probably would associate it with a person. However, you can also associate it to a service, a cellphone, or in these days with the emergence of the Internet of Things, even your refrigerator.

So an IAM user is an identity that you can create in order to grant access to your AWS resources. An IAM user can have a password associated with it. But it's important to highlight that using a password with an IAM user is optional. You will only need a password if your user is going to interact with AWS by the AWS Console. Another optional tool is user access keys. Access keys are used to interact with AWS programmatically.

So you'll need them if your user will be working with, for example, one of the AWS SDKs or the AWS Command Line Interface, also known as the AWS CLI. The most important edition for user authentication is multifactor authentication. Multifactor authentication adds a hardware or software generated key to a login authentication process. This device reduces risk of user name password compromise by requiring the IAM user to enter a one time generated key when logging into the console. Multifactor authentication adds another layer of security when logging into the AWS Console. As your user will not only have to provide a password to login, but also the secret number through the MFA device.

IAM groups simplify the management of IAM users. We can assign permissions to a group instead of assigning it to an individual user and then insert the user into a group. In this way you can create general permissions that will apply to a certain group of users. The key benefit is that you only need to do it once and it will be set for all users in the group. If you want to revoke the permission for a single user you can simply remove it from the group. Moving a user or users between groups is simple as well. Much easier than constantly manipulation individual user permissions as work situations change for example.

The third principle is roles. Roles provide temporary access with different credentials. Roles are in essence identities. They're similar to users in that you can assign policies to them to specify the permissions that they might have. However, roles were designed to be used by more than one entity. It means that many entities can assume a role. An IAM user, a service such as EC2, or even users outside your AWS account can assume a role.

Since roles can be used for more than one entity, it makes sense that they have no credentials of their own. You just need to have permissions allowing you to assume the role in order to absorb permissions that were assigned to the IAM role. This is both helpful and secure. You only need to specify exactly who can assume the role, and AWS will manage credential verification for you. For example, let's say that you have a backup service running in your AWS services that sends data to S3 buckets. You can create an IAM user with access keys to send data to the backup bucket using a script that relies on the AWS CLI.

For that you'll need to configure the AWS CLI with your access keys. But that would require you to either have the keys saved on the instance or configure them manually. The issue is that it's not secure to store credentials on an instance. And updating the credentials on all instances that use them would be painful. A better approach would be to assign permissions to the instances to assume a role that already has permission to store files in the backup bucket on S3. In this case you won't need to configure credentials into any instances.

It's all done automatically. Further, AWS will dynamically rotate the access keys used to grant access to the S3 bucket. Roles are a powerful tool in managing secure access to services and resources. A role is generally assumed via a temporary security token, e.g. simple token service, STS, and will expire after a set period of time. Roles provide a powerful and flexible way to keep control of who and what is authorized to access your resources and services.

If an IAM user account is compromised we can reduce access to services by disabling or expiring the role credentials assumed by that user. Policies are the way to define the permissions and rights that an identity will have. You can associate policies with users, groups, or roles. The standard role gives an identity no rights at all. So you need to explicitly declare the rights of an identity through a policy. The policy document is written in JSON format and will look something like the example shown here.

Learning how to create and read policy files is beyond the scope of this course. What you do need to know is that policies are used to allow or deny actions. However, since the default behavior is that the user has no rights unless you explicitly add them, it's more common to have policies with allow actions. It's important to realize, however, that an explicit deny action overrides any allow actions. That concludes this lecture on the AWS Identity and Access Management Service.

Let's summarize the features we've covered in this lecture. First, we learned that the root user is the most powerful accessed credential in an AWS account. The root user is associated a unique to the account record and it cannot be restricted in any way. Second, we learned that IAM users are persistent identities controlled via IAM. This means you can associate roles and policies to an IAM user, thereby restricting or allowing access to services or resources. We learned that IAM groups simplify the management of IAM users.

We can assign permissions to a group instead of assigning it to an individual user and then insert the user into a group. Then we explored roles. Roles provide temporary access with different credentials. Roles are in essence identities. They're similar to users in that you can assign policies to them to specify the permissions that they might have.

However, roles were designed to be used by more than one entity. It means that many instances can assume a role and IAM user. A service such as EC2 or even users outside your AWS account can assume a role. That concludes this introduction to the IAM service. I do encourage you to get started with our lab so you can experience the IAM Console and set up firsthand. The Cloud Academy labs provide a great way to experience the IAM services first hand. Thank you for your attention. Any questions or feedback, please reach out to us at support@cloudacademy.com.