From the course: AWS Certified DevOps Engineer Professional (DOP-C02) Cert Prep

IAM overview

From the course: AWS Certified DevOps Engineer Professional (DOP-C02) Cert Prep

Start my 1-month free trial Buy for my team

IAM overview

“

- [Instructor] The AWS Identity and Access Management Service, or IAM for short, is a web service that helps you security control and manage access to various AWS resources. The two primary functions of the service are quite obvious based on its name. It's for managing the identity of your users and for providing access management to the resources and services available in your account. In other words, it handles the authentication and authorization aspects of your cloud infrastructure. The identity aspect of IAM helps you identify who are the validated users or entities in your organization. This is also known as authentication. An IAM identity can be an IAM user, an IAM user group or an IAM role. If you create a new AWS account, the very first user that will automatically exist will be the root user. A root user is accessed by signing in with the actual email address and password that you use to create the account. This user is quite powerful as it can change your account settings, access your billing details, or even close down your AWS account. It also allows you to create individual IAM users within your AWS account that corresponds to the users or the actual employees of your company. You can create an IAM user for your administrator, for your developers, for your network engineers, and so on. These IAM users are not separate AWS accounts, but are just regular users that exist within your AWS account. Let's now talk about the authorization function of the IAM service. An IAM user can be authorized to access and control your AWS resources. You can create a policy that contains multiple permissions that authorize the IAM user to do a set of actions. This is the access management aspect of the IAM service. You can manage the type of access your users should have by attaching an AWS-managed policy, a customer-managed policy, or an inline policy to different IAM identities. An AWS-managed policy is a standalone policy that is managed by AWS, whereas a customer-managed policy is a standalone type that you administer in your own AWS account. An inline policy is a type that's just embedded in an IAM user. This inline policy can be embedded in an IAM group or an IAM role. You can even attach multiple policies to a single IAM user. The IAM service is where you apply the concept of granting the least privilege. This concept simply states that should only grant defined set of permissions necessary for the entity to perform this designated task. By doing so, it ensures that no resource can execute an operation that it is not meant to do, thereby reducing the security risk of unauthorized actions. For example, you have a new DevOps engineer in your company that only needs access to the AWS CloudFormation templates to create multiple AWS resources. After creating an IAM user, what permissions should you provide without compromising security? At the very least, you should add the IAM user to an IAM group with a policy that only allows AWS CloudFormation actions. If the user does not need this access anymore, you can then easily remove him or her from that IAM user group. You can also create an IAM role that explicitly defines the CloudFormation permissions necessary for the new hire to properly do his or her job. This is a perfect example of following the best practice of granting the least privilege to your users. If you add this user to an IAM group with PowerUserAccess or an AdministratorAccess IAM policy, then that's a security risk. This means that a DevOps engineer can do a lot of administrative actions that are out of scope and may adversely affect your resources. What's worse is if you hand over the account root user credentials. The user can certainly perform the necessary CloudFormation stack operations, but you're putting the security of your entire cloud infrastructure in imminent danger. Again, you should only grant the required permissions to your resources using the various policy types available in IAM. Aside from granting access to an individual person, you can also provide access to different AWS resources, such as your EC2 instances, S3 buckets, Lambda functions, and others. For Amazon EC2, you can use the Instance Profile to pass a specific IAM role to your EC2 instance for it to perform certain actions, like uploading data to Amazon S3 or other operations. These IAM rules attached to your instance can also be viewed on your EC2 metadata. If you have a Linux virtual machine, just type curl http://169.254.169.254/latest/meta-data/iam/info to view the list of attached IAM roles. For Amazon S3, you can set up a bucket policy to grant IAM users at other AWS accounts the access permissions for your bucket and its objects. Say you have multiple AWS accounts in your AWS Organizations that represent different departments. If one department wants to share an Amazon S3 bucket with all other departments, you can set up an S3 bucket policy that allows cross-account access to other departments. You can also use IAM in your databases. For DynamoDB, you can design an IAM policy that allows access to put, update, and delete items in one specific table. This policy can be attached on IAM role that can be used by a Lambda function or an ECS task to manage a particular DynamoDB table in your account. There's also a security feature called IAM DB Authentication for Amazon RDS and Aurora. This feature allows you to use IAM to centrally manage access to your database resources, eliminating the hassle of managing user access individually on each DB instance. It also improves the security of your application hosted in Amazon EC2 by not storing the database password and just using its instance profile to connect to Amazon RDS. For Amazon SQS, you can set up an access policy to control external access to your SQS queue. This is helpful if you need to grant permissions to an external company to access your queue. An SQS access policy can be prepared to allow the other company to poll the queue without giving up the permissions of your own account. In IAM, there are two primary types of policies that you can use. These are identity-based policy and resource-based policy. Basically, identity-based policies are attached to an IAM user, group, or role, while resource-based policies are attached to a resource like E2C instances, S3 buckets, and others. You can also use permissions boundaries for your IAM users and roles. A permissions boundary is a feature that allows you to set the maximum permissions that an identity-based policy can grant to an IAM entity. With this, an entity can only perform the actions that are allowed by both its identity-based policies and its permissions boundaries. In our succeeding lectures, we'll learn more about the Identity and Access Management service, or IAM, we'll discuss the different IAM identities, IAM policies, and its other concepts. We'll also cover the unique evaluation logic of the IAM policies that control access to AWS resources.

Contents