Hello and welcome to this lecture. Where we will be taking a deeper look at IAM policies and how these are created, modified, and constructed. I will also show you the syntax and structure of these policies.

So as we already know, IAM policies are used to assign permissions to users, groups, and roles. But what do these policies look like? IAM policies are formatted as JSON documents, Javascript objectmentation. And each policy will have at least one statement, where the structure may look like this example. Let me break the structure of this policy down to allow you to understand each element.

- Version: This going to the policy language version and at the time of writing this course, the current policy version is 2012-10-17.
- Statement: This defines the main element of the policy, which will also include other sub-elements, including Sid, Action, Effect, Resource, and Condition. These elements will identify the level of access, granted or denied, and to which resource.

So let's now understand what each of these are for. Sid. 
- The Sid Statement ID is simply a unique identifier within the Statement array. As you add more permissions, you will have multiple Sids within the Statement. 
- Action. This is the action that will either be allowed or denied, depending on the value entered for the Effect element. Actions are effectively API calls for different services. As a result, different Actions are used for each service. For example, for delete bucket action is available for s3, but not for ec2. And likewise, the create key pair action is available for ec2 but not s3. The Action is prefixed with the associated AWS service.

For example, you can see on the screen here we have two Actions for cloudtrail, one is to CreateTrail and the other is to DeleteTrail. Or you could, as seen on screen, use an asterisk as a wild card which represents all Actions for the cloudtrail service, essentially granting full access to the service.

- Effect: This element can either be set to allow or deny, which will either grant or restrict access for the previous Actions defined in the statement. These two options are explicit. By default, access to your resources are denied and, so therefore, if this is set to allow, it replaces the default deny. Similarly, if this was set to deny, it would override any previous allow.

- Resource: This element specifies the actual resource you wish the "Action" and "Effect" to be applied to. AWS uses unique identifiers, known as ARNs, Amazon Resource Names to specify specific resources. Typically, these ARNs follow a syntax of.

- Partition: This relates to the partition that the resource is found in. For standard AWS regions, this section would be AWS. 
- Service: This reflects the specific AWS service. For example, s3 or ec2. 
- Region: This is the region that the resource is located. Some services do not need the region specified, so this can sometimes be left blank.
- Account-id: This is your AWS account-id, without hyphens. Again, some services do not need this information, and so it can be left blank.
- Resource: The value of this field will depend on the AWS service you are using. For example, if I were using the Action "s3:PutObject", then I could use the bucket then I wanted those permissions to apply to using the following ARN.
- Condition: This is an option element that allows you to control when the permissions will be effective based upon set criteria. The element itself is made up of a condition and a key-value pair. And all elements of the condition must be met for the permissions to be effective. In the example, the IP address is the condition itself, which the key-value pair will be effective against.

The AWS Source IP is the key and the IP address is the value of the key. So effectively, what this is saying is if the Source IP address of the user who is using the policy is within their 10. 10. 0. 0/16 network range, then allow the permissions to be used.

As I mentioned previously, you can have multiple Sids within a statement, each granting a different level of access.

The example below demonstrates this and I have highlighted each a different color to show the separation.

The first Sid allows any resource full access to "cloudtrail" as long as their Source IP address is within the 10. 10. 0. 0/16 range.

The second Sid allows any resource to have full access to "autoscaling".

The third Sid allows the creation and deletion of s3 buckets within the "iam-course-ca" bucket on s3.

Typically, IAM policy will have these elements that we have just discussed. But sometimes, additional elements are and can be used. A full listing of these elements can be found here. Now we know what an IAM policy looks like, I want to talk to you about two different types of IAM policies available.

These being Managed Policies and In-line Policies. Managed policies come in two different flavors, AWS Managed Policies and Customer Managed Policies. These managed IAM policies can be associated with a Group, Role, or User. Although assigning to a User is not best practice, the difference between AWS and Customer Managed is as you would expect.

