- [Tutor] IAM policies are a critical tool for effective granular permissions management within AWS. IAM policies are used to control what happens when a given operation is executed against a resource within AWS. This control can be as granular as your organization needs. For example, suppose a company wants to give its newly hired DevOps engineers access to start, run, and stop EC2 instances. However, in order to prevent accidental loss of work, the company wants to inhibit the ability to take any other action, especially instance termination.
That is easily accomplished with an IAM policy. Policies can be assigned to IAM users individually, to IAM groups, or to IAM roles. This allows for the separation of the authoring of policies and their association with people or resources. To assist with managing common authorization use cases, AWS provides a large number of managed policies. A good example is the read-only access policy. Since it is maintained by AWS, as new AWS services are rolled out, you can be assured that read-only access to those services will be added to the policy without any action on your part.
If you have a complicated policy with both access and deny statements on the same resource, access to that resource will be denied. Bottom line, an explicit deny always wins in IAM policies. Let's go into the AWS console to create a custom policy that satisfies the use case of allowing newly hired DevOps to run, start, and stop EC2 instances. Here I am in the main AWS web console. In order to create a policy, I need to get to the IAM dashboard. Since we've been there recently, a link for IAM is in my shortcuts and recently viewed services, near the top of the screen.
From the IAM dashboard, I click the policies link in the left-hand navigation to get to the policies configuration screen. Clicking the blue create policy button takes me through the three-step create policy wizard. At this point I have three options. I can use an existing AWS managed policy as the foundation for my custom policy. I can use the policy generator to help create my custom policy. Or if I'm very familiar with JSON and IAM policy syntax, I can write my own custom policy from scratch.
In this case, I will use the policy generator, so I click the blue select button in that section on the screen. Since the default behavior is to deny actions and I want to allow my DevOps to have full access to EC2 except for terminate, I leave the effect radial button on allow. From the AWS service dropdown, I select Amazon EC2. You can see by the sheer number of services, how complicated policies can get if you want them to. Finally, I am going to allow the run, start, and stop actions.
In the actions dropdown list, I scroll to the bottom and check run, start, and stop instances. Since I want this permission to exist across all EC2 instances, I put an asterisk or star in the Amazon Resource Name field. Finally, following best practices, I want to guarantee that users have MFA enabled in order to be able to take any action. In order to do that, I click on the add conditions link. In the conditions dropdown, I pick Bool for a Boolean operator.
In the key dropdown, I select AWS MultiFactorAuthPresent. And in the value field, I type the word true. In order to add the condition, I click the intuitively named add condition button. And as we can see, the condition reads that multi-factor authentication has to be on. Comfortable that this statement reflects what I want to do, I click the add statement button. Now that I've constructed my policy statement, I click the blue next step button to review the policy.
The first thing I want to do in the review policy screen is specify a policy name. I like to use a prefix, so that all my custom policies are grouped together. I go ahead and intuitively name this policy, sbn-ec2-run-start-stop. In the description field, I describe what the policy does. The description reads, this policy is intended to be used on new hires in the DevOps department. It only allows the ability to run, start, and stop EC2 instances.
Although it is tempting to click the blue create policy button at this point, I'm going to click validate policy to make sure there are no syntax errors. Upon seeing the green, this policy is valid message. I can proceed by clicking the blue create policy button in the lower right. After a brief delay while the policy is created, I get a confirmation screen indicating that its creation is successful. If I type my prefix into the filter box, it filters in real-time to show the policy itself.
That's another reason why I like to use a prefix, as it is really easy to see all of the policies I've authored. Note that the number of attached entities is zero. This tells me that no groups, users, or roles are using my newly created policy at this time. IAM policies are tools that allow a remarkable degree of specificity for managing access to AWS resources. The interface I just walked through illustrates how complex policies can get. When constructing policies for the first time, remember to take your time to deeply understand what you want to do and how to best accomplish your goals as efficiently as possible.
Use conditions to further restrict when policies can be used. For example, specifying that MFA must be in use. You can refactor your policies as you learn more, use new services, or as new services are released by AWS. And experiment with policies in a non-production AWS account. Finally, remember when writing policies, a deny action always wins. For instance, suppose you have two policies applied to a user or a group. The first policy allows read-write to S3 and the second policy denies access to S3.
The result will be that user or group will not be able to write to S3. Remember, for any situation that requires access to AWS resources, if you can imagine it, you can write a policy to handle it.
Sharif Nijim couples pragmatic advice with practical examples that educate IT pros on how to create a secure infrastructure within Amazon Web Services. Sharif explores the shared responsibility model of security, which splits duties between your company and AWS, and introduces key identity and access management concepts, including users, groups, roles, and policies. Learn how to configure Identity and Access Manager (IAM) and Simple Storage Service (S3) access management, including policies and access control lists. At the end of the course, Sharif helps you prepare for the inevitable audit of your AWS account(s).
This course is also part of a series designed to help you prepare for the AWS Certified SysOps Administrator – Associate certification exam.
- Summarize the AWS Shared Responsibility Model.
- Recall how to implement separation of duties.
- Differentiate between assigning permissions to an individual versus a group.
- Summarize how to create IAM roles.
- Describe how to secure financial access.
- Recall the steps for managing access to S3 with IAM.
- Cite the advantages of a pre-signed URL.