From the course: AWS Security Best Practices for Developers

Important concepts - Amazon Web Services (AWS) Tutorial

From the course: AWS Security Best Practices for Developers

Start my 1-month free trial Buy for my team

Important concepts

“

- [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 a federated user that locked 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. An developer for example may require access to Cutmate, Cloud9, EC2 and others. But this person probably does not need to see audit logs within Cloud Trail or change any network settings within the Bitro private cloud as these tasks are performed by other employees within the organization. A preferred away 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, database administrators, developers, and super users. Any and all changes made to the group will apply it 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 give 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.

Contents