Simplifying Role Based Access to AWS EC2 using Okta Image

Simplifying Role Based Access to AWS EC2 using Okta

Okta has emerged as a leading solution for enterprise identity management. Many of BlueChipTek’s customers use Okta for single sign-on (SSO) functionality across many applications, services and environments. Upon logging into the Okta web portal, a user is presented with a list of configured applications. Among those applications it is possible to define the AWS Management Console for one or more AWS accounts. Enterprises leveraging this functionality from Okta incur a noticeable amount of administrative overhead for each account integration (see the currently available instructions located here).


It is common practice to create a separate AWS account for each department, project, developer, or environment. Each of these individual AWS accounts must be integrated and managed as a separate application within Okta. Furthermore, a single user or groups of users may require multiple levels of permissions while accessing each AWS Management Console. With the rapid pace of growth and change found in online business the task of provisioning the accounts, access policies and necessary integrations between AWS and Okta can easily consume a significant amount of IT resources.


BlueChipTek worked with a client recently to address this exact problem. Leveraging the available APIs and industry best practices, BlueChipTek created an automation toolset that vastly reduced the amount of time and effort needed to provision the integrations for each AWS account within the Okta platform. The resulting configuration presents a list of available IAM Roles to each user as they login to the AWS Management Console.




1.      An existing AWS account (see here).

2.      An IAM user with API access credentials (see here).

3.      AWS CLI tools installed and configured on the host where the toolset will run (see here).

4.      An Okta account (Developer accounts are available for free, see here).

5.      An Okta API token (see here).


With all of our prerequisites in place, we begin with a terminal shell (BASH on OS X in my case). Using the ‘aws configure’ CLI, I have configured a profile called ‘gmail’ with the specifics of the IAM user (from prerequisite #2) for the AWS account (from prerequisite #1) that we will configure with Okta for SSO.

I can now set an environment variable with this profile.

Next, I execute the Python script that Blue Chip Tek developed. There are a few required parameters that must be passed to the script. They are:


·         app-name: The name of the application as it will appear in the Okta we portal. This should be descriptive enough for users to easily identify it among other applications that may be configured in your Okta implementation. Organizations that have multiple AWS accounts that will be defined as Okta applications should define and implement a naming scheme for consistency before moving forward.

·         okta-token: The Okta API token that was created for the Okta user that has been granted permission to interact with the API (prerequisite #5)

·         okta-api-host: The hostname for accessing your organization’s Okta account.


For this example, I have chosen to name the Okta application for this AWS Management Console integration, Gmail-AWS-Account. I created a separate developer Okta account for purposes of this example as well.

The script has taken care of a number of tasks for me automatically. First, it has created a new IAM user in my AWS account. This new user is allowed to list and assume the various IAM Roles that will be presented to Okta users.

Next, it creates the new application in my Okta account.

Next, it creates a SAML Identity Provider within my AWS account. This is the integration point that Okta will use to exchange authentication information with the AWS account.

At this point, it is important to digest the information that was output following the execution of the script. The script outputs a set of instructions that must now be executed before the integration is complete. The first task is to define the various IAM Roles within the AWS account that Okta users will be allowed to assume. For this example, we are defining three roles: Administrator, PowerUsers, and ReadOnlyAccess. To create these IAM Roles and their associated permission policies, we will leverage the AWS CloudFormation service. We have created a CloudFormation template file using the YAML standard (see attached file for reference). The template requires the AWS Identity Provider ARN as a parameter. The AWS Identity Provider ARN is included in the output from the script.

Once the new CloudFormation stack creation has completed, you will see the three new IAM Roles defined in the AWS account.

At this point we need to shift focus to the Okta administration portal. The newly created Okta Application must have the Provisioning feature enabled. Unfortunately, there is no API available at this time to complete this task. Therefore, it must be done manually. Login to the Okta administration portal and navigate to the Provisioning tab of the Application configuration. Click on the “Enable Provisioning” button.

Next, we need to provide the AWS API credentials for the Okta SSO IAM account that the script created. Copy and paste the Access Key and Secret Key that was provided in the script output into the API Credentials section of the Okta Application Provisioning configuration.

Next, the “Enable Create Users” checkbox must be selected.

Finally, save the updated configuration parameters by clicking on the “Save” button at the bottom right corner of the window.


You will now be able to assign the available AWS IAM Roles to your Okta user groups. In this example, we have defined Okta user groups with similar names to the IAM Roles that have been created in the AWS account. Each Okta group is mapped to the appropriate IAM Role in the Okta Application configuration Groups tab.

To test our new configuration, we assign the Gmail-AWS-Account application in Okta to a test user (or group of users). When the test user logs into the Okta portal, they are presented with the new AWS Management Console application tile.

Selecting the Gmail-AWS-Account application tile launches a new web browser window and connects to the AWS Identity Provider URL for that integrated AWS account. My test user is a member of multiple groups; therefore, I am presented with a select of the IAM Role that I would like to assume for accessing the AWS Management Console.

Using the tooling described here greatly reduces the amount of time needed to define new Okta integrations with the AWS Management Console. For organizations that are tasked with managing many AWS accounts, having the ability to automate many of the tasks involved in defining the Okta integrations greatly reduces the time and effort needed. Dozens of AWS accounts can be integrated with Okta in under an hour using the BlueChipTek toolset.