Chapter 3. About IAM resources for STS clusters
To deploy a Red Hat OpenShift Service on AWS classic architecture (ROSA) cluster that uses the AWS Security Token Service (STS), you must create the following AWS Identity Access Management (IAM) resources:
- Specific account-wide IAM roles and policies that provide the STS permissions required for ROSA support, installation, control plane, and compute functionality. This includes account-wide Operator policies.
- Cluster-specific Operator IAM roles that permit the ROSA cluster Operators to carry out core OpenShift functionality.
- An OpenID Connect (OIDC) provider that the cluster Operators use to authenticate.
If you deploy and manage your cluster using OpenShift Cluster Manager, you must create the following additional resources:
- An OpenShift Cluster Manager IAM role to complete the installation on your cluster.
- A user role without any permissions to verify your AWS account identity.
This document provides reference information about the IAM resources that you must deploy when you create a ROSA cluster that uses STS. It also includes the aws CLI commands that are generated when you use manual mode with the rosa create command.
3.1. OpenShift Cluster Manager roles and permissions Copy linkLink copied to clipboard!
If you create ROSA clusters by using OpenShift Cluster Manager, you must have the following AWS IAM roles linked to your AWS account to create and manage the clusters. For more information, see Associating your AWS account.
These AWS IAM roles are as follows:
-
The ROSA user role (
user-role) is an AWS role used by Red Hat to verify the customer’s AWS identity. This role has no additional permissions, and the role has a trust relationship with the Red Hat installer account. An
ocm-roleresource grants the required permissions for installation of ROSA clusters in OpenShift Cluster Manager. You can apply basic or administrative permissions to theocm-roleresource. If you create an administrativeocm-roleresource, OpenShift Cluster Manager can create the needed AWS Operator roles and OpenID Connect (OIDC) provider. This IAM role also creates a trust relationship with the Red Hat installer account as well.NoteThe
ocm-roleIAM resource refers to the combination of the IAM role and the necessary policies created with it.
You must create this user role as well as an administrative ocm-role resource, if you want to use the auto mode in OpenShift Cluster Manager to create your Operator role policies and OIDC provider.
3.1.1. Understanding the OpenShift Cluster Manager role Copy linkLink copied to clipboard!
Creating ROSA clusters in OpenShift Cluster Manager require an ocm-role IAM role. The basic ocm-role IAM role permissions let you to perform cluster maintenance within OpenShift Cluster Manager. To automatically create the operator roles and OpenID Connect (OIDC) provider, you must add the --admin option to the rosa create command. This command creates an ocm-role resource with additional permissions needed for administrative tasks.
This elevated IAM role allows OpenShift Cluster Manager to automatically create the cluster-specific Operator roles and OIDC provider during cluster creation. For more information about this automatic role and policy creation, see the "Methods of account-wide role creation" link in Additional resources.
3.1.1.1. Understanding the user role Copy linkLink copied to clipboard!
In addition to an ocm-role IAM role, you must create a user role so that Red Hat OpenShift Service on AWS classic architecture can verify your AWS identity. This role has no permissions, and it is only used to create a trust relationship between the installer account and your ocm-role resources.
The following tables show the associated basic and administrative permissions for the ocm-role resource.
| Resource | Description |
|---|---|
|
| This permission allows the basic role to retrieve information about the specified OpenID Connect (OIDC) provider. |
|
| This permission allows the basic role to retrieve any information for a specified role. Some of the data returned include the role’s path, GUID, ARN, and the role’s trust policy that grants permission to assume the role. |
|
| This permission allows the basic role to list the roles within a path prefix. |
|
| This permission allows the basic role to list the tags on a specified role. |
|
| This permission allows the basic role to return information about all of the enabled regions on your account. |
|
| This permission allows the basic role to return information about all of your route tables. |
|
| This permission allows the basic role to return information about all of your subnets. |
|
| This permission allows the basic role to return information about all of your virtual private clouds (VPCs). |
|
| This permission allows the basic role to retrieve temporary security credentials to access AWS resources that are beyond its normal permissions. |
|
| This permission allows the basic role to retrieve temporary security credentials for users authenticated their account with a web identity provider. |
| Resource | Description |
|---|---|
|
| This permission allows the admin role to attach a specified policy to the desired IAM role. |
|
| This permission creates a resource that describes an identity provider, which supports OpenID Connect (OIDC). When you create an OIDC provider with this permission, this provider establishes a trust relationship between the provider and AWS. |
|
| This permission allows the admin role to create a role for your AWS account. |
|
| This permission allows the admin role to list any policies associated with your AWS account. |
|
| This permission allows the admin role to list any tags on a designated policy. |
|
| This permission allows the admin role to change the permissions boundary for a user based on a specified policy. |
|
| This permission allows the admin role to add tags to an IAM role. |
3.1.2. Creating an ocm-role IAM role Copy linkLink copied to clipboard!
You create your ocm-role IAM roles by using the command-line interface (CLI).
Prerequisites
- You have an AWS account.
- You have Red Hat Organization Administrator privileges in the OpenShift Cluster Manager organization.
- You have the permissions required to install AWS account-wide roles.
-
You have installed and configured the latest ROSA CLI,
rosa, on your installation host.
Procedure
To create an ocm-role IAM role with basic privileges, run the following command:
rosa create ocm-role
$ rosa create ocm-roleCopy to Clipboard Copied! Toggle word wrap Toggle overflow To create an ocm-role IAM role with admin privileges, run the following command:
rosa create ocm-role --admin
$ rosa create ocm-role --adminCopy to Clipboard Copied! Toggle word wrap Toggle overflow This command allows you to create the role by specifying specific attributes. The following example output shows the "auto mode" selected, which lets the ROSA CLI (
rosa) create your Operator roles and policies. See "Methods of account-wide role creation" for more information.
Example output
- 1
- A prefix value for all of the created AWS resources. In this example,
ManagedOpenShiftprepends all of the AWS resources. - 2
- Choose if you want this role to have the additional admin permissions.Note
You do not see this prompt if you used the
--adminoption. - 3
- The Amazon Resource Name (ARN) of the policy to set permission boundaries.
- 4
- Specify an IAM path for the user name.
- 5
- Choose the method to create your AWS roles. Using
auto, the ROSA CLI generates and links the roles and policies. In theautomode, you receive some different prompts to create the AWS roles. - 6
- The
automethod asks if you want to create a specificocm-roleusing your prefix. - 7
- Confirm that you want to associate your IAM role with your OpenShift Cluster Manager.
- 8
- Links the created role with your AWS organization.
3.2. Account-wide IAM role and policy reference Copy linkLink copied to clipboard!
This section provides details about the account-wide IAM roles and policies that are required for ROSA deployments that use STS, including the Operator policies. It also includes the JSON files that define the policies.
The account-wide roles and policies are specific to an Red Hat OpenShift Service on AWS classic architecture minor release version, for example Red Hat OpenShift Service on AWS classic architecture 4, and are compatible with earlier versions. You can minimize the required STS resources by reusing the account-wide roles and policies for multiple clusters of the same minor version, regardless of their patch version.
3.2.1. Methods of account-wide role creation Copy linkLink copied to clipboard!
You can create account-wide roles by using the Red Hat OpenShift Service on AWS classic architecture (ROSA) CLI, rosa, or the OpenShift Cluster Manager guided installation. You can create the roles manually or by using an automatic process that uses predefined names for these roles and policies.
3.2.1.1. Manual ocm-role resource creation Copy linkLink copied to clipboard!
You can use the manual creation method if you have the necessary CLI access to create these roles on your system. You can run this option in your desired CLI tool or from OpenShift Cluster Manager. After you start the manual creation process, the CLI presents a series of commands for you to run that create the roles and link them to the needed policies.
3.2.1.2. Automatic ocm-role resource creation Copy linkLink copied to clipboard!
If you created an ocm-role resource with administrative permissions, you can use the automatic creation method from OpenShift Cluster Manager. The ROSA CLI does not require that you have this admin ocm-role IAM resource to automatically create these roles and policies. Selecting this method creates the roles and policies that uses the default names.
If you use the ROSA guided installation on OpenShift Cluster Manager, you must have created an ocm-role resource with administrative permissions in the first step of the guided cluster installation. Without this role, you cannot use the automatic Operator role and policy creation option, but you can still create the cluster and its roles and policies with the manual process.
The account number present in the sts_installer_trust_policy.json and sts_support_trust_policy.json samples represents the Red Hat account that is allowed to assume the required roles.
| Resource | Description |
|---|---|
|
| An IAM role used by the ROSA installer. |
|
| An IAM policy that provides the ROSA installer with the permissions required to complete cluster installation tasks. |
Example 3.1. sts_installer_trust_policy.json
Example 3.2. sts_installer_permission_policy.json
| Resource | Description |
|---|---|
|
| An IAM role used by the ROSA control plane. |
|
| An IAM policy that provides the ROSA control plane with the permissions required to manage its components. |
Example 3.3. sts_instance_controlplane_trust_policy.json
Example 3.4. sts_instance_controlplane_permission_policy.json
| Resource | Description |
|---|---|
|
| An IAM role used by the ROSA compute instances. |
|
| An IAM policy that provides the ROSA compute instances with the permissions required to manage their components. |
Example 3.5. sts_instance_worker_trust_policy.json
Example 3.6. sts_instance_worker_permission_policy.json
| Resource | Description |
|---|---|
|
| An IAM role used by the Red Hat Site Reliability Engineering (SRE) support team. |
|
| An IAM policy that provides the Red Hat SRE support team with the permissions required to support ROSA clusters. |
Example 3.7. sts_support_trust_policy.json
Example 3.8. sts_support_permission_policy.json
| Resource | Description |
|---|---|
|
| You use this IAM role to create and maintain ROSA clusters in OpenShift Cluster Manager. |
Example 3.9. sts_ocm_role_trust_policy.json
| Resource | Description |
|---|---|
|
| An IAM role used by Red Hat to verify the customer’s AWS identity. |
Example 3.10. sts_user_role_trust_policy.json
3.2.1.2.1. Example CLI output for policies attached to a role Copy linkLink copied to clipboard!
When a policy is attached to a role, the ROSA CLI displays a confirmation output. The output depends on the type of policy.
If the policy is a trust policy, the ROSA CLI outputs the role name and the content of the policy.
For the target role with policy attached, ROSA CLI outputs the role name and the console URL of the target role.
Target role with policy attached example output
I: Attached trust policy to role 'testrole-Worker-Role(https://console.aws.amazon.com/iam/home?#/roles/testrole-Worker-Role)': ******************
I: Attached trust policy to role 'testrole-Worker-Role(https://console.aws.amazon.com/iam/home?#/roles/testrole-Worker-Role)': ******************Copy to Clipboard Copied! Toggle word wrap Toggle overflow If the attached policy is a trust policy, the ROSA CLI outputs the content of this policy.
Trust policy example output
I: Attached trust policy to role 'test-Support-Role': {"Version": "2012-10-17", "Statement": [{"Action": ["sts:AssumeRole"], "Effect": "Allow", "Principal": {"AWS": ["arn:aws:iam::000000000000:role/RH-Technical-Support-00000000"]}}]}I: Attached trust policy to role 'test-Support-Role': {"Version": "2012-10-17", "Statement": [{"Action": ["sts:AssumeRole"], "Effect": "Allow", "Principal": {"AWS": ["arn:aws:iam::000000000000:role/RH-Technical-Support-00000000"]}}]}Copy to Clipboard Copied! Toggle word wrap Toggle overflow
If the policy is a permission policy, the ROSA CLI outputs the name and public link of this policy or the ARN depending on whether or not the policy is an AWS managed policy or customer-managed policy.
If the attached policy is an AWS managed policy, the ROSA CLI outputs the name and public link of this policy and the role it is attached to.
AWS managed policy example output
I: Attached policy 'ROSASRESupportPolicy(https://docs.aws.amazon.com/aws-managed-policy/latest/reference/ROSASRESupportPolicy)' to role 'test-HCP-ROSA-Support-Role(https://console.aws.amazon.com/iam/home?#/roles/test-HCP-ROSA-Support-Role)'
I: Attached policy 'ROSASRESupportPolicy(https://docs.aws.amazon.com/aws-managed-policy/latest/reference/ROSASRESupportPolicy)' to role 'test-HCP-ROSA-Support-Role(https://console.aws.amazon.com/iam/home?#/roles/test-HCP-ROSA-Support-Role)'Copy to Clipboard Copied! Toggle word wrap Toggle overflow If the attached policy is an AWS managed policy, the ROSA CLI outputs the name and public link of this policy and the role it is attached to.
Customer-managed policy example output
I: Attached policy 'arn:aws:iam::000000000000:policy/testrole-Worker-Role-Policy' to role 'testrole-Worker-Role(https://console.aws.amazon.com/iam/home?#/roles/testrole-Worker-Role)'
I: Attached policy 'arn:aws:iam::000000000000:policy/testrole-Worker-Role-Policy' to role 'testrole-Worker-Role(https://console.aws.amazon.com/iam/home?#/roles/testrole-Worker-Role)'Copy to Clipboard Copied! Toggle word wrap Toggle overflow
| Resource | Description |
|---|---|
|
| An IAM policy that provides the ROSA Ingress Operator with the permissions required to manage external access to a cluster. |
Example 3.11. openshift_ingress_operator_cloud_credentials_policy.json
| Resource | Description |
|---|---|
|
| An IAM policy required by ROSA to manage back-end storage through the Container Storage Interface (CSI). |
Example 3.12. openshift_cluster_csi_drivers_ebs_cloud_credentials_policy.json
| Resource | Description |
|---|---|
|
| An IAM policy that provides the ROSA Machine Config Operator with the permissions required to perform core cluster functionality. |
Example 3.13. openshift_machine_api_aws_cloud_credentials_policy.json
| Resource | Description |
|---|---|
|
| An IAM policy that provides the ROSA Cloud Credential Operator with the permissions required to manage cloud provider credentials. |
Example 3.14. openshift_cloud_credential_operator_cloud_credential_operator_iam_ro_creds_policy.json
| Resource | Description |
|---|---|
|
| An IAM policy that provides the ROSA Image Registry Operator with the permissions required to manage the OpenShift image registry storage in AWS S3 for a cluster. |
Example 3.15. openshift_image_registry_installer_cloud_credentials_policy.json
3.2.2. Account-wide IAM role and policy AWS CLI reference Copy linkLink copied to clipboard!
This section lists the aws CLI commands that the rosa command generates in the terminal. You can run the command in either manual or automatic mode.
3.2.2.1. Using manual mode for account role creation Copy linkLink copied to clipboard!
The manual role creation mode generates the aws commands for you to review and run. The following command starts that process, where <openshift_version> refers to your version of Red Hat OpenShift Service on AWS classic architecture (ROSA), such as 4.
rosa create account-roles --mode manual
$ rosa create account-roles --mode manual
The provided command examples include the ManagedOpenShift prefix. The ManagedOpenShift prefix is the default value, if you do not specify a custom prefix by using the --prefix option.
Command output
3.2.2.2. Using auto mode for role creation Copy linkLink copied to clipboard!
When you add the --mode auto argument, the Red Hat OpenShift Service on AWS classic architecture (ROSA) CLI, rosa, creates your roles and policies. The following command starts that process:
rosa create account-roles --mode auto
$ rosa create account-roles --mode auto
The provided command examples include the ManagedOpenShift prefix. The ManagedOpenShift prefix is the default value, if you do not specify a custom prefix by using the --prefix option.
Command output
3.3. Permission boundaries for the installer role Copy linkLink copied to clipboard!
You can apply a policy as a permissions boundary on an installer role. You can use an AWS-managed policy or a customer-managed policy to set the boundary for an Amazon Web Services (AWS) Identity and Access Management (IAM) entity (user or role). The combination of policy and boundary policy limits the maximum permissions for the user or role. Red Hat OpenShift Service on AWS classic architecture includes a set of three prepared permission boundary policy files, with which you can restrict permissions for the installer role since changing the installer policy itself is not supported.
This feature is only supported on ROSA (classic) clusters.
The permission boundary policy files are as follows:
- The Core boundary policy file contains the minimum permissions needed for ROSA installer to install an Red Hat OpenShift Service on AWS classic architecture cluster. The installer does not have permissions to create a virtual private cloud (VPC) or PrivateLink (PL). A VPC needs to be provided.
- The VPC boundary policy file contains the minimum permissions needed for Red Hat OpenShift Service on AWS classic architecture installer to create/manage the VPC. It does not include permissions for PL or core installation. If you need to install a cluster with enough permissions for the installer to install the cluster and create/manage the VPC, but you do not need to set up PL, then use the core and VPC boundary files together with the installer role.
- The PrivateLink (PL) boundary policy file contains the minimum permissions needed for Red Hat OpenShift Service on AWS classic architecture installer to create the AWS PL with a cluster. It does not include permissions for VPC or core installation. Provide a pre-created VPC for all PL clusters during installation.
When using the permission boundary policy files, the following combinations apply:
- No permission boundary policies means that the full installer policy permissions apply to your cluster.
Core only sets the most restricted permissions for the installer role. The VPC and PL permissions are not included in the Core only boundary policy.
- Installer cannot create or manage the VPC or PL.
- You must have a customer-provided VPC, and PrivateLink (PL) is not available.
Core + VPC sets the core and VPC permissions for the installer role.
- Installer cannot create or manage the PL.
- Assumes you are not using custom/BYO-VPC.
- Assumes the installer will create and manage the VPC.
Core + PrivateLink (PL) means the installer can provision the PL infrastructure.
- You must have a customer-provided VPC.
- This is for a private cluster with PL.
This example procedure is applicable for an installer role and policy with the most restriction of permissions, using only the core installer permission boundary policy for Red Hat OpenShift Service on AWS classic architecture. You can complete this with the AWS console or the AWS CLI. This example uses the AWS CLI and the following policy:
Example 3.16. sts_installer_core_permission_boundary_policy.json
To use the permission boundaries, you will need to prepare the permission boundary policy and add it to your relevant installer role in AWS IAM. While the ROSA (rosa) CLI offers a permission boundary function, it applies to all roles and not just the installer role, which means it does not work with the provided permission boundary policies (which are only for the installer role).
Prerequisites
- You have an AWS account.
- You have the permissions required to administer AWS roles and policies.
-
You have installed and configured the latest AWS (
aws) and ROSA (rosa) CLIs on your workstation. - You have already prepared your ROSA account-wide roles, includes the installer role, and the corresponding policies. If these do not exist in your AWS account, see "Creating the account-wide STS roles and policies" in Additional resources.
Procedure
Prepare the policy file by entering the following command in the
rosaCLI:curl -o ./rosa-installer-core.json https://raw.githubusercontent.com/openshift/managed-cluster-config/master/resources/sts/4.20/sts_installer_core_permission_boundary_policy.json
$ curl -o ./rosa-installer-core.json https://raw.githubusercontent.com/openshift/managed-cluster-config/master/resources/sts/4.20/sts_installer_core_permission_boundary_policy.jsonCopy to Clipboard Copied! Toggle word wrap Toggle overflow Create the policy in AWS and gather its Amazon Resource Name (ARN) by entering the following command:
aws iam create-policy \ --policy-name rosa-core-permissions-boundary-policy \ --policy-document file://./rosa-installer-core.json \ --description "ROSA installer core permission boundary policy, the minimum permission set, allows BYO-VPC, disallows PrivateLink"
$ aws iam create-policy \ --policy-name rosa-core-permissions-boundary-policy \ --policy-document file://./rosa-installer-core.json \ --description "ROSA installer core permission boundary policy, the minimum permission set, allows BYO-VPC, disallows PrivateLink"Copy to Clipboard Copied! Toggle word wrap Toggle overflow Example output
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Add the permission boundary policy to the installer role you want to restrict by entering the following command:
aws iam put-role-permissions-boundary \ --role-name ManagedOpenShift-Installer-Role \ --permissions-boundary arn:aws:iam::<account ID>:policy/rosa-core-permissions-boundary-policy
$ aws iam put-role-permissions-boundary \ --role-name ManagedOpenShift-Installer-Role \ --permissions-boundary arn:aws:iam::<account ID>:policy/rosa-core-permissions-boundary-policyCopy to Clipboard Copied! Toggle word wrap Toggle overflow Display the installer role to validate attached policies (including permissions boundary) by entering the following command in the
rosaCLI:aws iam get-role --role-name ManagedOpenShift-Installer-Role \ --output text | grep PERMISSIONSBOUNDARY
$ aws iam get-role --role-name ManagedOpenShift-Installer-Role \ --output text | grep PERMISSIONSBOUNDARYCopy to Clipboard Copied! Toggle word wrap Toggle overflow Example output
PERMISSIONSBOUNDARY arn:aws:iam::<account ID>:policy/rosa-core-permissions-boundary-policy Policy
PERMISSIONSBOUNDARY arn:aws:iam::<account ID>:policy/rosa-core-permissions-boundary-policy PolicyCopy to Clipboard Copied! Toggle word wrap Toggle overflow For more examples of PL and VPC permission boundary policies see:
Example 3.17.
sts_installer_privatelink_permission_boundary_policy.jsonCopy to Clipboard Copied! Toggle word wrap Toggle overflow Example 3.18.
sts_installer_vpc_permission_boundary_policy.jsonCopy to Clipboard Copied! Toggle word wrap Toggle overflow
3.4. Cluster-specific Operator IAM role reference Copy linkLink copied to clipboard!
Operator roles are used to obtain the temporary permissions required to carry out cluster operations, such as managing back-end storage, cloud ingress controller, and external access to a cluster.
When you create the Operator roles, the account-wide Operator policies for the matching cluster version are attached to the roles. The Operator policies are tagged with the Operator and version they are compatible with. The correct policy for an Operator role is determined by using the tags.
If more than one matching policy is available in your account for an Operator role, an interactive list of options is provided when you create the role.
| Resource | Description |
|---|---|
|
| An IAM role required by ROSA to manage back-end storage through the Container Storage Interface (CSI). |
|
| An IAM role required by the ROSA Machine Config Operator to perform core cluster functionality. |
|
| An IAM role required by the ROSA Cloud Credential Operator to manage cloud provider credentials. |
|
| An IAM role required by the cloud network config controller to manage cloud network configuration for a cluster. |
|
| An IAM role required by the ROSA Image Registry Operator to manage the OpenShift image registry storage in AWS S3 for a cluster. |
|
| An IAM role required by the ROSA Ingress Operator to manage external access to a cluster. |
|
| An IAM role required by the cloud network config controller to manage cloud network credentials for a cluster. |
3.4.1. Operator IAM role AWS CLI reference Copy linkLink copied to clipboard!
This section lists the aws CLI commands that are shown in the terminal when you run the following rosa command using manual mode:
rosa create operator-roles --mode manual --cluster <cluster_name>
$ rosa create operator-roles --mode manual --cluster <cluster_name>
When using manual mode, the aws commands are printed to the terminal for your review. After reviewing the aws commands, you must run them manually. Alternatively, you can specify --mode auto with the rosa create command to run the aws commands immediately.
Command output
The command examples provided in the table include Operator roles that use the ManagedOpenShift prefix. If you defined a custom prefix when you created the account-wide roles and policies, including the Operator policies, you must reference it by using the --prefix <prefix_name> option when you create the Operator roles.
3.4.2. About custom Operator IAM role prefixes Copy linkLink copied to clipboard!
Each Red Hat OpenShift Service on AWS classic architecture (ROSA) cluster that uses the AWS Security Token Service (STS) requires cluster-specific Operator IAM roles.
By default, the Operator role names are prefixed with the cluster name and a random 4-digit hash. For example, the Ingress Cloud Credentials Operator IAM role for a cluster named mycluster has the default name mycluster-<hash>-openshift-ingress-operator-cloud-credentials, where <hash> is a random 4-digit string.
This default naming convention enables you to easily identify the Operator IAM roles for a cluster in your AWS account.
When you create the Operator roles for a cluster, you can optionally specify a custom prefix to use instead of <cluster_name>-<hash>. By using a custom prefix, you can prepend logical identifiers to your Operator role names to meet the requirements of your environment. For example, you might prefix the cluster name and the environment type, such as mycluster-dev. In that example, the Ingress Cloud Credentials Operator role name with the custom prefix is mycluster-dev-openshift-ingress-operator-cloud-credenti.
The role names are truncated to 64 characters.
3.5. Open ID Connect (OIDC) requirements for Operator authentication Copy linkLink copied to clipboard!
For ROSA installations that use STS, you must create a cluster-specific OIDC provider that is used by the cluster Operators to authenticate or create your own OIDC configuration for your own OIDC provider.
3.5.1. Creating an OIDC provider using the CLI Copy linkLink copied to clipboard!
You can create an OIDC provider that is hosted in your AWS account with the Red Hat OpenShift Service on AWS classic architecture (ROSA) CLI, rosa.
Prerequisites
- You have installed the latest version of the ROSA CLI.
Procedure
To create an OIDC provider, by using an unregistered or a registered OIDC configuration.
Unregistered OIDC configurations require you to create the OIDC provider through the cluster. Run the following to create the OIDC provider:
rosa create oidc-provider --mode manual --cluster <cluster_name>
$ rosa create oidc-provider --mode manual --cluster <cluster_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow NoteWhen using
manualmode, theawscommand is printed to the terminal for your review. After reviewing theawscommand, you must run it manually. Alternatively, you can specify--mode autowith therosa createcommand to run theawscommand immediately.Command output
aws iam create-open-id-connect-provider \ --url https://oidc.op1.openshiftapps.com/<oidc_config_id> \ --client-id-list openshift sts.<aws_region>.amazonaws.com \ --thumbprint-list <thumbprint>
aws iam create-open-id-connect-provider \ --url https://oidc.op1.openshiftapps.com/<oidc_config_id> \1 --client-id-list openshift sts.<aws_region>.amazonaws.com \ --thumbprint-list <thumbprint>2 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- The URL used to reach the OpenID Connect (OIDC) identity provider after the cluster is created.
- 2
- The thumbprint is generated automatically when you run the
rosa create oidc-providercommand. For more information about using thumbprints with AWS Identity and Access Management (IAM) OIDC identity providers, see the AWS documentation.
Registered OIDC configurations use an OIDC configuration ID. Run the following command with your OIDC configuration ID:
rosa create oidc-provider --oidc-config-id <oidc_config_id> --mode auto -y
$ rosa create oidc-provider --oidc-config-id <oidc_config_id> --mode auto -yCopy to Clipboard Copied! Toggle word wrap Toggle overflow Command output
I: Creating OIDC provider using 'arn:aws:iam::4540112244:user/userName' I: Created OIDC provider with ARN 'arn:aws:iam::4540112244:oidc-provider/dvbwgdztaeq9o.cloudfront.net/241rh9ql5gpu99d7leokhvkp8icnalpf'
I: Creating OIDC provider using 'arn:aws:iam::4540112244:user/userName' I: Created OIDC provider with ARN 'arn:aws:iam::4540112244:oidc-provider/dvbwgdztaeq9o.cloudfront.net/241rh9ql5gpu99d7leokhvkp8icnalpf'Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.5.2. Creating an OpenID Connect Configuration Copy linkLink copied to clipboard!
When using a cluster hosted by Red Hat, you can create a managed or unmanaged OpenID Connect (OIDC) configuration by using the Red Hat OpenShift Service on AWS classic architecture (ROSA) CLI, rosa. A managed OIDC configuration is stored within Red Hat’s AWS account, while a generated unmanaged OIDC configuration is stored within your AWS account. The OIDC configuration is registered to be used with OpenShift Cluster Manager. When creating an unmanaged OIDC configuration, the CLI provides the private key for you.
3.5.2.1. Creating an OpenID Connect configuration Copy linkLink copied to clipboard!
When creating a Red Hat OpenShift Service on AWS classic architecture cluster, you can create the OpenID Connect (OIDC) configuration before creating your cluster. This configuration is registered to be used with OpenShift Cluster Manager.
Prerequisites
- You have completed the AWS prerequisites for Red Hat OpenShift Service on AWS classic architecture.
-
You have installed and configured the latest ROSA CLI,
rosa, on your installation host.
Procedure
To create your OIDC configuration alongside the AWS resources, run the following command:
rosa create oidc-config --mode=auto --yes
$ rosa create oidc-config --mode=auto --yesCopy to Clipboard Copied! Toggle word wrap Toggle overflow This command returns the following information.
Example output
Copy to Clipboard Copied! Toggle word wrap Toggle overflow When creating your cluster, you must supply the OIDC config ID. The CLI output provides this value for
--mode auto, otherwise you must determine these values based onawsCLI output for--mode manual.Optional: you can save the OIDC configuration ID as a variable to use later. Run the following command to save the variable:
export OIDC_ID=<oidc_config_id>
$ export OIDC_ID=<oidc_config_id>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- In the example output above, the OIDC configuration ID is 13cdr6b.
View the value of the variable by running the following command:
echo $OIDC_ID
$ echo $OIDC_IDCopy to Clipboard Copied! Toggle word wrap Toggle overflow Example output
13cdr6b
13cdr6bCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Verification
You can list the possible OIDC configurations available for your clusters that are associated with your user organization. Run the following command:
rosa list oidc-config
$ rosa list oidc-configCopy to Clipboard Copied! Toggle word wrap Toggle overflow Example output
ID MANAGED ISSUER URL SECRET ARN 2330dbs0n8m3chkkr25gkkcd8pnj3lk2 true https://dvbwgdztaeq9o.cloudfront.net/2330dbs0n8m3chkkr25gkkcd8pnj3lk2 233hvnrjoqu14jltk6lhbhf2tj11f8un false https://oidc-r7u1.s3.us-east-1.amazonaws.com aws:secretsmanager:us-east-1:242819244:secret:rosa-private-key-oidc-r7u1-tM3MDN
ID MANAGED ISSUER URL SECRET ARN 2330dbs0n8m3chkkr25gkkcd8pnj3lk2 true https://dvbwgdztaeq9o.cloudfront.net/2330dbs0n8m3chkkr25gkkcd8pnj3lk2 233hvnrjoqu14jltk6lhbhf2tj11f8un false https://oidc-r7u1.s3.us-east-1.amazonaws.com aws:secretsmanager:us-east-1:242819244:secret:rosa-private-key-oidc-r7u1-tM3MDNCopy to Clipboard Copied! Toggle word wrap Toggle overflow
3.5.2.2. Parameter options for creating your own OpenID Connect configuration Copy linkLink copied to clipboard!
The following options may be added to the rosa create oidc-config command. All of these parameters are optional. Running the rosa create oidc-config command without parameters creates an unmanaged OIDC configuration.
You are required to register the unmanaged OIDC configuration by posting a request to /oidc_configs through OpenShift Cluster Manager. You receive an ID in the response. Use this ID to create a cluster.
3.5.2.2.1. raw-files Copy linkLink copied to clipboard!
Allows you to provide raw files for the private RSA key. This key is named rosa-private-key-oidc-<random_label_of_length_4>.key. You also receive a discovery document, named discovery-document-oidc-<random_label_of_length_4>.json, and a JSON Web Key Set, named jwks-oidc-<random_label_of_length_4>.json.
You use these files to set up the endpoint. This endpoint responds to /.well-known/openid-configuration with the discovery document and on keys.json with the JSON Web Key Set. The private key is stored in Amazon Web Services (AWS) Secrets Manager Service (SMS) as plaintext.
Example
rosa create oidc-config --raw-files
$ rosa create oidc-config --raw-files
3.5.2.2.2. mode Copy linkLink copied to clipboard!
Allows you to specify the mode to create your OIDC configuration. With the manual option, you receive AWS commands that set up the OIDC configuration in an S3 bucket. This option stores the private key in the Secrets Manager. With the manual option, the OIDC Endpoint URL is the URL for the S3 bucket. You must retrieve the Secrets Manager ARN to register the OIDC configuration with OpenShift Cluster Manager.
You receive the same OIDC configuration and AWS resources as the manual mode when using the auto option. A significant difference between the two options is that when using the auto option, ROSA calls AWS, so you do not need to take any further actions. The OIDC Endpoint URL is the URL for the S3 bucket. The CLI retrieves the Secrets Manager ARN, registers the OIDC configuration with OpenShift Cluster Manager, and reports the second rosa command that the user can run to continue with the creation of the STS cluster.
Example
rosa create oidc-config --mode=<auto|manual>
$ rosa create oidc-config --mode=<auto|manual>
3.5.2.2.3. managed Copy linkLink copied to clipboard!
Creates an OIDC configuration that is hosted under Red Hat’s AWS account. This command creates a private key that responds directly with an OIDC Config ID for you to use when creating the STS cluster.
Example
rosa create oidc-config --managed
$ rosa create oidc-config --managed
Example output
3.6. Minimum set of effective permissions for service control policies (SCP) Copy linkLink copied to clipboard!
Service control policies (SCP) are a type of organization policy that manages permissions within your organization. SCPs ensure that accounts within your organization stay within your defined access control guidelines. These policies are maintained in AWS Organizations and control the services that are available within the attached AWS accounts. SCP management is the responsibility of the customer.
When using AWS Security Token Service (STS), you must ensure that the service control policy does not block the following resources:
-
ec2:{} -
iam:{} -
tag:*
Verify that your service control policy (SCP) does not restrict any of these required permissions.
| Service | Actions | Effect | |
|---|---|---|---|
| Required | Amazon EC2 | All | Allow |
| Amazon EC2 Auto Scaling | All | Allow | |
| Amazon S3 | All | Allow | |
| Identity And Access Management | All | Allow | |
| Elastic Load Balancing | All | Allow | |
| Elastic Load Balancing V2 | All | Allow | |
| Amazon CloudWatch | All | Allow | |
| Amazon CloudWatch Events | All | Allow | |
| Amazon CloudWatch Logs | All | Allow | |
| AWS EC2 Instance Connect | SendSerialConsoleSSHPublicKey | Allow | |
| AWS Support | All | Allow | |
| AWS Key Management Service | All | Allow | |
| AWS Security Token Service | All | Allow | |
| AWS Tiro | CreateQuery GetQueryAnswer GetQueryExplanation | Allow | |
| AWS Marketplace | Subscribe Unsubscribe View Subscriptions | Allow | |
| AWS Resource Tagging | All | Allow | |
| AWS Route53 DNS | All | Allow | |
| AWS Service Quotas | ListServices GetRequestedServiceQuotaChange GetServiceQuota RequestServiceQuotaIncrease ListServiceQuotas | Allow | |
| Optional | AWS Billing | ViewAccount Viewbilling ViewUsage | Allow |
| AWS Cost and Usage Report | All | Allow | |
| AWS Cost Explorer Services | All | Allow |
3.7. Customer-managed policies Copy linkLink copied to clipboard!
Red Hat OpenShift Service on AWS classic architecture (ROSA) users are able to attach customer-managed policies to the IAM roles required to run and maintain ROSA clusters. This capability is not uncommon with AWS IAM roles. The ability to attach these policies to ROSA-specific IAM roles extends a ROSA cluster’s permission capabilities; for example, as a way to allow cluster components to access additional AWS resources that are otherwise not part of the ROSA-specific IAM policies.
To ensure that any critical customer applications that rely on customer-managed policies are not modified in any way during cluster or role upgrades, ROSA utilizes the ListAttachedRolesPolicies permission to retrieve the list of permission policies from roles and the ListRolePolicies permission to retrieve the list of policies from ROSA-specific roles. This information ensures that customer-managed policies are not impacted during cluster events, and allows Red Hat SREs to monitor both ROSA and customer-managed policies attached to ROSA-specific IAM roles, enhancing their ability to troubleshoot any cluster issues more effectively.
Attaching permission boundary policies to IAM roles that restrict ROSA-specific policies is not supported, as these policies could interrupt the functionality of the basic permissions necessary to successfully run and maintain your ROSA cluster. There are prepared permissions boundary policies for the ROSA (classic architecture) installer role. See the Additional resources section for more information.