Define and Manage Permissions with AWS IAM
This course covers how IAM Policies can be used to allow you to grant and restrict access to your resources within your AWS account, as well as the different types of policies and how to interpret a policy.
- Understanding the different types of IAM policies you can expect to see when working within IAM
- Learn how to implement policies effectively to build secure and robust access controls for your users
- Learn how to read IAM policies to understand the permissions they are granting and restricting
- Learn how policy evaluation logic operates
- AWS administrators
- Security engineers
- Security architects
- Anyone who is looking to increase their knowledge of the IAM service in preparation for an AWS certification
To get the most out of this course, you should already have a basic understanding of AWS IAM and what the service is used for. It would also be advantageous if you had some basic hands-on experience of AWS and some of its core services, but this is not essential.
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 principle 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 principle or principles 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 principle and has the ability to assume the role. It is this parameter of principle which signifies the difference between an identity-based policy and a resource-based policy.
Identity-based policies don't have that principle parameter as the policy is already associated within the identity. Resource-based policies must have the principle 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.
Stuart has been working within the IT industry for two decades covering a huge range of topic areas and technologies, from data center and network infrastructure design, to cloud architecture and implementation.
To date, Stuart has created 150+ courses relating to Cloud reaching over 180,000 students, mostly within the AWS category and with a heavy focus on security and compliance.
Stuart is a member of the AWS Community Builders Program for his contributions towards AWS.
He is AWS certified and accredited in addition to being a published author covering topics across the AWS landscape.
In January 2016 Stuart was awarded ‘Expert of the Year Award 2015’ from Experts Exchange for his knowledge share within cloud services to the community.
Stuart enjoys writing about cloud technologies and you will find many of his articles within our blog pages.