The AWS Managed policy have been pre-configured by AWS and made availble to you to help with some of the most common permissions that you may wish to assign. For example, these two AWS Managed policies covering s3. By selecting one of these policies, the necessary IAM JSON policy and its permissions will already be configured.

The two policies are configured as follows. The difference between the two separating full access from ready only is made clear in the "Action" element. The great thing about these AWS Managed policies is that you are able to edit them and make tweaks and changes before saving it as a new policy. This then becomes a Customer Managed policy.

This is great when an AWS Managed policy is almost as you need it, as it saves you time creating the policy from scratch. Let's look at a scenario.

A user requires read only access to everything on s3, plus the ability to create new buckets for management purposes. To create the appropriate policy for this user, we should consider using the AWS Managed policy "AmazonS3ReadOnlyAccess", which would give us the "ReadOnly" permission. But it would need to be copied and altered to allow the creation of buckets too.

Therefore, during the creation of this policy, the AWS Managed "AmazonS3ReadOnlyAccess" policy would be selected and then edited, as shown in red, to grant the additional "CreateBucket" permissions. So Customer Managed policies are any IAM policies that do not follow a pre-defined AWS Managed policy.

There are a number of ways to create a Customer Managed policy. These being the following: 
- Copy an AWS Managed policy. This is what we just covered, where an existing AWS Managed policy is used and then edited to create new Customer Managed policy. 
- The Policy Generator. This allows you to create a Customer Managed policy by selecting options from a series of dropdown boxes.
- And you can create your own policy. If you are proficient in JSON and the syntax of IAM policy writing, then you can create your own policies from scratch or paste in a JSON policy from another source.

I now want to give you a quick demonstration of how to create a policy in each of these three ways. The demonstration will include: how to create a Customer Managed policy by editing an existing AWS Managed policy; how to create a Customer Managed policy using the Policy Generator; how to create a Customer Managed Policy from scratch; and how to validate your policies and why this is important.

Okay, I'm at the AWS Managed console and if I just go across to "IAM", and then across to "Policies", and "Create Policy", and here we have three options: "Copy an AWS Managed Policy", "Policy Generator", or "Create Your Own Policy". So I'm going to cover each option, but start with I'm going to copy an AWS Managed Policy and create a Customer Managed Policy by doing so.

So if we click on "select", we can see here a list of AWS Managed policies. Now for my policy, I want to have a policy that allows s3 Full Access and also ec2 Full Access within the same policy. So if I search for s3, we can see here that we have an AWS Managed policy that provides full access to all buckets for the AWS Management Console.

So, that's what I want, but I also want to add ec2 Full Access as well. So if I select that, and we can see here that this is the policy, the JSON policy for these permissions, we can see the Effect is "Allow", the Action is "s3" and the Resource is "all". So I want to edit this to also include ec2 Full Access.

So I can copy that section there, paste that in, and change the Action here to "ec2". So now what we have IR two elements within the statement one that allows full access to s3 and another allows full access to ec2. Now to verify that I have entered this correctly, there is a "Validate Policy" button down here.

Now always worth clicking on that when you're creating your policies 'cause it'll let you know if there's any errors within the policy document that you need to correct. So if I click on "Validate Policy", we can see here there's an error on line 8, that's expected comma instead of a bracket. So if we go down to line 8 and add our comma in, go down to "Validate Policy" again, we can see that the policy is now valid.

So let's give this policy a name. So we've got "s3", let's say and "ec2FullAccess", click on "Create Policy". And our policy has now been created. Now if we go to filter here on "Policy Type" and select "Customer Managed" we can see here that this has filtered all the Customer Managed policies that I have and the latest one here is the "Amazons3andec2FullAccess".

Now we can have a look at that. Now we can see that is allows two services ec2 and s3, Full Access, to All Resources. And if you want to see the policy document, then we can just view it there and we can also edit the policy again. So let's create that same policy but for a different method. So, if we go "Create Policy", this time use the Policy Generator.

