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.
IAM Roles allow trusted Users, AWS services and applications to adopt a set of temporary IAM credentials to access your AWS resources. Roles act as identities, much like Users do, and have permissions assigned to them defining what resources the Roles can and can't access. Unlike Users though, which represent a single identity, IAM Roles are designed to be assumed by multiple different entities as and when required. Like I say, Roles are used for temporary access to gain access to resources, and each time the role is assumed by a User, an AWS service or an application, a new set of credentials is dynamically created for the duration of that session. As a result, Roles do not have any long term credentials associated, so there is no password for console access, nor are there any access keys for programmatic access that are explicitly associated with the Role.
For every role there will be associated policies controlling access as to what can and can't be accessed when the role is assumed. There will also be a Trust Relationship, and this Trust Relationship defined who or what can assume the role, for example a User, an AWS account, or an AWS Service. IAM Roles are generally used: if you need to grant temporary access for Users to AWS resources that they don't normally require access to or you can use a Role to grant access for an IAM user in one account to access resources in another AWS account or perhaps an AWS service needs to access resources on your behalf or if an application requires access to resources you can use a Role instead of embedding credentials into the software itself. Or you might have federated users who require access to specific resources, perhaps those authenticated via Active Directory So, as a result, Roles can be assumed by the following: A user that's in the same AWS account as the where the role has been created, a user that's in a different AWS account than where the the role has been created, an AWS service, such as EC2, or an external federated users to your AWS account
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.