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 explore designing your own custom IAM policies for roles, groups or users. Most of the time, you'll probably use one of the policy templates provided by AWS as we described and showed in the IAM Roles video. But sometimes, if you're looking for something more precise, you'll want to cook up your own.
Let's go to IAM. We'll click on Groups. There's a couple of groups that we've already created, let's click on devs and let's take a look at one of the policies we created for this group. You noticed that the policy is made up of a number of key elements. Effect, that is this is the effect this policy will have. It will, in this particular case, allow certain behavior and action, which defines what behavior that will be. In this case, because there's a star, an asterisk, it's any behavior, anything that the user would want to do in relation to the resource we're going to see in a minute will be allowed.
The third key element is resource. Where will the user be able to do this? Well, in the S3 bucket in this case called shared-bucket-acme. That's how a policy is structured. You'll notice, of course, that it's done in JSON format.
Let's cancel this and let's attach another policy. Let's try creating a brand new policy. Again, there are many policy templates you could choose from but we're talking about someone whose needs are more specific. So let's select Custom Policy, give the policy a name. That's a very descriptive name, which will be most helpful through the course of your use of this policy. Of course, I'm only being cynical. It won't be helpful at all.
You really should give it a more descriptive name normally and let's paste in a policy statement that's a little more complex than the one we showed you just before.
This, by the way, is an example from the AWS documentation. It has, as you can see, a first statement, a second statement and a third statement. I believe that's it, just three statements. So effectively this is divided into three parts.
There are three different rules you're creating. In the first statement, will allow. Its effect is to allow. It will allow the following action, that is, change password in IAM. The user with whose profile this policy is associated will be allowed to change his own password where on any resource associated with this AWS account.
The second statement also will allow. It will allow ListAllMyBuckets on S3 and again it will apply this ability to list buckets will apply to all S3 buckets that are associated with this account. The third statement again is allow as opposed to deny, of course. It will allow an action. Well, there's more than one action in this particular case.
It will allow you to list and will allow you to get in S3 because both of these are in S3, but this time specifically associated with the confidential data bucket and anything underneath the confidential data bucket, meaning any directories or folders that have been created and any data in any of those folders that are under the root confidential-data bucket.
In this case also, it's a little bit different in that a condition was added. In this case, this process will only be allowed, this access to the buckets will only be allowed if the multifactor authentication is present and has passed and has a value of true. Only if he has successfully logged in using multifactor authentication, then he will have this access of list and get associated with this specific bucket.
One more note, AWS will actually try to parse the policy and check it for accuracy. Let's say I would add an extra curly brace right here and then try to apply the policy. It wouldn't let me.
There's a problem, as you see, the policy is not in valid JSON format. Remove the curly brace, apply the policy and it works.
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.