So click on "Select". And this uses a number of dropdown boxes to make it easier if you're not too familiar with JSON and editing policies, etc. So our Effect is "Allow", we can select our service, so first of all we want "AmazonS3". Actions, we want "Full Access", so it's "All Actions", but you can select different ones here if you just want to create or delete buckets, etc.

Or delete objects. But for this demonstration we want "Full Access". And the Amazon Resource Name we want "All Resources", so just put in the asterisks. Click on "Add Statement". Now we want to also allow "ec2" as well, so let's find that. "Amazon EC2" Actions. "All Actions", "All Resources", "Add Statement".

So here you can see the statements that we've added so the Effect is to both allow the action of "s3" and "ec2" and to all resources. We've gone to next step. We can see that the policy have been created for us it's laid out slightly differently but the Effect is still the same. So we can see we have the statement ID, the Effect of "allow", the Action is "s3", with "all resources".

And if we have a look down here, we have another statement ID with Effect of "Allow" and the Action of "ec2" and "all resources". We click on "Validate Policy". Policy is valid. We give the policy a name, "S3andEC2FullAccessFromThePolicyGenerator". Create Policy. And again, if we go down to "Policy Type", "Customer Managed", we can see that we have our policy here.

"Customer Managed", and again full access for EC2 and S3 to All Resources. So let's create the policy for the third time. Exactly the same. But this time creating your own policy. So this will simply open up a blank policy editor document. And here you can write your own policy as you need to or paste it in from another document, which is exactly what I'm going to do.

So all I need to do is paste it into this document here, and as you can see, I have the Action of "s3" for everything Effect "Allow", Resource "Everything", and the same for "ec2". Now if I "Validate Policy" to make sure I've created it correctly, we can see I need a policy name. So let's give this "EC2andS3Custom", "Validate Policy", and we can see the policy is valid.

Go to "Create Policy". And again, one final time, "Customer Managed", and we can see "EC2andS3Custom". And again we can see that services EC2 and S3 has Full Access to All Resources. So that's the three different ways that you can create a Customer Managed Policy. You can select whichever way is easier for you.

If you're not too familiar with writing your own policies then the Policy Generator is probably easiest. Or if you want to use the bulk of an existing AWS Managed Policy to create your own, then the top option is probably best. So each of those policies that we created were all the same. They all gave full access to ec2 and s3, it was just different ways to create them.

That brings us to the end of this demonstration. Thank you.

Now we have covered Managed Policies, I want to go back to Inline Policies. Whereas a Managed Policy could be attached to multiple users, groups, and roles, Inline Policies cannot. An Inline Policy is directly embedded into a specific User, Group, or Role, and as a result, it is not available to be used by multiple identities.

To add an Inline policy for within the AWS Management Console, you must select the User, Group, or Role, select the "Permissions" tab, and click on "Click Here" to add an Inline policy. You will then be given two options in creating your Inline policy: one, using the Policy Generator, or two, writing your own custom policy.

When the policy is being created, it is then associated to your IAM object. As a result, Inline policies do not show up under the Policies list with IAM, as they are not publicly available for other Users, Groups, or Roles to use with your account like Managed Policies are. Inline policies are typically used when you don't want to run the risk of the permissions being used in the policy for any other identity.

When the User, Group, or Role is deleted, Inline policy is also deleted, as this is the only place where the policy exists. With the ability to attach multiple Managed and Inline policies to an identity object in IAM, what happens when there are conflicting permissions assigned to the same User for example?

The rules for reviewing for permissions is very simple and can be summarized as follows: By default, all access to a resource is denied. Access will only be allowed if an explicit "Allow" has been specified within a policy associated with an identity. If a single "Deny" exists within any policy associated to the same identity against the same resource, then that "Deny" will override any previous "Allow" that may exist for the same resource and action.

An explicit "Deny" will always take precedence over an explicit "Allow".

That now brings us to the end of this lecture covering IAM Policies. Coming up next, I am going to give you an overview of Multi Factor Authentication, MFA.