As your organization grows, more and more people are going to need access to your cloud resources. The ability to create and assign granular permissions is crucial to ensure the safety of your data and to avoid unauthorized access to reserved information.
Identity and Access Management (IAM) is the AWS tool that gives you centralized control over your AWS resources. It allows you to create fine-grained policies using JSON syntax to grant unique privileges to each and every available resource. This course will tell you everything you need to know to get started hardening your infrastructure.
Who should take this course
As a beginner to intermediate course, you'll require no previous experience, nevertheless some knowledge of AWS and its main services (like EC2 and S3) would really help you better understanding the concepts you'll encounter. You may therefore want to check out other AWS courses before tackling this tutorial.
Do you have questions on this course? Contact our cloud experts in our community forum.
In this video, we'll learn how to effectively manage users and groups so that each member of your team can get to whatever resources he or she needs but has no access to whatever isn't necessary.
We're going to setup users and groups for a hypothetical company so that besides clearly defined relationships to general computing resources users will also be able to access their own S3 buckets and a shared company-wide S3 bucket.
Let's click on "IAM" and then "Groups." We're going to create a new group. We're going to call it "Admin." Click "Next Step." We had to select an Access Policy for the Admin group. Let's give them administrator access, which is full access to all AWS services and resources. This is obviously access you should only give to team members who need this kind of access and who know how to use it.
You'll notice that the Access Policy is spelled out in a JSON formatted text. Just to take a quick look the effect to the policy will be to allow all behavior, that's the asterisk or star, all actions on all resources. Let's go to the next step and create the group.
The group at this point has no members so it's not going to do a whole lot of good. Let's create another group though and we'll call it Devs, the developers for our company. Rather than giving them administrator access, which they don't need and might not be able to manage that well, let's scroll down and give them AWS connector access. That'll enable strong access to EC2 objects and S3 buckets the kind of services they'll have to access in the process of their work.
Here we see they're allowed as an example access used through IAM to get users so they could list all the users that IAM defines in our system. In S3, they'll be able to list all buckets concerning any resource in S3. That's the star. Similarly, they'll be able to create buckets, delete buckets, delete object, get bucket, all location, etc.
Concerning EC2 the computing instances they'll be able to delete tags, create volume, create tags and perform many of the functions necessary in the life cycle of EC2 instances and they'll be able to do that on any, because of the star, any EC2 instance associated with this account.
Let's go to the next step and create this Group too. We now have two groups but no users. Let's create some users. Create new users. Well we'll call one Ted and one Alan. Let's say Alice and Steve. We'll create those users. We'll show their security credentials. We may have to securely transfer those credentials to these users so they'll be able to get in to our system. But once that's done they'll have access to whatever we allow them. Let's close.
Now let's go back to Groups. Let's click on "Admin" and add users to the Admin group. I only want to add Alan because he's our sys amin so I'll add him to the Admin group. He now has the full rights and accesses that have been associated with the Admin group.
Let's go back to Groups. Let's now click on "Devs" and add users to this group. And we'll add the other three and they will now have all the rights and nothing but the rights and accesses that were defined as part of this group.
Let's go back to Users and let's click on "Alice." Let's create a new user policy for Alice so beyond the general rights and accesses that she has because she's part of the Devs group we're going to give her her own S3 bucket, where she can store objects. We'll click on "Custom Policy" and select the "Editor" to allow a custom policy. Let's give this policy a name.
Let's call this policy Alice's Private Bucket and assuming that we've already created an S3 bucket on our account called "Alice Bucket Acme," assuming that our company name is Acme Widgets. Then this policy would give Alice access to everything on S3 that is associated with this resource Alice's Bucket Acme. Let's apply the policy and Alice now has access to her private S3 Bucket on our AWS account.
We can do the same thing of course for all the other users. However, there's a group policy that we'd also like to apply to the Devs Group, which already has these three users Ted, Alice and Steve. Let's scroll down and attach another policy. This too will be a custom policy and we will open the Custom Policy Editor. Let's call this one "Shared Bucket Access" and paste the JSON formatted code for this policy.
This one will allow any members of this group full access, that's the star again, to all S3 resources that are associated with this bucket that we've created called Shared Bucket Acme. Assuming we've created a bucket policy on S3 that will allow access. Any users who are currently a part of the Devs group will be able to access all the resources on Shared Bucket Acme and also to create and edit their own. Let's apply the policy.
So what we've done now is create users and assigned them to specific groups. We've assigned access policies to each of the groups and we've given access to each user to just those S3 buckets where they need access.
David taught high school for twenty years, worked as a Linux system administrator for five years, and has been writing since he could hold a crayon between his fingers. His childhood bedroom wall has since been repainted.
Having worked directly with all kinds of technology, David derives great pleasure from completing projects that draw on as many tools from his toolkit as possible.
Besides being a Linux system administrator with a strong focus on virtualization and security tools, David writes technical documentation and user guides, and creates technology training videos.
His favorite technology tool is the one that should be just about ready for release tomorrow. Or Thursday.