This Total Seminars course covers the exam certification topics. For information on additional study resources—including practice tests, lab simulations, books, and discounted exam vouchers—visit totalsem.com/linkedin. LinkedIn Learning members receive special pricing.
This course was created by Total Seminars. We are pleased to offer this training in our library.
- IAM principles
- Authentication and authorization
- Multi-factor authentication
- AWS Security Hub
- Shared responsibility model
- Password policies
- IAM roles
Skill Level Intermediate
- Throughout this course, we've been looking at AWS management. We've seen how to do everything from creating S3 buckets to setting up EC2 instances and more. But everything we've done so far, we've actually done it using the account root user identity. In other words, we've done it using the account that was initially set up an AWS service account. The reality is that in a production environment, you're going to want to move beyond that. You're going to want to have other ways to manage access so that you can give different people access or different processes access. And what that means is you need to understand a concept that we call identity and access management. And in this chapter and the next, we're going to be exploring IAM, identity and access management, in-depth. So you understand what it offers to you and how you utilize it within your environment. It is absolutely essential that you understand IAM concepts in-depth for the exam. So make sure you pay close attention as we go through this material. Now the first thing I want to do is define for you what IAM actually does. Identity and access management is about managing access to AWS itself. So to be very clear, it's not about managing the operating systems in your instances or the services that run in your instances or the applications that run on your instances. Or even access to files that are hosted in EBS volumes inside of instances. In other words, all of that stuff is managed with Linux permissions and Linux accounts, Windows permissions and Windows accounts, and so forth. You don't manage those through AWS IAM. AWS IAM is all about deciding what people can do as far as the AWS cloud goes. Can they launch an instance? Can they actually create an S3 bucket? Can they put stuff in an S3 bucket or delete stuff from an S3 bucket? So it's all about what people can do within AWS. Now it supports users, groups, and roles, and we're going to get into all of those in more detail. It's very important to keep in mind that using IAM is free. So it doesn't cost you anything to create a user account. There's no charge per month for each user account or anything like that. There's no charge for roles, there's no charge for groups. So using IAM is free. However, AWS services implemented by users that log on with their IAM credentials do incur charges. So if you give someone the ability to be an AWS admin, for example, and they can go in and launch instances, keep in mind that if they launch an instance, your account will be charged according to whatever that instance is. So it's very key, before I go any further in this episode, that you understand that it is important to train these users. They need to understand AWS. Maybe they should go through a course like this one. But they need to understand the impact of their decisions within AWS. Because they need to know that if they launch an instance that costs $30 an hour and they do it within your account but you didn't actually need it, you're going to get billed for that. So it's important to understand, IAM is free, but what people do who are given IAM credentials is not necessarily always going to be free. Now let's talk about some important IAM concepts. First of all you have resources. Resources are the things on which actions can be taken. So, for example, EC2 instances are resources. So someone can have the power to start or stop an instance. They are acting on a resource. So resources are the things on which actions can be taken. And then principals are the things that can take action. So principals act and they act upon resources. Principals include users, groups, and roles. And again, we're going to explore all of these in detail. Then we also have the concept of policies. So all of your rights or permissions, your authorization capabilities, come through policies. And these policies are based on JSON and we'll be looking at that later on in this chapter. So, IAM allows you to define principals that can act on resources and the way you do that is through the creation of policies. Now what I want to do is talk to you a little bit about the IAM architectural model. What does it look like and how do all of these things come into play? So let's take a look at this. First of all, you have the principals, and as I said, principals are your users, your roles, and of course users can be put in groups so that they can be given permissions together. That is, I can apply a policy to a group and then that policy ends up applying to all the users in the group. So we see that we have these objects of principals and then these principals are authorized through either identity-based policies, such as JSON policies that are either created manually or through a visual editor, or they are given these authorization capabilities through policies that are attached to groups. So it's either identity-based policies or group-based policies. And then we have resource-based policies as well. So we can attach a policy to a specific resource, allowing someone to do something on that resource. Then there are actions they can take. So they can act on the EC2 service. They can act on the IAM service itself. They can act on the S3 service. So we could give someone the ability in the IAM service to create a user, delete a user, get user information, and so forth. In S3 they could create a bucket, delete a bucket, list a bucket, and so on. So the key thing here to understand is there are actions that can be taken and those actions are taken against resources. When you understand this hierarchy, this model, you have a principal that can be authorized to take an action on a resource, everything becomes more clear with IAM. Now this model is very important to understand because it is how IAM determines what someone's going to be able to do. And we're going to explore the different parts and pieces of this model in more detail as we go along in further episodes of this chapter. But for now, you need to keep in mind that IAM is there all the time, when someone logs in to the AWS console or they're using the command line interface, or even a program is using APIs to talk to AWS. Whatever the method is to come in, IAM is there and it's watching attempted actions and determining whether they're allowed to take that action or not. If they're allowed, they let it happen. If they're not allowed, they deny the action. This is what IAM is all about. (jazz music)