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 about the key basic concepts that drive the IAM system. IAM itself is a centralized way to efficiently control access to your AWS resources. IAM policies precisely define relationships between principles and resources. A principle by the way in AWS terms is a user, a group or an AWS service like an EC2 instance. By resource in this context, we mean an S3 bucket and its contents or an EC2 instance and the data and services it provides. By policy therefore, we mean control over exactly who can read, write, create, or delete an object or a service. We associate either directly or indirectly IAM policies with users, groups and roles. Using IAM you can define the way users access AWS through passwords, access keys, MFA or identity providers. When users are associated with groups, any policies attached to the group by definition are now binding on all the users who are part of that group. A role is not associated with the user or a group but with a service like an EC2 instance.
So the instance in our example will be assigned specific privileges and limitations so that any service running on the instance let's say web server that's running on an EC2 instance will be limited or opened up by the content of the role associated with this instance. The bottom line is IAM policies are meant to control the behavior of each principle.
Let's take a quick look. Clicking on a specific role will provide you access to the role policies, which you can edit if you like you can add new role policies.
It'll also display the ARN Amazon Resource Name that is unique to this particular role. Therefore, if you want to associate a particular role with an Amazon service you might be required to enter this specific and unique ARN. Just one important note IAM policies are not synonymous with S3 bucket policies. Even though both are often written in JSON formatted text and they look the same, they actually have a very different orientation. An IAM policy controls the behavior of each principle where it can go, what it can access, what its limitations are.
An S3 bucket policy on the other hand controls what can happen to a bucket. So even though S3 policies and formally ACLs would appeared to have overlapping goals with IAM they actually work in a way in opposite directions just be aware of that distinction.
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.