This article is a summary of a presentation I recently gave looking at Okta Workforce Identity Cloud and Amazon Web Services (AWS). It is focused on how privileged access management can be applied to AWS users and access, leveraging the different Identity and Access Management (IAM) capabilities in Okta.
Introduction
Privileged Access Management (PAM) as an IAM domain has been around for a long time. The original premise was that privileged access could be separated from regular access, almost a binary user vs. super-admin delineation. Modern app access is far more nuanced that that – there may be shared accounts with privileged access to be managed, but there is also the need to prioritise granting individual access with the right level of privileges delivered in a Just-in-time (JIT) approach to drive towards a Zero Standing Privileges model.
Amazon Web Services (AWS) is a good example of the complexity of privileged access management. It can involve Account root users, shared users, local users and federated users. Other than the root user (which is effectively the super user), these may have varying levels of access based on the roles/ permission sets they are assigned or can assume. This means privileged access management for AWS will cover the major domains of IAM: controlling which entitlements a user can assume in Access Management, controlling which entitlements a user is allowed to assume in Identity Governance and Administration (IGA) and PAM-specific controls for AWS.
This article explores these different aspect for AWS privileged access and how Okta addresses them. It’s focussed on user-based access via SSO and doesn’t touch on service-based access.
It is worthwhile reading this article on a background to AWS users and policies.
Access Management and AWS Privileges
Most AWS users will be federated users or local AWS IAM Identity Centre users. When you SSO into AWS, those users assume entitlements (Roles for federated users and Permission Sets in Accounts for local users). These entitlements could include privileged access, where the Roles/Permission Sets are mapped to privileged permissions in AWS.
Okta has the Okta Integration Network (OIN) which provides multiple integrations for AWS. Of interest to this article are the AWS Account Federation integration and the AWS IAM Identity Centre integration.
The AWS Account Federation integration is for use where AWS Identity and Access Management is used to manage federated access and is tied to a specific AWS Account. With federated users and AWS IAM, there are no local accounts in AWS. When a user clicks on a tile for AWS Account Federation in the Okta Dashboard, they are presented with a list of AWS Roles they can assume and they connect as that Role into AWS.
The AWS IAM Identity Centre integration is used where AWS IAM Identity Centre is used across one or more AWS Accounts. Local users are defined in AWS IAM Identity Centre, and they are mapped (either directly or via groups) to Permission Sets that allow access in AWS. When a user clicks on a tile for AWS IAM Identity Centre in the Okta Dashboard, they select an AWS Account and then the Permission Set for that account, and are given access in AWS as that local user with that Permission Set.
These two integrations and the flows are shown in the following figure.
Thus SSO’ing into AWS via one of these integrations may involve assuming some privileged access via Roles or Permission Sets. But how do we map the users to these entitlements?
Identity Administration, Governance and AWS Access
In the previous section I showed how the different OIN integrations can let users SSO into AWS and assume privileged entitlements. In this section we look at the identity management and governance aspects.
Managing AWS IAM Role Assignment
When defining an applicaiton in Okta leveraging the AWS Account Federation integration, the application profile will be populated with a list of Roles for the corresponding AWS Account. These Roles are available to be assigned in the app user profile.
As with any application user profiles in Okta, attributes (such as Role) can be assigned directly or via groups. It makes sense to setup different groups to assign logical sets of assignments and have the group assignment define the Roles a user gets.
Thus to assign users to AWS Roles, you assign them to the relevant groups in Okta.
Note that the AWS Account Federation integration does not provision users to AWS (as they are federated users that don’t exist in AWS IAM) but will pull in the list of roles and also manage the mechanism where users select the role to assume on SSO.
Managing AWS IAM Identity Centre Permission Set Assignment
The AWS IAM Identity Centre integration acts differently – the AWS Permission Sets are not imported into the Okta app profile and available in app assignment, so you cannot use the group assignment approach to manage the entitlement mapping.
For applications using AWS IAM Identity Centre, you need to define Push Groups for the application and then map these groups in IAM Identity Centre to Permissions Sets. This is shown below.
Thus to assign users to AWS Permission Sets, you assign them to the relevant group in Okta that is then pushed to AWS IAM Identity Centre.
Note that the AWS IAM Identity Centre integration provisions users from Okta to AWS IAM Identity Centre. Users must be in AWS IAM Identity Center and be assigned to the relevant AWS Groups (pushed from Okta) for them to be able to SSO, so any users in the push groups for the app must also be assigned to the app.
Using Group Management to Control Assignment
Common to two approaches above is using membership of groups in Okta – whether it is groups assigned to an AWS Account Federation app assigning Roles or groups pushed to AWS IAM Identity Centre mapped to Permission Sets.
The following figure shows an example of different groups in Okta mapped into AWS IAM Identity Centre and how they are managed in Okta.
In the example, there are three groups pushed to AWS and assigned to different Permissions Sets. One of these groups (Network Admin Group) is managed through a group rule. The other two groups can be requested via Access Requests.
The following sections will look at the different patterns: use of group rules for automatic assignment; use of access requests for dynamic assignment; and the user of access certification to revalidate the need for access.
More information on this pattern with Okta Groups and AWS IAM Identity Centre can be found at https://aws.amazon.com/blogs/apn/just-in-time-least-privileged-access-to-aws-administrative-roles-with-okta-and-aws-identity-center/.
Automatic Assignment to Entitlements via Group Rules
Automated end-to-end user lifecycle often involves automatic assignment to entitlements based on some attributes coming from HR, such as department, jobcode or location. This is sometimes called role-based or attribute-based assignment. Within Okta, this is achieved through Group Rules tied to attributes on user profiles. When user profiles change, such as in response to a user change coming from a HR system, the group rules are re-evaluated to determine what groups the user should belong to and any application assignment changes that triggers.
The followign figure shows a group rule for automatic assignment to the AWS-NA-Prod-NetworkAdmin group based on the user department being “Network”.
If the user was moved out of the Network department they would automatically be removed from the group and lose the associated AWS entitlement.
Requesting Access to AWS Entitlements via Access Requests
The Access Requests function in Okta Identity Governance (OIG) can be used to allow users to request AWS privileged access via a group, with for a flow to drive approvals (e.g. manager or service owner).
For example, I’ve setup two Request Types (flows) in OIG, one to grant short-term (2 hour) access to Permission Sets/Roles via one of the Okta groups, and another for a longer-term access (until a specified date). Note that the “Role Required” is a list of the three groups shown in the previous section that are mapped to Permission Sets.
As these groups represent privileged access, you can apply mitigating controls, such as limiting access to a short time and/or having multiple levels of approval (e.g. manager AND service owner). The first flow above will automatically remove group membership (thus assignment to the Permission Set) after two hours. The second one will automatically remove it on the chosen date.
Reviewing Access to AWS Entitlements via Access Certification
We can also use the Okta Identity Governance (OIG) Access Certifications mechanism to review who has access to the groups granting access to the Permission Sets (or Roles in AWS IAM).
The following figure shows the Access Certification manager view for their employees and the access they have into AWS Permission Sets via Okta groups.
The reviewer, in this case the user manager but it could be a service owner or another role, reviews the access and can remove it be revoking access.
Access Certifications for privileged access is a good complementary control to how access is assigned – if there are holes in the access assignment process, regular access reviews can minimise the risk of inappropriate privileged access.
A Note on Okta Workflows and AWS
It is worth noting that Okta Workflows has a number of AWS Connectors, including the AWS Multi-Account Access connector and the AWS Lambda connector. Both of these can be used to manage the entitlements within AWS. The former provides actions to List, Add and Remove entitlements. The latter is used to execute Lambda functions, and it’s a common pattenr to embed API calls into these Lambda functions and call them from workflows.
Both could be used to manage AWS entitlements such as assigning users to permission sets in accounts.
Privileged Access Management Capabilities for AWS
The previous sections have looked at controlling access to AWS privileged entitlements through groups and different mechanisms in Okta such as the OIN integrations and Okta Identity Governance. But what about Okta Privileged Access, the new Privileged Access Management product? It can help with the following:
- Controlling access to servers hosted on AWS EC2
- Storing the AWS Account root user password in the Secrets Vault, and
- Providing visibility into the entitlement topology and risks with Cloud Infrastructure Entitlement Management
The first is a fairly standard use case that applies to any servers irrespective of whether they are on-prem physical/virtual servers or cloud-hosted servers. Okta Privileged Access can manage ssh/rdp connections to Linux and Windows servers and through policy control who can access them and how (such as requiring MFA or manager approval).
Storing the AWS Account Root User Password in the Secrets Vault
The AWS Account Root User in AWS is a special user. It is the super admin used to setup and manage the AWS Account. As it is such a powerful account, it’s credentials must be controlled appropriately. It should be a break-glass account, with other individual accounts given the administrative rights as needed. See https://docs.aws.amazon.com/IAM/latest/UserGuide/root-user-best-practices.html for more recommendations on the root user.
But like any shared account, there may be times where it is needed, and potentially needed by different people. It makes sense to store this account in a vault, like the Secrets Vault in Okta Privileged Access. Storing the password in the vault means controls, such as MFA and access approval, can be applied to accessing the password.
For example, you could set up a secret folder structure in Okta Privileged Access for the root user credentials for your different AWS accounts (perhaps different for development, testing and production), define the access policy for each, and store the root user creds in the appropriate folder. When an admin goes to access the password they drill down to the relevant folder and open the secret.
In this example, there is a policy applied to that secret requiring the users manager to approve the request to reveal the password. Attempting to reveal the credentials triggers an approval request sent to the manager.
Once approved, the user can reveal the credentials and copy them out to use when logging into AWS.
Note that there is no API to manage the password of the Account root user – password management must be performed in the UI. Thus the passwords must be manually managed in the vault. When changed in AWS, they must be updated in the vault to reflect the new value.
All access to these secrets is recorded in the Okta System Log, as shown below.
They could be reported on there, plumbed to a SIEM for analysis and reporting, or have bespoke automation run through Okta Workflows.
Cloud Infrastructure Entitlement Management for AWS
The last privileged access mechanism for AWS to mention is the new Cloud Infrastructure Entitlement Management (CIEM) capability. It provides a mechanism to go and discover AWS entitlements, build a topology view of who has access to what and how, and perform some risk heuristics to determine over-permissioning.
Within Okta Privileged Access you define connections to AWS accounts then schedule jobs to gather and analyse entitlements. This produces a topology view of resources, permissions, groups and users with risk.
This CIEM capability is currently in preview and focussed on the RDS service in AWS. In time it will develop to cover more services and a broader set of risk rules.
This capability provides another means to understand privileged access in an AWS Account.
Summary
In this article I have explored the different ways that Okta can support privileged access management for AWS users and entitlements across the domains of Access Management, Identity Governance and Administration (IGA) and PAM.
The following figure shows the components and integration points discussed.
They are:
- The two OIN integrations (AWS Account Federation and AWS IAM Identity Centre) allow users to single signon to AWS and assume an entitlement within AWS, which could be a privileged entitlement
- When using the AWS Account Federation integration, AWS Roles are imported and can be assigned to individuals or groups in Okta. When group membership changes in Okta, the Roles a user can select on SSO changes.
- When usingthe AWS IAM Identity Centre integration, users and groups are provisioned to AWS IAM IC and then the groups are mapped to Permission Sets in Accounts. When group membership changes in Okta, this is reflected in the permission set assignment in AWS.
- Okta Workflows may also be used for AWS entitlement management
- Using group to manage AWS Roles / Permission Set assignment means that Okta Identity Governance (IGA) controls like automated lifecycle, access request and access certification can be applied.
- The Okta Privileged Access CIEM capability can consume entitlement relationships and present the topology and risk of those entitlements.
- Access to servers running in AWS EC2 can be managed with controls like MFA and access approval.
- AWS secrets, such as the AWS Account root user, can be stored in the Okta Privileged Access Vault with policy-based controls wrapped around to restrict who can access them and how.
This is a wide-reaching set of capabilities to manage privileged access in AWS. Not all of them will be relevant to every AWS environment, but effective use can reduce the risk of improper access and use of privileges in AWS.
