From the course: Hands-On Development in AWS

Exploring users and groups - Amazon Web Services (AWS) Tutorial

From the course: Hands-On Development in AWS

Start my 1-month free trial Buy for my team

Exploring users and groups

“

- We talked about policies in the previous lesson and we saw how policies are applied to users. Let's get a little bit more detail about users and groups. Users have two different types of access. We have programmatic access users as well as web console users. You can see here, programmatic access, we have this checkbox whenever we create an account. You can check it and it will enable this particular account for programmatic access. We also have password access available. This is for the web console itself. So, if they wanted to log in and actually view the screen that you see here on the right hand side of the slide, it would need to be a web console account. The programmatic access user type results in two pieces of information, the access key id, as well as the secret access key. Whenever you select that particular checkbox on the previous slide where you're creating that user, once you finally hit submit to create that account, it's going to display you with the actual programmatic access credentials. However, you should be aware that the secret access key shown here is only visible one time. When you click on that Show link right there, it will show it as you see over here on the right hand side. You must copy it and distribute it at that point. It is not viewable any other time down the road. If the user is a AWS Management Console user, you can, whenever you create the account, specify that the user should be able to change their password or rather be forced to change their password once they log in that first time. If they are an AWS Management Console access user type, you will see that they are enabled for access here. Users, however, can be both. As you see here, I've outlined it already. We have programmatic access as well as AWS Management Console access for this particular user named Dave. The permissions whenever you create a user account can be defined. You can also just leave it blank as we saw in the demo for the policy section. You don't necessarily have to attach a policy to a user when you create them. If you don't attach any and you have specified that this user needs to change their password, they will receive the policy that allows them to modify their password. Without any policies, they can't even change their password. You'll notice that this says that you can assign these policies when you create the account. However, it is a two step process if you are using the command line interface or SDK. You can, of course, interact with the IAM service in the command line interface or the SDK. If you create an account in the CLI, you would then need to make a subsequent call to associate the various permissions that you want to assign. Sources for our permissions that are associated with a particular user come from various locations. You can do a group assignment. If you do a group assignment, the user will inherit the permissions that are associated with the group. You can also copy permissions from another user. If you copy permissions, the permissions are associated with this new user account. However, keep in mind that if you change the permissions on that original account, it's not going to be copied over to that new user account. It's a one-time copy. You can also do manual policy assignment where you associate policies directly to the particular user. Permissions are inherited. Group level permissions are inherited by a user and then user directly attached permissions, take precedence over the group. Permissions are optional. Default is denied. You don't have any applied. This particular entity has no permissions. Let's do a quick demo and take a look at creation of user accounts and log in and what it looks like to actually be denied to access the services. We are in our IAM service and I am going to add a user. This user is going to be called deleteme. This user will be a web console user and a programmatic access user. We will do a custom password and I will type in the password here. And I'm going to uncheck Require password reset 'cause I don't want to have to remember that password after I change it. So, it is deleteme and then the password. And I'm going to attach policies directly to this user. This user is going to receive EC2 full access only. Next will be tags. No tags. Review our permissions and hit Create user. Now, I will get the programmatic access credentials shown to me here. I'm going to copy these and store them in notepad for a bit while we move around. Let's come over here. We'll copy that. And I'm going to open an incognito window and I'm going to log in as this new user. If I look at my dashboard for IAM, we can see that my account alias is this adguadgu? I can go directly though. So, let's go ahead and do that. Here's our direct link to log in to this IAM account. And I'm going to log in as deleteme and the password. And we will log in. And recall that this account can only access IAM services. So, what happens if I go to the S3 service? What is it going to do? Nothing in the S3 service. I don't have anything actually created. You'll notice I cannot create a bucket. I can't delete, can't empty, can't do anything. No buckets. There might be a bucket, but I wouldn't know. This particular user does not have the ability to list S3 buckets. However, if I go to the EC2 service... While this is loading up, let me over here, go into the S3 service and I'm going to create a bucket and we will see what happens over there in the other window. I will create a bucket and this will be called deletemebucket123432. In Northern Virginia, the ACL is disabled. I don't need to do anything unique on this bucket. I just want a bucket to exist. Leave it as default. We can see this bucket exists here, deleteme bucket. And over in EC2, this restricted user called deleteme can do anything the account needs to do within the EC2 service. Let's go back to S3 and see if we see our new bucket. This deleteme bucket that was created by the Nick account. No buckets. I cannot create bucket, I can't do anything. So, I have zero permissions to the S3 service as a result. I can't even see that bucket that was created by this other user over here. So, we created a user, we created a programmatic access user as well as a web console user. We attached a policy directly that restricted him or her to EC2 only. Programmatic access credentials would give us the same result. Let's go ahead and take a look at that. So, let's hop into our Linux instance and we will run aws configure. And I will provide those credentials that I saved without the space at the end. And our secret key. And we'll do us-east-2 and json. Okay. So, if I'm on aws ec2 describe-instances, I should get a response. No reservations. This is in us-east-2. It should be us-east-1. There's our single instance up and running. And if I were to do, for example, aws sqs list-queues, I should get a failure. Yeah, access denied. So, this user has programmatic access. The policy is associated for EC2 read only, or rather EC2, full access, and they can do whatever they need to do. So, we looked at account creation, two different types of access, programmatic versus web console, association of policies and what happens whenever they log in, what they can actually see whenever they have those restricted policies.

Contents