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.
Welcome to the final lecture of this course where I shall summarize the key points taken from the previous lectures. I began by looking at the different IAM policy types, and here I covered the following. And I started with Identity-based policies. These policies can be attached to Users, User Groups or Roles. They can be managed or inline policies. The managed policies can be AWS managed or customer managed. AWS managed policies are pre-configured by AWS and customer managed policies are created by us as customers. And inline policies are embedded directly into the entity, either the User, User Group or Role, creating a 1-2-1 relationship.
Then we have Resource-based policies. And these are policies associated with a resource instead of an identity. So, S3 bucket policies are a common resource-based policy. Trust relationship policies are also a resource-based policy and resource-based policies must have the 'Principal' parameter to determine which identity that the policy relates to. Permission boundaries. Permission boundaries can only be associated with a User or Role. They do not grant permissions, they act as a guardrail to limit the maximum level of permissions that the User or Role can be given. And the policy can be an AWS managed or customer managed policy. And then we have Organization Service Control Policies, SCPs. And these 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. And they operate at the account level. SCPs do not grant access, they add a guardrail to define what is allowed. And don't forget, you still need to configure your identity-based policies or resource-based policies.
To use SCPs you need to ensure that you deploy AWS Organizations using the enable all features setting. Next I looked at the JSON policy structure and broke down the different parameters of the policy which included the following. Version, this specifies the policy language version. Statement, this defines that main element of the policy. The Sid, the Statement ID, and this is an optional parameter that allows you to set a unique identifier within the Statement. Effect, this element can be set to either Allow or Deny.
The Principal, this parameter defines which principal the policy relates to. And the Principal is only used for resource-based policies. Action, this is the action that will either be allowed or denied. Resource, this element specifies the actual resource you wish the Action and Effect to be applied to. Condition, and this is an optional element that allows you to control when the permissions will be effective based upon set criteria. I then gave a demonstration showing you how to create different IAM policies using a variety of different methods. Then finally I broke down the process of how IAM evaluates permissions when multiple different types of policies are involved. And in this lecture we learnt that when a request to access a resource is triggered, AWS will ensure that the identity is authenticated, it will then determine the context of the request, at which point policy evaluation will take place before determining if the request is allowed or denied.
By default all access is to a resource is denied. Access will only be allowed if an Allow has been specified within a policy associated with the principal, and a Deny will overrule any previous Allow. IAM Policy types are evaluated in the following order. Organizational Service Control Policies, Resource-based Policies, IAM Permission Boundaries, and then finally, Identity-based Policies. That now brings me to the end of this lecture and to the end of this course, and so you should now have a greater understanding of how you can use IAM Policies to define and manage permissions across your account.
Feedback on our courses here at Cloud Academy is valuable to both us as trainers and any students looking to take the same course in the future. If you have any feedback, positive or negative, it would be greatly appreciated if you can contact firstname.lastname@example.org. Thank you for your time and good luck with your continued learning of cloud computing. Thank you.
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.