×

This section provides an overview of the options that are presented when you use the interactive mode to create the OCM role, the user role, and Red Hat OpenShift Service on AWS (ROSA) clusters by using the ROSA CLI (rosa).

Interactive OCM and user role creation mode options

Before you can use Red Hat OpenShift Cluster Manager to create Red Hat OpenShift Service on AWS (ROSA) clusters that use the AWS Security Token Service (STS), you must associate your AWS account with your Red Hat organization by creating and linking the OCM and user roles. You can enable interactive mode by specifying the --interactive option when you run rosa create ocm-role or rosa create user-role.

The following tables describe the interactive OCM role creation mode options:

Table 1. --interactive OCM role creation mode options
Field Description

Role prefix

Specify the prefix to include in the OCM IAM role name. The default is ManagedOpenShift. You can create only one OCM role per AWS account for your Red Hat organization.

Enable admin capabilities for the OCM role (optional)

Enable the admin OCM IAM role, which is equivalent to specifying the --admin argument. The admin role is required if you want to use auto mode to automatically provision the cluster-specific Operator roles and the OIDC provider by using OpenShift Cluster Manager.

Permissions boundary ARN (optional)

Specify a permissions boundary Amazon Resource Name (ARN) for the OCM role. For more information, see Permissions boundaries for IAM entities in the AWS documentation.

Role Path (optional)

Specify a custom ARN path for your OCM role. The path must contain alphanumeric characters only and start and end with /, for example /test/path/dev/. For more information, see ARN path customization for IAM roles and policies.

Role creation mode

Select the role creation mode. You can use auto mode to automatically create the OCM role and link it to your Red Hat organization account. In manual mode, the rosa CLI generates the aws commands needed to create and link the role. In manual mode, the corresponding policy JSON files are also saved to the current directory. manual mode enables you to review the details before running the aws commands manually.

Create the '<ocm_role_name>' role?

Confirm if you want to create the OCM role.

Link the '<ocm_role_arn>' role with organization '<red_hat_organization_id>'?

Confirm if you want to link the OCM role with your Red Hat organization.

The following tables describe the interactive user role creation mode options:

Table 2. --interactive user role creation mode options
Field Description

Role prefix

Specify the prefix to include in the user role name. The default is ManagedOpenShift.

Permissions boundary ARN (optional)

Specify a permissions boundary Amazon Resource Name (ARN) for the user role. For more information, see Permissions boundaries for IAM entities in the AWS documentation.

Role Path (optional)

Specify a custom ARN path for your user role. The path must contain alphanumeric characters only and start and end with /, for example /test/path/dev/. For more information, see ARN path customization for IAM roles and policies.

Role creation mode

Selects the role creation mode. You can use auto mode to automatically create the user role and link it to your OpenShift Cluster Manager user account. In manual mode, the rosa CLI generates the aws commands needed to create and link the role. In manual mode, the corresponding policy JSON files are also saved to the current directory. manual mode enables you to review the details before running the aws commands manually.

Create the '<user_role_name>' role?

Confirm if you want to create the user role.

Link the '<user_role_arn>' role with account '<red_hat_user_account_id>'?

Confirm if you want to link the user role with your Red Hat user account.

Interactive cluster creation mode options

You can create a Red Hat OpenShift Service on AWS cluster with the AWS Security Token Service (STS) by using the interactive mode. You can enable the mode by specifying the --interactive option when you run rosa create cluster.

The following table describes the interactive cluster creation mode options:

Table 3. --interactive cluster creation mode options
Field Description

Cluster name

Enter a name for your cluster, for example my-rosa-cluster.

Deploy cluster using AWS STS

Create an OpenShift cluster that uses the AWS Security Token Service (STS) to allocate temporary, limited-privilege credentials for component-specific AWS Identity and Access Management (IAM) roles. The service enables cluster components to make AWS API calls using secure cloud resource management practices. The default is Yes.

OpenShift version

Select the version of OpenShift to install, for example 4.3.12. The default is the latest version.

Installer role ARN

If you have more than one set of account roles in your AWS account for your cluster version, a list of installer role ARNs are provided. Select the ARN for the installer role that you want to use with your cluster. The cluster uses the account-wide roles and policies that relate to the selected installer role.

External ID (optional)

