AWS STS “enables you to request temporary, limited-privilege credentials for AWS Identity and Access Management (IAM) users or for users you authenticate (federated users),” according to the AWS website. In this instance, AWS STS can be used to offer limited, short-term access to resources in your AWS account to the ROSA service. These credentials are no longer recognized by AWS and have no account access from API calls made with them once they expire (about an hour after being requested).
What makes this a safer option?
- The explicit and limited set of roles and policies – the user establishes them in advance and knows exactly which permissions are requested and which roles are being utilized.
- Outside of those permissions, the service is powerless.
- Whenever the service has to conduct an action, it acquires credentials that are only valid for one hour. There is no need to rotate or revoke credentials, and having them expire decreases the chance of them being leaked and reused.
What is ROSA?
Red Hat OpenShift Service on AWS (ROSA) is a fully managed turnkey application platform that allows you to focus on what matters most: creating and distributing value for your customers. The underlying platform is managed by Red Hat and AWS site reliability engineers (SRE), so you don’t have to bother about infrastructure management. The service, like many others, must undertake legitimate actions within your AWS account. As a result, the question of how the service can access such credentials in order to operate in your account arises. This article will concentrate on the newer, explicitly desired, and recommended technique of using AWS Security Token Service (STS) to do this.
What are the numerous ROSA deployment “options” (credential methods)?
Because ROSA manages infrastructure resources in your AWS account, the question is “how do you grant Red Hat the permissions it needs to do the required operations in your AWS account?” That is what “options” refers to. You may have come across references to deploying a ROSA cluster or deploying it “with STS” in the manual and are unsure what the differences are.
As a result, there are two methods for granting those rights that are currently supported:
- Using AdministratorAccess policy with static IAM user credentials – “ROSA with IAM Users” (not recommended)
- “ROSA with STS” – Using AWS Security Token Service (STS) with short-lived, dynamic tokens (recommended).
There was only one technique when ROSA was first released: ROSA with IAM Users. This solution requires an IAM user with the AdministratorAccess policy (restricted to the AWS account using ROSA), which allows the installer to create all of the resources it requires and the cluster to create/expand its own credentials as needed. Since then, we’ve been able to strengthen the service by incorporating security best practices and introducing an AWS STS-based mechanism. The STS technique uses preset roles and policies to grant the service the bare minimum of permissions (least privilege) to establish and manage the cluster. Although both approaches are now available, “ROSA with STS” is the preferred and recommended alternative.
What role does STS play in ROSA?
ROSA leverages STS to grant permissions to particular and segregated IAM roles with short-term security credentials, which are defined as least-privilege policies. These credentials are linked to specific IAM roles for each component and cluster that makes AWS API requests. This is more in line with the notion of least privilege, as well as safe cloud service resource management standards. As part of OpenShift functionality, the ROSA CLI tool controls the STS roles and rules that are assigned for certain activities and takes action on AWS resources. One disadvantage of adopting STS is that each ROSA cluster requires its own set of roles and policies. To make things even easier, the installation tools provide all of the necessary commands and files, as well as the option to have the CLI generate these roles and policies automatically using automated mode. For additional information on the various —mode options, read the ROSA documentation.