Managing Access with IAM User Groups & Roles
The course is part of these learning paths
This course explores some of the security best practices when using user groups and roles and how these can help you secure access to your resources more effectively. It also includes guided demos from the AWS platform to give you a practical understanding of the topics covered throughout the course.
- Learn how to manage multiple users with IAM User Groups
- Get a foundational understanding of IAM roles
- Understand how to use AWS service roles to access AWS resources on your behalf
- Learn how to use IAM user roles to grant temporary access for users
- Understand how to use roles for federated access
- AWS administrator
- Security engineer
- Security architect
- Anyone who's 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, as well as knowledge of policy types such as managed, customer, and in-line. It would also be advantageous if you had some basic hands-on experience of AWS and some of its core services, but it is not essential.
Hello and welcome to this lecture which will summarize some of the key points mentioned throughout the previous lectures. I started this course looking at User Groups and in this lecture we learnt that: IAM User Groups can be used to manage multiple users. They do not signify a single user and can't be referenced within an IAM policy. They contain IAM Users and have IAM policies associated with them defining their permissions. They are normally created to directly relate to a specific requirement or job role. Applying these permissions to a Group instead of individual users is a security best practice.
To create a Group is very simple and is essentially a 3 step process: Give your Group a meaningful name. Add users to the Group. And then attach permissions via policies. There are limitations on the number of groups per AWS account and for the latest information on this please refer to the following url. I then focused on IAM Roles to understand how they can be used to help manage access. I started by explaining that IAM Roles: Allow trusted Users, AWS services and applications to adopt a set of temporary IAM credentials to access your AWS resources. They are designed to be assumed by multiple different entities as and when required.
Each time a role is assumed a new set of dynamic credentials are created. IAM Roles do not have any long term credentials associated with them. Roles have associated policies controlling access as to what can and can't be accessed when the role is assumed. A Trust Relationship defines who or what can assume the role. IAM Roles are generally used: To grant temporary access for Users in your account or cross-accounts. For AWS Services to carry out specific operations on your behalf. Or for federated uses. I then explained what AWS Service Roles were and what they were used for, and in this section I covered the following points: AWS Service Roles allows AWS services to assume a role to access other AWS resources within your account on your behalf.
Commonly used for EC2 instances. AWS managed and customer managed policies can be attached to Service Roles. Service Roles can be attached to an EC2 instance during its creation or when its running. It's a security best practice to associate a Role to an EC2 instance for accessing AWS resources instead of storing local credentials on the instance itself. There are a number of AWS Services that integrate with IAM that support roles. Service-linked roles perform functions requiring very specific permissions which are often created the first time you use the service.
Service-linked Roles come pre-configured with the relevant AWS Managed policies, trusts and permissions allowing only that Service to carry out the required operations. The difference between AWS Service and AWS Service-Linked Roles is that AWS Service roles allow you to apply your own customer managed or AWS Managed policies, whereas service-linked roles come pre-configured with a specific set of read only AWS managed policies that can only be used by that particular service. Following Service Roles I then looked at IAM User Roles to understand how individual users can adopt a set of temporary credentials.
During this lecture I explained that: When a User assumes a Role it replaces all other permissions that the User has. To assume a role you need to be a trusted entity and have access to assume the Role via a policy. IAM User Roles are often used to create cross-account access, allowing users in one AWS Account to access resources in a different AWS account.
Finally I covered how Roles are used to grant access to federated users which involved both Web Identity federation and SAML 2.0 federation. When discussing Web Identity I explained that: Identity Federation is basically an access method of authentication where two different providers can establish a level of trust allowing users to authenticate from one, which authorizes them to access resources in another. AWS would act as a Service Provider.
A Web Identity Provider would be Google or Facebook, for example. When users authenticate via web identity federation, they will receive an authentication token. The token is then exchanged for temporary security credentials in AWS and mapped to a Role providing access. Amazon Cognito is the preferred method for managing federated access for mobile applications. When I covered SAML Federation I covered the following points: SAML 2.0 is generally used to authenticate your employees using existing directory services that you might already be using, such as MS AD. It minimizes the amount of administration required within IAM allowing for a single sign-on solution.
The Security Token Service allows you to gain temporary security credentials for federated users via IAM, associated with IAM roles and 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 IAM User Groups and how they can be used to simplify access management across multiple users, and how IAM Roles provide short-term temporary credentials to your users and AWS Services.
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 could contact email@example.com. 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.