Getting Started with AWS (Part 12)

By / September 10, 2017

If you would like to read the other parts in this article series please go to:

Introduction

Let’s start off with a quick recap of what we’ve covered up to now in this short series of articles on how to get started with Amazon Web Services (AWS):

  • Part 1 described the free usage tier of Amazon Web Services (AWS) and how you can sign up for it so you can test drive AWS for 12 months.
  • Part 2 examined the various management and development tools provided by Amazon for creating and managing cloud resources on AWS.
  • Part 3 described some steps you can use to secure your AWS account in case your account becomes compromised.
  • Part 4 introduced the AWS Identity and Access Management (IAM), a web service that enables you to create and manage users and assign user permissions for your AWS cloud environment.
  • Part 5 described the features of the IAM Console and how to create a friendly alias for your AWS account ID to make sure you haven’t generated any access keys for your AWS root account.
  • Part 6 demonstrated how you can create a new user that has administrator privileges so you can use this user instead of your root account for managing your AWS environment.
  • Part 7 examined how to implement multi-factor authentication (MFA) for adding an extra layer of protection to your AWS root account and IAM user accounts and discussed the advantages and disadvantages of using MFA for protecting AWS accounts–especially your root account.
  • Part 8 examined how IAM policies can be used to assign permissions for controlling access to AWS resources.
  • Part 9 explained how policy documents are used to define the policies you can use to control access to the resources in your AWS environment.
  • Part 10 demonstrated how to create custom policies for more granular control over the resources in your AWS environment.
  • Part 11 examined some additional ways you can create custom policies for more granular control over the resources in your AWS environment.

So with regard to AWS Identity and Access Management (IAM) we have covered how to create and manage IAM users, groups, and policies. What we haven’t looked at yet is IAM roles, so let’s consider this topic now.

What are roles?

While you can use policies to assign permissions to groups or individual users to grant or deny them access to AWS resources, there are times where this isn’t enough. For example, let’s say you want to allow a user you’ve created in your own AWS environment access to a resource in another AWS environment that is associated with a different AWS account.

A simple scenario where this might be needed would be if your organization has two AWS accounts, one named Development and the other named Production. Users in your Development environment can create and test new applications and services. Then once testing is complete, you want to be able to provision the application or service into the Production environment to make it live there so your business can make use of it.

To accomplish this, you could create a role in the Production environment that grants users or groups who use the role the permissions they need to create, configure and manage the application or service when it is in the Production environment. In effect what you will be doing here is to delegate permissions that are effective in one AWS account so that users in a different AWS account can make use of those permissions when they are needed.

Types of roles

You can create a new role by selecting the Roles page in your IAM console and clicking the Create New Role button as shown in the following figure:

Image
Figure 1: New roles can be created using the Roles page of the IAM console.

The first page of the Create Role wizard always asks you to start by specifying a name for your new role:

Image
Figure 2: You must start by specifying a name for the new role you are creating.

Once you’ve named your new role, you then have three options you can choose from for the type of new role you will create. These three options are:

  • AWS service roles
  • Roles for cross-account access
  • Roles for identity provider access

Let’s examine each of these three role types.

AWS service roles

AWS service roles can be used when you need to delegate permissions to an AWS service like the Amazon Elastic Cloud (EC2) service. Figure 3 below shows how you can use Step 2 of the Create Role wizard to select the AWS service you want to delegate permissions to with your new role:

Image
Figure 3: The different types of AWS service roles you can create using the Create Role wizard in IAM.

After you select the AWS service on this page, the wizard takes you to Step 4 where you can attach up to two IAM policies to your new role.

Roles for cross-account access

The second type of role you can create is one for cross-account access. These are roles that you can use to delegate access for IAM users to specified AWS resources. An example here is the Development/Production scenario described earlier where your organization has two AWS accounts and you want to create a role that will grant users in one account access to resources in the other account. However, as Figure 4 illustrates below, you can also create cross-account access roles that allow users of an AWS account from a different organization–one that you yourself have no authority over–to access resources in your own AWS account:

Image
Figure 4: The different types of roles for cross-account access you can create using the Create Role wizard in IAM

Let’s say for example that you own both AWS accounts. In this case, you will select the “Provide access between AWS accounts you own” option in the figure above. Doing this will take you to Step 3 where you will be asked to enter the 12-digit AWS account ID where the IAM users reside who you will be using the role to grant access to your current AWS environment (the AWS account where you are creating the role). The account ID is needed to establish trust with the other environment. Once trust has been established with the other account, you select up to two policies and finish creating the role.

Roles for identity provider access

The last type of role you can create is one for identity provider access. You create this kind of role when you want to allow users in a non-AWS environment the ability to access resources in your AWS account. The term for this kind of thing is federation. In other words, you create identity provider access roles to establish federation between your AWS account (where your resources reside) and another identity service like Google or Facebook or Amazon Cognito.

AWS supports federation with any identity provider that follows the Open ID standard. However, as the figure below shows, you can also use identity provider access roles to grant access to AWS resources via Web Single Sign-on (WebSSO) or Security Assertion Markup Language (SAML), so there’s lots of flexibility in how you can use roles to integrate AWS into an existing environment that supports any of these identity standards.

Image
Figure 5: The different types of roles for identity provider access you can create using the Create Role wizard in IAM

All that will be required is that in Step 3 you will need to specify the details of the identity provider so the Create Role wizard can establish trust between your AWS account and the other environment where the users who need to access your AWS resources reside.

If you would like to read the other parts in this article series please go to:

Read Next

About The Author

Mitch Tulloch is Senior Editor of both WServerNews and FitITproNews and is a widely recognized expert on Windows Server and cloud technologies. He has written more than a thousand articles and has authored or been series editor for over 50 books for Microsoft Press and other publishers. Mitch has also been a twelve-time recipient of the Microsoft Most Valuable Professional (MVP) award in the technical category of Cloud and Datacenter Management. He currently runs an IT content development business in Winnipeg, Canada.

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top