Hello and welcome to this lecture, discussing how authorization is granted when working within your AWS account. Before we start, let me just highlight the difference between authentication and authorization to ensure we are clear on these two security terms which are often interchanged with one another. Authentication is the process of defining an identity and the verification of the identity. For example, a username and password. Authorization determines what identity can access within the system once it's been authenticated. An example of this would be an identities' permissions to access specific AWS resources.

As you may know, the main service responsible for managing and maintaining what an AWS identity is authorized to access is governed by the IAM service, identity and access management. So, let's start with IAM and how these permissions are implemented and associated with different identities, allowing the authorization of using specific services to carry out certain functions. When an identity is authenticated to AWS, the way in which permissions are given to the identity varies depending on the identities own user permissions and its association with other IAM groups and roles.

Let's take a quick recap on users groups and roles. The IAM users are account objects that allow an individual user to access your AWS environment with a set of credentials. You can issue user accounts to anyone who needs to view or administer objects and resources within your AWS environment. Permissions can be applied individually to a user, but the best practice for permission assignments is to add the user to an IAM user group. IAM user groups are objects that have permissions assigned to them via policies, allowing the members of the group to access specific resources.

Having users assigned to these groups allows for a uniformed approach to managing access and control. IAM roles are objects which have policy permissions associated to them. However, instead of just being associated with users as groups are, roles can be associated to EC2 instances or other AWS services as service controls. If associated with an EC2 instance, this allows the instance to adopt permissions given by the role without the need to have access keys stored locally.

Permissions are granted to users, users groups, and roles by means of an AWS IAM policy written as a JSON script. There are a number of privates in AWS policies which are classed as AWS managed policies, but you can also create your own custom-managed policies as well. AWS managed policies cover a huge range of AWS services which authorize you to carry out different tasks through varied levels of access, from read-only to full access and everything in between. If your security requirements fit with one of these AWS managed policies, then that's great and you can start using it right away by associating users, user groups, or roles to it. However, if it's more likely that these AWS-managed policies are not a perfect match for permissions you want to assign to an authenticated user, then in this instance you can copy and tweak the policy and make it fit for your requirements exactly.

When it comes to security, you cannot be lazy as this leads to mistakes and vulnerabilities. You can't afford to take shortcuts and you need to define your permissions ensuring they only allow authorized access to services and features that are required, also known as the principle of least privilege.

IAM policies are made up of statements following a set syntax for allowing or denying permissions to resources within AWS. And each policy will have at least one statement within the structure that resembles the following. So, the statement: This defines the main element of the policy and groups together the permissions defined within it via the following attributes. Effect: This will either be set to Allow or Deny, and these 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 configured as Deny, it would override any previous Allow.

Action: This corresponds to API calls to AWS services. This example represents an API call to delete a bucket, an action within S3. You are able to list multiple actions if required by using a comma to separate them as shown here. Wildcards are also allowed. So, for example, you could create an action to carry out all APIs relating to S3. Resources: This specifies the actual resource you wish the permissions to be applied to. AWS uses unique identifiers known as ARNs, Amazon Resource Names, to specify resources. Typically, ARNs follow the following syntax. Let's break this down and take a look at each of these segments.

Partition: This relates to the partition that the resources 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 where the resource is located. Now remember, some services do not need a region specified. So, this can sometimes be left blank in no circumstances.

Account ID: This is your AWS account ID without hyphens. Again, there are some services that 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:DeleteBucket, then I could use the bucket name that I wanted the permission to delete, and in this example cloudacademy is the name of the bucket.

Condition: This element of the IAM policy is an optional element that allows you to specify when the permissions will be activated based upon set conditions. Conditions use key value pairs and all conditions must be met for the permission to be activated. For example, there may be a condition only permitting requests from a specific source IP address.

Now, we have a basic understanding of how JSON scripts are put together and their general flow, I want to show you how to create and modify AWS IAM policies using a variety of different methods. Okay, so I've logged into my AWS management console and I'm at the IAM dashboard and I've gone into Policies. So, from here, we can create a number of different IAM policies. And the first method I'm going to show you is how to copy and import an existing AWS managed policy to create your own if you need to make a few changes to it. So, let's go ahead and do that now.

So, from here, we need to go across to Create policy. Now from here, we have an option on the top right here called Import managed policy, and that's what we want to do. I want to import an AWS managed policy and then make a couple of small changes to it. So, if I select Import managed policy and then find the policy that I want to find. So, let's for example look at Amazon S3 full access, import that. And we can see here that it's imported the data. And if we look at the JSON tab, we can actually see the JSON format of that policy, and from here we can directly make changes.

