- [Seph] If you've watched through all of the demos in this course, and if you started experimenting with AWS IAM yourself, you've likely run across having your access denied. Whether you're using the AWS Management Console, making calls through the SDKs, or using the AWS Command Line Interface, unexpected denials of access can be frustrating to encounter. When working through building policies, you quickly learn that while it may be easy to get started in building simple policies, the more specific you try to get, the more troubleshooting that needs to be done. Using the AWS managed policies can definitely help, but they're not going to cover every use case. And when you need to build your own policies, you'll want ways to test the policies. One way to test the policies is simply to apply them to a test user or group to try out the permissions. This works but it can be a bit time consuming adding the extra step of making calls as another user. A more direct method is simply to use the IAM Policy Simulator. The Policy Simulator allows you to test calls against existing policies that you've built in your account, and also provides a method to test out calls on policies that you are actively building. One way the simulator can be accessed is from the IAM console by going through a group as you see me doing here. That brings me to the landing page for the Policy Simulator. Here, there are four major sections to the page that we'll focus on. First is the top banner. This is where you are provided with the ability to choose your mode, whether you want to work with an existing policy, or if you want to work on creating a new policy. I'm going to focus on existing policies for this demonstration, but you should definitely try working with creating policies in the Policy Simulator. Keep in mind that it's best for copying in a document and then making small changes as it does not provide any of the guidance given by the visual editor in the AWS IAM console. The second section I want to draw your attention to is the area that allows you to choose what you want to test. This allows you to choose whether you want to test calls against policies associated to your users, groups, or roles. Additionally, when you select one of the entities, you are also able to select which of their associated policies to test against. As you currently see, this testers group has two policies attached. I could leave both of them selected to enable testing all of the access that this has, or I could only select one of them to test only that policy. If I click on one of the policy names, I'm then able to see the actual policy document. Clicking in the box also allows me to directly edit the JSON document if I want, and then apply those changes. For this demo, I'll keep them as they are, but it's nice to have the ability to make the changes you need while you're in the simulator. The group I want to actually test is the S3 access group. And it only has one policy, so I'll keep it selected. Now onto our third section. This area is the main part of the Policy Simulator. It allows you to select the service and actions that you want to test. I have created this group with an AWS managed policy to provide read only access, but I want to verify that it does not allow for associated users to write to my buckets. Under select service, I'll type in S3 and select that service. Using the search allows for me to skip through all of AWS's long list of services to find the one I'm looking for. After that, under select actions, I'll specify which calls I want to test against this group's policy. The tool allows me to select multiple actions at once to save time in my testing. I'll select delete bucket, delete object, get object, and put object for this test. Once I do that, I can just click on Run Simulation and that will bring us to our fourth and final section, the settings and results. This area allows us to see what response would be received if a user in this group were to make these specific calls. As you can see, all except get object would be denied if a user were trying to make these calls. This is expected and reassuring because it means that this read only access is in fact read only. All of the actions show if they're implicitly denied, but if there is a statement in the policy pertaining to one of the actions, it will call that out. If I expand the permission that is allowed, I'm also able to show the specific statement in the policy that allows this action. This would also be the case if there were an explicit deny in the policy. For this policy, the statement is pretty much the entire policy, but if I had a policy that was longer and had several statements, clicking show statement would take me directly to the associated section in case I wanted to make some changes. And that does it. The IAM Policy Simulator is a great tool for helping to test and build policies and should be one of the primary tools used when working through building or troubleshooting your policies. All policies should be fully evaluated before they are put into use to make sure that you are following least privilege access principle, doing all you can to avoid mistakes due to access. Make sure you are checking the course notes for a direct link to the Policy Simulator. Keep in mind that you need to be signed in to an AWS account in order to access the Policy Simulator, as it needs to know the details specific to your account in order to accurately test. That's it from me for now. Talk to you soon.