Specify an unique identifier that is passed by OpenShift Cluster Manager and the OpenShift installer when an account role is assumed. This option is only required for custom account roles that expect an external ID.

Operator roles prefix

Enter a prefix to assign to the cluster-specific Operator IAM roles. The default is the name of the cluster and a 4-digit random string, for example my-rosa-cluster-a0b1.

Multiple availability zones (optional)

Deploy the cluster to multiple availability zones in the AWS region. The default is No, which results in a cluster being deployed to a single availability zone. If you deploy a cluster into multiple availability zones, the AWS region must have at least 3 availability zones. Multiple availability zones are recommended for production workloads.

AWS region

Specify the AWS region to deploy the cluster in. This overrides the AWS_REGION environment variable.

PrivateLink cluster (optional)

Create a cluster using AWS PrivateLink. This option provides private connectivity between Virtual Private Clouds (VPCs), AWS services, and your on-premise networks, without exposing your traffic to the public internet. To provide support, Red Hat Site Reliability Engineering (SRE) can connect to the cluster by using AWS PrivateLink Virtual Private Cloud (VPC) endpoints. This option cannot be changed after a cluster is created. The default is No.

Install into an existing VPC (optional)

Install a cluster into an existing AWS VPC. To use this option, your VPC must have 2 subnets for each availability zone that you are installing the cluster into. The default is No.

Select availability zones (optional)

Specify the availability zones to use when installing into an existing AWS VPC. Use a comma-separated list to provide the availability zones. If you specify No, the installer selects the availability zones automatically.

Enable customer managed key (optional)

Enable this option to use a specific AWS Key Management Service (KMS) key as the encryption key for persistent data. This key functions as the encryption key for control plane, infrastructure, and worker node root volumes. The key is also configured on the default storage class to ensure that persistent volumes created with the default storage class will be encrypted with the specific KMS key. When disabled, the account KMS key for the specified region is used by default to ensure persistent data is always encrypted. The default is No.

Compute nodes instance type

Select a compute node instance type. The default is m5.xlarge.

Enable autoscaling (optional)

Enable compute node autoscaling. The autoscaler adjusts the size of the cluster to meet your deployment demands. The default is No.

Compute nodes

Specify the number of compute nodes to provision into each availability zone. Clusters deployed in a single availability zone require at least 2 nodes. Clusters deployed in multiple zones must have at least 3 nodes. The maximum number of worker nodes is 180 nodes. The default value is 2.

Machine CIDR

Specify the IP address range for machines (cluster nodes), which must encompass all CIDR address ranges for your VPC subnets. Subnets must be contiguous. A minimum IP address range of 128 addresses, using the subnet prefix /25, is supported for single availability zone deployments. A minimum address range of 256 addresses, using the subnet prefix /24, is supported for deployments that use multiple availability zones. The default is 10.0.0.0/16. This range must not conflict with any connected networks.

Service CIDR

Specify the IP address range for services. The range must be large enough to accommodate your workload. The address block must not overlap with any external service accessed from within the cluster. The default is 172.30.0.0/16. It is recommended that they are the same between clusters.

Pod CIDR

Specify the IP address range for pods. The range must be large enough to accommodate your workload. The address block must not overlap with any external service accessed from within the cluster. The default is 10.128.0.0/14. It is recommended that they are the same between clusters.

Host prefix

Specify the subnet prefix length assigned to pods scheduled to individual machines. The host prefix determines the pod IP address pool for each machine. For example, if the host prefix is set to /23, each machine is assigned a /23 subnet from the pod CIDR address range. The default is /23, allowing 512 cluster nodes and 512 pods per node, both of which are beyond our supported maximums. For information on the supported maximums, see the Additional resources section below.

Encrypt etcd data (optional)

In Red Hat OpenShift Service on AWS, the control plane storage is encrypted at rest by default and this includes encryption of the etcd volumes. You can additionally enable the Encrypt etcd data option to encrypt the key values for some resources in etcd, but not the keys.

By enabling etcd encryption for the key values in etcd, you will incur a performance overhead of approximately 20%. The overhead is a result of introducing this second layer of encryption, in addition to the default control plane storage encryption that encrypts the etcd volumes. Red Hat recommends that you enable etcd encryption only if you specifically require it for your use case.

Disable workload monitoring (optional)

Disable monitoring for user-defined projects. Monitoring for user-defined projects is enabled by default.

Additional resources