- [Seph] I spoke briefly last week about policies within AWS Identity and Access Management. More specifically, I talked about the parts of a policy that help you to fine tune the permissions you want to provide to users. Well, now I'm going to continue on with that conversation. Earlier, I covered the required components for every policy. Effect, action, and resource. To review, effect specifies whether the statement results in an allow or an explicit deny. As you'll remember, it's only options are allow or deny. Action elements describe the specific activities that are being allowed or denied. Each AWS service has its own set of actions that describe tasks that you can perform with that service and the documentation is the best place to find the actions you can control with the different services. The final one we covered last week was resource. This element specifies the object or objects that the statement covers. It is specified using the Amazon Resource Name, or ARN. Each service has its own set of resources and details for the ARN for a resource depend on the service and the resource. If you'll remember from earlier this week, the ARN has specific sections that are used to identify the service, region, account, and other necessary information in order to specify exactly which service or services the statement is controlling access to. The last thing I'll mention as review is that the action and resource sections accept asterisks (*) or wildcards, which represent a sort of auto-complete functionality. For example, you could list out actions such as EC2 run instances, EC2 describe instances, EC2 stop instances, et cetera, or if you were referencing Amazon EC2 actions, you could just use EC2 * (wildcard). The example policy we were looking at looked like this. This policy allows the user to launch a new EC2 instance with a wide open resource specification. So now that we've reviewed those parts, let's look at two additional parts of a policy that you should familiarize yourself with. First, we'll start with principal. The principal element in a policy is used to specify the principal that is allowed to access a resource. Principals can be AWS root users, IAM users, federated users, IAM roles, assumed role sessions, and anonymous users, which isn't generally recommended. Similar to resources, the principal is identified by its ARN which is specific to the type of principal you are referencing. As you see here, the principal we are specifying is the root user of the referenced account, which is done by using the AWS root user account identifier ARN. For more examples, make sure you check the course notes. I have linked documentation guiding you through how to reference principals. The final major section I want to cover is the condition element. The condition element, or block, lets you specify conditions for when a policy is in effect. This allows you to build expressions, utilizing condition operators, such as equal, less than, et cetera, to match keys and values in the policy against keys and values in the request context. The condition key can be a global condition key or a service specific one. Global condition keys have the AWS prefix while service specific keys have the services prefix, such as EC2. Looking again at our ever changing policy example, I have now added a condition block to identify which types of instances the user will be allowed to launch. In the policy, the user is allowed to launch three specific families of instances, but if they try to launch any instance family outside of these, they will be denied, unless another policy is associated that provides them with the additional permissions to do so. As with all of the other sections, I have provided some documentation in the course notes for you to use in order to dive deeper into the condition block. So now that you've heard about the major elements that exist, there is a simple way to remember these. The way to remember these sections is to remember E, P, A, R, C, or E-PARC. This simply stands for effect, principal, action, resource, and condition. This will help you to think through the elements that exist and think about what you need to utilize. The final topic I want to cover in this video is another reminder and that is the importance of the principle of least privilege access control. All of the sections of a policy are there to help you get as specific as possible in what permissions you grant to users, enabling you to grant only the permissions required to perform a task. When building policies, determine what users and roles need to do, then craft policies that allow them to perform only those tasks. Start with a minimum set of permissions and grant additional permissions as necessary. This is preferable to starting with broad or lenient permissions and trying to tighten them later. Okay, I'll stop there. As always, make sure you are reading through the course notes to gain better understandings of the topics we cover. Especially when it comes to policies, there is so much to learn. This should help you to build a good foundation, but you should have many of the document pages bookmarked in order to find them quickly for reference. We still have more to cover this week on policies, so I'll see you soon.
