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.
An AWS Service Role allows an AWS service to assume a role to access other AWS resources within your own account on your behalf. This is commonly used for EC2 instances, whereby you could create a role for an EC2 instance to assume to gain access to AWS resources on your behalf. Let's look at an example of when you might use this.
Consider the following scenario. You have an EC2 instance running an application that requires access to Amazon S3 to Put and Get objects using the relevant API calls. To allow access to S3, a set of credentials could be stored on the EC2 instance within the application code allowing it to use those credentials to gain access to the relevant S3 Bucket for any Put or Get API requests. However, in this scenario, you would need to manage these credentials manually including the rotation of access keys, which is obviously an administrative burden and open to the possibility of being compromised by a malicious attacker.
To alleviate this issue, the EC2 instance could be assigned an IAM Role, which in turn would have the relevant permissions associated granting the EC2 instance and its application to access S3 to perform the Put and Get API calls using existing AWS managed or customer manager policies. EC2 instances can be assigned a role during its creation, or to a running instance. You can also replace a role that is already associated with an EC2 instance with a new role. From a security best practice perspective you should always associate a Role to an EC2 instance for accessing AWS resources instead of storing local credentials on the instance itself.
There is also another great advantage of using Service Roles. Let's now imagine we have a fleet of EC2 instances all using the same application and performing the same task using the same role, but now consider that your existing application, which was used to perform Put and Get requests is now only required to perform Put requests only, and Get requests must be denied.
To make the change, all you'd to do is to alter the permissions assigned to the IAM Role and all EC2 instances associated with that Role would now have the correct permissions. If this same scenario happened by embedding credentials locally on the EC2 instance, then it would take a long time to replicate the change on every instance accurately.
When creating a Service Role, there's a number of AWS Services that integrate with IAM that support roles. This is a screenshot at the time of writing this course showing the supported AWS services, but for the latest information, you should always check the AWS documentation found here. Before we move on from AWS Service Roles, I want to mention service-linked roles.
A number of different AWS services require roles to perform functions requiring very specific permissions, and in these instances AWS allows you to create service-linked Roles. These are often created the first time that you use a 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 with other AWS resources that it needs to interact with. Some examples of these roles include AWS ServiceRoleForAmazonSSM.
So AWS Systems Manager uses this IAM service role to manage AWS resources on your behalf. AWS ServiceRoleForCloudTrail. So this service linked role is used for supporting the organization trail feature with AWS CloudTrail. And AWS ServiceRoleForCloudWatchEvents. CloudWatch uses this service-linked role to perform Amazon EC2 alarm actions.
So if we look closer at the AWSServiceRoleForAmazonSSM in IAM, we will find that the trusted identity to use this role is ssm.amazonaws.com, AWS Systems Manager. and with it having an AWS Managed policy already configured, we're unable to edit and update this policy. This policy is specifically designed to provide access to AWS Resources managed or used by Amazon SSM, and this role is created when you configure SSM. So 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.
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.