Hello and welcome to this lecture where I want to talk about four different policy types that you can expect to see when working with AWS IAM. Identity-based policies. These policies can be attached to users, user groups or roles within IAM. Essentially, any entity that depicts an identity. Resource-based policies. Instead of being associated with an identity, these policies are attached in line to resources themselves. An example of a resource-based policy in IAM will be that of a role trust policy where the policy defines the principal that can assume the role.

Permission boundaries. These policies can be associated with a role or user, but they don't actually grant permissions themselves, instead they define the maximum level of permissions that can be granted to an entity. Organization service control policies, SCPs. These are very similar to permission boundaries in the fact that they do not grant permissions. They define a boundary of maximum permissions. However, these service control policies are associated with an AWS account or organizational unit, an OU, when working with AWS organizations and govern the maximum permissions to the members of those accounts.

With all of these policy types, it's easy to see why some people can get confused as to which type of policy is being used or should be used. So let me run through each of these policies in greater detail, starting with the identity-based policies.

As already highlighted, these policies can be attached to users, user groups, or roles and they control what permissions each of those entities have. Identity-based policies can either be managed or inline policies, but what does this mean? Well, managed policies are saved within the IAM library of policies and can be attached to any user, user group or role as and when required, and the same policy can be attached to multiple entities.

Managed policies also come in two different flavors, AWS managed policies and customer managed policies. AWS managed policies are policies that have been pre-configured by AWS and made available to you to help you manage some of the most common permissions that you may wish to assign. Some examples of AWS managed policies can be seen here. From the policy name, you can usually tell what access is being given, although you can expand upon each policy to see the JSON document that is associated.

Customer managed policies are those that you have created yourself, which can then be associated with a user, user group or role. You might want to create customer managed policies when the AWS managed policies do not meet your security requirements. For example, you might want to add additional granularity to the policy to restrict access at a specific API call level.

Let me now explain how inline policies contrast against managed policies. So inline policies are embedded directly into the entity, either the user, user group or role. The policy is not saved and stored in the IAM library policy, its only existence is within the associated entity. As a result, it can't easily be replicated to other entities, it's specific to that one user, user group or role, creating a one-to-one relationship. It's not always best practice to use inline policies as they take a lot of administration to keep on top of and should only be used if absolutely necessary. For example, you might have some elevated permissions that you don't want to have mistakenly given to someone else that they weren't intended for.

Okay, let me now move onto resource-based policies. So resource-based policies are effectively inline policies that are associated with a resource instead of an identity. If you have been using Amazon S3 for any extended period of time, then you may have come across S3 bucket policies, which is a common resource-based policy where permissions to the bucket are defined at the resource level and defined which principal or principals can access the bucket based upon different actions.

When using roles within IAM, the role has a trust relationship policy, which is a resource-based policy. As a result, the permissions of the trust are embedded inline within the role itself. So in this instance, the resource is the role and the resource-based policy is the trust relationship. This example shows the resource-based policy of the trust relationship of one of my roles. In this policy, the user, Stuart is the principal and has the ability to assume the role. It is this parameter of principal which signifies the difference between an identity-based policy and a resource-based policy.

Identity-based policies don't have that principal parameter as the policy is already associated within the identity. Resource-based policies must have the principal parameter to determine which identity that the policy permissions relate to. Next up, we have permission boundaries. So permission boundaries can only be associated with a user or role. It's not possible to add a boundary to a group. They differ from both identity-based and resource-based policies in the fact that permission boundaries don't grant permissions themselves. They act as a guide rail to limit the maximum level of permissions that the user or role can be given. The policy configured for the boundary can be an AWS managed or customer managed policy.

So let's assume for example, that our user, Stuart has an identity-based policy associated with him that allows full access to S3 and full access to EC2 using the following AWS managed policies. However, if a permission boundary was also configured for Stuart using the following AWS managed policies, which only grants read only access to S3, but still full access to EC2, then the resulting access for the user, Stuart would be full access to EC2, but only read only to Amazon S3 as the maximum permission defining by the permissions boundary was limited to read only despite the user having an identity-based policy associated granting full S3 access.

So the last policy I want to reference are the SCPs, the service control policies. So service control policies are used by AWS organizations and attached to AWS accounts or organizational units, OUs, to define the maximum permissions allowed for the members of the associated account or OU. So in a way they act in a similar fashion to that of permission boundaries, but at the account level and affect all members of those accounts.

For example, let's say a user within an AWS account had full access to S3, RDS and EC2 via an identity-based policy. If the SCP associated with that AWS account denied access to the S3 service, then that user would only be able to access RDS and EC2 despite having full access to S3. The SCP would serve to prevent service from being used within the AWS account and so have the overriding precedence and determine the maximum level of permissions allowed.

So to be clear, an SCP does not grant access, they add a guide route to define what is allowed. You'll still need to configure your identity-based or resource-based policies to identities, granting permission to carry out actions within your accounts. If you want to use service control policies to help you manage your security at an account level, then you need to ensure that you deploy AWS organizations using the enable all feature setting.

Within IAM, you have the ability to view any SCPs that are applicable to your AWS account, the policy statement itself, it's ARN, the number of entities it affects and you can also review access activity to learn when a principal within the organization last accessed a service. However, if you wanted to update or edit the SCP, then you'd have to do that from within the AWS organization service itself. The SCP can't be edited from within IAM. For more information relating to how to implement, manage and secure AWS organizations using SCPs, then please see our existing course here.