In this video, take a look at Identity and Access Management, IAM, what it's used for, and the difference between authentication and authorization. Explore IAM users, groups, policies, and roles, as well as the Principle of Least Privilege.
- [Instructor] Understanding Identity and Access Management is a crucial concept to secure administration of your AWS account. Going forward, I will simply refer to Identity and Access Management as IAM. What is IAM and what is it used for? Generally speaking, IAM has two primary functions. The first function of IAM is to authenticate users. By validating the combination of a username and password, the authentication function of IAM is complete. For example, let's say you have a Netflix subscription for streaming movies and television shows. In order to log into your account, you have to supply your username and password. In the context of IAM in AWS, authentication is the combination of an IAM user and the user's security credential. The second function of IAM is the authorization of users. For example, you have a valid username and password for Netflix. However, you are unable to stream any content because you have a single stream plan, and one of your family members is actively streaming. That is, you're not authorized to access content, despite the fact that you authenticated successfully. In the context of IAM in AWS, authorizations specifies the services that an IAM user has access to, and the actions the IAM user can perform on those services. In AWS, the creation of an IAM user allows you to give more than one person individualized, auditable access to services within your account. Suppose you have 100 people in your organization who need access to your AWS account. Instead of the catastrophically bad idea of sharing the root account credentials with the entire group, each person instead, should have an individual IAM user. Attempting to manage authorization for 100 people independently is a nightmare for any system administrator. Fortunately, IAM in AWS supports the concept of groups. Remember the 100 people who need access to your AWS account, chances are they already fall into existing organizational groups. These groups can include engineering, quality assurance, information security, and finance. You'll want to consider your existing group structure and how to project that into AWS IAM. Once you have your users mapped into groups, you can spend time considering the types of resources you'll be using in AWS, and the permissions associated with these resources. For example, for EC2, different permissions exist, which grant the ability to stop, start, reboot, or terminate an instance. Once you've considered and aggregated permissions into logical collections, you can assign permissions to IAM policies. Remember, permissions are granular in nature, and there are many possibilities for every service AWS offers. A policy is simply a collection of permissions you want to grant to people. Once you have IAM policies in place, you can proceed to assign policies to IAM groups. As you establish IAM groups, you can assign individual IAM users to those groups. In AWS, policies allow you to manage access to resources in a very granular fashion. For instance, you might give your engineers the ability to create, stop, and terminate EC2 instances. On the other hand, you likely want to prevent the finance department from taking any action in your AWS account that is not billing related. Keep job roles in mind as you design your IAM infrastructure to support it. Another important concept to internalize is that AWS IAM is built on the principle of least privilege, that means that by default, access is denied. While AWS has many policy layers, let's step through a simplified identity based policy evaluation process to see what happens when a user tries to access a resource. By default, that access request is presumed to be denied. Then, the IAM policies for the user and resource combination in question are evaluated. If there is an explicit denial of that action in the policy, the user's access is denied and the evaluation workflow stops. An explicit deny trumps everything period, full stop. If there isn't an explicit deny in the policy, the evaluation process looks for an entry that explicitly allows the action in question. If there's an explicit allow, the action is permitted, otherwise, access is denied. Remember, if you see an explicit deny statement in a policy, the associated actions are denied. Only if there is no explicit deny and an explicit allow is an action permitted. Integrated across many AWS services, IAM has some nifty additional features that are an asset when controlling access. You have the ability to apply IAM policies to a role. Roles can be assigned to a specific resource. For example, you can create a policy that allows read write access to an S3 bucket, and assign that policy to a role. Then, you can grant that role to an EC2 instance. Any instance that has that IAM role applied to it when launched will have the ability to read and write to the specified S3 bucket. You can grant temporary access to resources using the secure token service. This is useful when you want someone to have access to resources on a time-limited basis. AWS IAM supports identity federation, so, if you already manage users external to AWS using something like Active Directory, you can map AD identities to IAM users.