So, for this quick demonstration, I want to copy this existing policy, but instead of allowing any resource, I want to specify my own resource for this, which would mean instead of this policy being allowed full access to Amazon S3, it allows full access to a specific bucket on Amazon S3. So, let me go ahead and make those changes now. So, I'm going to change the Asterix from resource and put in my own specific ARN of a bucket. So, now I've changed the resource to my own ARN.

So now, all I need to do is click on 'Next', go to Tags and I can add any optional tags if I want to, I'm just going to leave that blank for this demonstration. Go across to Review, and here I can give this new policy a name. So, I can call S3FullAccessToMyBucket, and description this allows for full S3 access to CA bucket UK. And it gives you a summary of the policy here, so we can see the service that it's using, the access level, and also the resource. Once we're happy with that, we can simply click on 'Create policy'. And we can see that that policy has now been created. Now, if we have a look at that policy just by clicking on it there will take us straight to it and we can see the JSON version of the policy. So, that's a very quick and easy way if you want to save yourself some time by copying existing S3 managed policies that are already there.

Now, I chose a fairly simple policy just for a demonstration, but there are some quite complex policies that AWS already have that you might need to just tweak a few changes to so you can simply import those existing managed policies, make your changes, and then save it as a new customer managed policy. Okay, so that's the first method covered.

Now, next I want to show you how to create a policy using something called the AWS policy generator. Now, if you simply go to Google and type in the AWS policy generator, then it will come up straight away, and you'll be brought to a page like this. Now, the actual URL of this policy generator, if you'd prefer to type it in is awspolicygen.s3.amazonaws.com/policygen.html. So, this is a policy generator and it allows you to easily create different types of AWS policies.

So, if we look at this drop down list here, we can create an SQS queue policy, an S3 bucket policy, which as we know is a resource based policy, a VPC endpoint policy, an IAM policy, and an SNS topic policy. We're interested in the IAM policy. So, if we select that, now in Step 2 we can add our statement. Now here, we have our effect which can be allow or deny. So, let's say allow for this example. And then we can select the service that we're interested in. Let's select Amazon S3 to keep it nice and simple. Now, we can select our actions.

Now, we can select individual actions here just through these tick boxes for any actions that we're interested in. So, I'll just select a number of different ones there. And you can see here, that it's selected five actions. If you wanted all actions, you would simply tick this box and then you'd put in the ARN in the bucket. So, let's just put in that same bucket that we used in the previous example, and then here we can also add in any conditions that we'd like. So, just through a series of dropdown boxes you can specify any conditions that you'd like in there as well. And then once you're happy with your policy, simply select 'Add statement'. And here it breaks down a summary as well. So, it shows the effect, the action, and the actions that we selected, the resource, and if there's any conditions which we didn't specify any.

Now, if you wanted to we can now add an additional statement. So, for example, if we wanted to add some RDS elements in here as well, we can select AWS service, select a load of actions, put in the ARN of your RDS database, and also add that statement to the same policy. Now, once you're happy with your policy and the number of statements that you've added, simply click 'Generate Policy'. And here it shows you the JSON view of the policy that you would need based on your dropdown selection. So, what we can do now is simply copy that, go back to IAM, go to your policies, create policy, go to the JSON tab, and simply paste it in. So, it's a very quick way of creating a policy through a series of dropdown boxes. And again, you can just progress through adding any tags that you need to do, give this a name, ThisIsMyPolicy, and then click 'Create policy'. And again, you can see that this is been created. You can select that, and again we can see that the JSON statement there.

So, now we've looked at how to create a policy by copying an existing AWS managed policy, we've looked at how to use the policy generator. Now, let's just quickly review how to create a policy from scratch. So again, go back to Policies and then Create policy. Now, you can either use this visual editor or go straight to JSON and you can start typing out your policy in here as and how you need it, or you can use the visual editor which is very similar to the policy generator we just looked at, where, again, you can choose a service then the specific actions, say all S3 actions. Then you can specify the resources, whether you want this against an access point, a bucket, a job, an object. So, you can say any object, then you can specify any conditions if you need MFA or specific source IP for example. And again, you can also add additional permissions here.

So, almost like another statement, it's very similar to the policy generator, but for me personally I think the policy generator is slightly easier to understand. And then once you have your settings as you want them, and this has all been prefilled from the options from the visual editor, and again click 'Tags', and then 'Review',  and then give this a name; MyPolicy. And then go to Create policy. If we take a look at the policy, we can just see its details again. And again, this shows the JSON view etc. And if we wanted to edit the policy directly here, then we can click on 'Edit', and you can either edit through the visual editor or you can directly edit the JSON view as well. So, that's just a couple of ways of creating your IAM policies in a few very simple steps. There are many commands that can be applied and controlled through an IAM policy, but they're a bit beyond the scope of this course. However, AWS does provide great API listings for the different services through their extensive documentation for advanced policy writers.