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're going to explore IAM roles, the AWS mechanism for controlling the access and behavior of services and instances rather than users or groups.
Policies work pretty much the same way for users and groups as they do for roles. Unlike policies for users and groups however, when you're creating a new role, you must first define the role type and only then its policies.
Let's click on IAM and then roles. Let's create a new role. Let's call it new role, click on next step and first we have to define the role type. There are three broad categories. Role for cross account access, that is if we want to allow access to one of our local services from a service or a user in a different Amazon account. We can do it using one of these role types or role for identity provider access, if you want to allow access to our services from users who can log in using outside accounts like a Google account or a Facebook account. We could do that.
We're going to focus on AWS service roles, that is what an Amazon service will be allowed to do, what access it will have to other Amazon services once it's associated with this particular role. We could, as in our example we will, create a role for an Amazon EC2 instance that would determine what, where, when and how the services running on our instance could access, let's say an S3 bucket or some other Amazon service.
We could also, however, define how a data pipeline might behave, elastic map produce might behave, opts works might behave, all these are role type templates that Amazon has created.
So let's select Amazon EC2 and now let's define the policy that will determine how a session associated with this role will be allowed to behave. Do we give it full access, administrator access to every service and resource running in our whole Amazon account or will the services in our local instance be allowed to access services and resources elsewhere on the account but not management of users and groups? Will they have read-only access? What will their access be to Cloud formation, Cloud search, Cloud trail, Cloud watch, data pipeline, direct connect, upstream, etc. All the services and resources that could be available by category in your Amazon account. The access to them from our EC2 instance will be defined here.
So let's select Amazon direct connect full access, which as it says here, will provide full access to AWS direct connect via the Amazon AWS management console.
This is the policy that defines this role, that is the effect will be to allow any resource that a user or service on our instance will try to apply the action will be direct connect, will be allowed direct connect. And the resource will be any resource because of the star, it means any resource associated with our Amazon account that this instance will try to use direct connect against, will be permitted, will be allowed.
Click on next step and review and then create the role. The role now exists. You can also custom define your own role policies and this we'll discuss in a later video in the series.
AWS also offers a terrific service called the Policy Simulator, where it will test for you the results of any action against a particular policy. Let's try it out.
Let's click on manage policy for any policy really at all. Then click on the IAM policy simulator and let's work by users. We could also work by groups, but let's work by users. Let's take Alice and Alice has three policies associated with her account. So let's click on this one, which tells us that requests to S3, to list all my buckets for instance, are allowed. Get user requests from IAM are allowed and a great many other requests to S3 are allowed along with EC2.
Let's now select the service we'd like to test. Let's say S3 and let's say list all my buckets, which we know is something that's permitted and delete bucket. Let's try those two actions and see how Alice will be able to perform them. Let's run a simulation.
List all my buckets is allowed. Delete buckets is denied, which is exactly what the policy had outlined. We can run the same test, of course, against every element of every policy on our account to see if it actually works in the real world.
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.