We're going to begin our conversation on handling people, classes, and functions. In the previous class, we spoke about how you can not use the root admin account for day-to-day administration. We spoke about how you build and grant administrative rights to an individual admin account.
Okay, in this tutorial, we're going to delve further into handling people, classes, and functions. We're going to think about whether you're adapting rules to certain apps and classes, and we're also going to speak about how you're utilising IAM positions. So let's just go ahead and get going. IAM users are unique users who have
been given access to an AWS account.
So if your company gives you access to their AWS account, then you are in IAM user. Every IAM user is made up of three basic components a username, passwords, and then the permissions that allow it to access the AWS resources. Without the permissions being explicitly granted to an IAM user, that user will not be able to access any AWS services. This is because AWS works on the principle of least privilege.
Any time you create user accounts, they have access to nothing. All they could do was log in. You have to attach a policy to that user in order for that user to be able to access any resources. So let's take a look at how that works. So we have a user named Mark and Mark wants to access this S3 bucket. Well, when we create Mark's account, if we come over here to the dashboard, we'll go to users and then add a user.
Spinning users on the AWSVMs
And let's add a user named Mark, and we're going to give Mark the ability to log in to the AWS console. And I'm going to set a password. So the password created here has to match the password complexity rules that we created in the previous lesson. I'm going to uncheck require the password reset and click "Next" for permissions. Now, at this time, Mark doesn't have permissions to anything.
So I'm just going to go ahead and click "Next" and again tags are how you organize and track your resources. So you can assign tags that will help you to easily identify how things are grouped together. So I'm going to go ahead and click "Next." This user has no permissions, which is what we want and click "Create User." So Mark's account exists, but Mark can't access anything. He wants to access this S3 bucket. When he attempts to access the S3 bucket, he gets an access denied.
Now, the way we're allowing Mark to access the tool is to create an IAM policy and add it to the user account of Mark. So let's go back over here to the users.
Let's close this with a user window. Click on Mark's account and notice that we can assign permission here. We will attach an existing policy to
Mark's account because there is already a policy here that does what we want. So I'm going to go to search for S3. And here there is an S3 full access policy. So that's what we're doing here is we're attaching this IAM S3 policy to Mark's user account. So let's go ahead and click "Review." That looks good. Click "Add Permission." So now Mark actually has access to be able to save files or store files in that S3 bucket.
Now let's say that Mark has some additional team members who want to be able to access this bucket. Well, let's create some accounts for them. So let's go back to users and add a user. We're going to create the user Adrian, and we're going to add the user James. We're going to also give them the ability to log in through the AWS console.
AWS password strategies
I'm going to set the password. We're going to uncheck the require password reset and go to permissions, and we're not going to associate the permissions just yet and next for tags and next for review. These users have no permissions. That's fine. Let's click "Create the Users" and close. So now we have these user accounts, and these user accounts do not have access to the S3 bucket. Now we could associate that same policy with the user's individually. The disadvantage of doing that is the fact that we have to do that for every individual user.
So imagine if you have 50 user accounts and you had to go to each of these accounts individually to associate that policy. While rather than doing that, we actually can set up a group. So we're going to create a group called Dev and then we're going to put our users into that group. So let's go over here in the management console to groups, create a new group, and our group name is dev.
And we're using that S3 policy so I'm going to search for that S3 full access click "Next" and "Create." So now we have our Dev group. I'm going to select the group and notice it says there are no users in the group. We're going to add users and we're going to add Adrian, James, and Mark to the group. Click the "Add Users" and all of these users are now in the group.
Now what I am also going to do as I'm going to go to users and I'm going to go to the user Mark and notice how this looks. Mark has the S3 full access policy attached directly to him, and he also has it attached from the group. I'm going to remove the one where the policy is attached directly to his account, and I'm going to confirm that I want to detach that.
So now his membership in the group is what gives him access to that policy. Now, the advantage of doing that is that now all I have to do is add and remove users from that group, the Dev group, to remove their rights or access based on that policy. So initially we put all three of them in the group and then we attached the policy to the group.
Groups of the IAM
And by attaching that policy to the group, we've granted all of them access to the S3 bucket. Now, if we remove Mark from the group and we're on our user Mark already, so we go ahead and remove him from the group. Then Mark loses his access.
He'll get an access denied when he attempts to access that data. But ultimately, we want Mark to be part of the group with all of his team members. So we're going to go ahead and leave him as part of the group. Okay, so we just put—checked the box to put him back in the Dev Group so that again gives him access as a member of the Dev group to that S3 bucket.
Now let's go ahead and take a look at roles. Now sometimes you have AWS services that need access rights to other AWS services. So what if we were processing data on our EC2 instance and needed to save that data off to our S3 bucket? Well, in order to do that, we would need to create what's called a role. Without that role our EC2 instance would get an access denied when it attempts to access S3.
But we can then add a regulation to that role by creating this, the function of IAM, so that we can then access the bucket S3. Both of these are based on IAM access policies where our users and groups have either the policies attached directly to the community member. And then you have IAM positions where we add a policy
to the role so that another AWS service can access it.
Conclusions and final words
So let's have a look at what this screen looks like. So if we move over to roles here, you could see I've got some error messages here. You should only forget those from everything else that I've been working on.
Do you want to learn more?
IAM users, groups, and roles. Thanks for watching. I'll see you in the next lesson.