In this video, the instructor defines and explores the concepts around the AWS IAM service.
- [Instructor] Identity and Access Management, or IAM for short, is a critical tool that has a significant impact on all AWS services. Everything you'll create within your AWS Cloud will need to have permissions granted and managed by account owners or administrators. This is done from the IAM Console. Before jumping to our console, let's take a moment to learn some useful terminology. An identity within IAM is a resource for which you want to be able to manage permissions.
It could be a single user, a group of users, or it could simply be a role that you assign to an AWS service in order to access another one. As we'll see later in the course, it can be federated user that logged in through another identity provider. Policies are JSON-formatted documents that specify which actions to allow or deny to an IAM identity. By default in AWS, all access is denied unless you specify otherwise.
A user account in IAM is one way to give individuals access to resources within this AWS account. These permissions will need to be in line with the role they perform within your organization. A developer, for example, may require access to CodeCommit, Cloud9, EC2 and others but this person probably does not need to see other logs within CloudTrail or change any network settings within the virtual private cloud as these are performed by other other employees within the organization.
A preferred way to manage users within IAM is by using groups. Groups help you avoid having to repeat yourself when assigning policies to users individually. Just group them in a way that makes logical sense for your company. For example, network engineers, data administrators, developers and super users. Any and all changes made to the group will apply immediately to all members of the group. As we mentioned earlier, in IAM you can assign access policies to a non-user identity.
This is called a role and you can assign it to your application servers, for example, in order to given them permission to access your message queues, databases and other services. Please note, this is not to be confused with security groups which control access at the networking level. Roles control access to AWS services, not network traffic. Let's look at the next diagram. In this example, a developer launches an EC2 instance that gets a role assigned at boot time. When the application running inside this EC2 server attempts to access the photos S3 bucket, it will be able to do so.
This is very convenient because this way your application can be deployed to a staging or production environment and you don't need to provide an access key pair for it to be able to run. When a resource has permissions from a role, IAM will give a set of temporary credentials that match the permissions associated with the role.
- Identity and Access Management security
- S3 security policies, encryption, and version control
- KMS encryption
- User authentication with Cognito