- View Offline
- [Voiceover] 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 at the main AWS web console starting page. In order to create a policy I need to navigate to the Identity & Access Management Dashboard.
I do so by finding the Security & Identity section in the middle column and clicking the Identity & Access Management link. From the IAM Dashboard, I click the Policies link in the lefthand 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 radio 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 StopInstances. 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 awsMultiFactorAuthPresent. In the Value field, I type the word True. In order to add the condition, I click the intuitively named Add Condition button. As we can see, the condition reads that multifactor 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. 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's created, I get a get 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 0. 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. 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 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 organizations 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: users, groups, roles, and policies. At the end of the course, he helps you prepare for the inevitable audit of your AWS account(s).
This course includes trademarks owned by Amazon Web Services. This course has not been prepared, approved, or endorsed by Amazon Web Services.
- The AWS shared responsibility model and security landscape
- Enabling CloudTrail
- Configuring AWS Identity and Access Management (IAM)
- Troubleshooting IAM policies
- Granting temporary access
- Incorporating least privilege
- Controlling access to Simple Storage Service (S3)
- Preparing for security audits
- Getting audit help from Trusted Advisor