$ rosa list ocm-role
Red Hat OpenShift Service on AWS (ROSA) provides a model that allows Red Hat to deploy clusters into a customer’s existing Amazon Web Service (AWS) account.
AWS Security Token Service (STS) is the recommended credential mode for installing and interacting with clusters on Red Hat OpenShift Service on AWS because it provides enhanced security. |
Ensure that the following prerequisites are met before installing your cluster.
The following prerequisites must be complete before you deploy a Red Hat OpenShift Service on AWS (ROSA) cluster that uses the AWS Security Token Service (STS).
Your AWS account must allow sufficient quota to deploy your cluster.
If your organization applies and enforces SCP policies, these policies must not be more restrictive than the roles and policies required by the cluster.
You can deploy native AWS services within the same AWS account.
Your account must have a service-linked role to allow the installation program to configure Elastic Load Balancing (ELB). See "Creating the Elastic Load Balancing (ELB) service-linked role" for more information.
Red Hat recommends that the customer have at least Business Support from AWS.
Red Hat may have permission from the customer to request AWS support on their behalf.
Red Hat may have permission from the customer to request AWS resource limit increases on the customer’s account.
Red Hat manages the restrictions, limitations, expectations, and defaults for all Red Hat OpenShift Service on AWS clusters in the same manner, unless otherwise specified in this requirements section.
The following configuration details are required only if you use OpenShift Cluster Manager to manage your clusters. If you use the CLI tools exclusively, then you can disregard these requirements.
When you provision Red Hat OpenShift Service on AWS (ROSA) using OpenShift Cluster Manager, you must associate the ocm-role
and user-role
IAM roles with your AWS account using your Amazon Resource Name (ARN). This association process is also known as account linking.
The ocm-role
ARN is stored as a label in your Red Hat organization while the user-role
ARN is stored as a label inside your Red Hat user account. Red Hat uses these ARN labels to confirm that the user is a valid account holder and that the correct permissions are available to perform provisioning tasks in the AWS account.
You can associate or link your AWS account with existing IAM roles by using the Red Hat OpenShift Service on AWS (ROSA) CLI, rosa
.
You have an AWS account.
You have the permissions required to install AWS account-wide roles. See the "Additional resources" of this section for more information.
You have installed and configured the latest AWS (aws
) and ROSA (rosa
) CLIs on your installation host.
You have created the ocm-role
and user-role
IAM roles, but have not yet linked them to your AWS account. You can check whether your IAM roles are already linked by running the following commands:
$ rosa list ocm-role
$ rosa list user-role
If Yes
is displayed in the Linked
column for both roles, you have already linked the roles to an AWS account.
From the CLI, link your ocm-role
resource to your Red Hat organization by using your Amazon Resource Name (ARN):
You must have Red Hat Organization Administrator privileges to run the |
$ rosa link ocm-role --role-arn <arn>
I: Linking OCM role
? Link the '<AWS ACCOUNT ID>` role with organization '<ORG ID>'? Yes
I: Successfully linked role-arn '<AWS ACCOUNT ID>' with organization account '<ORG ID>'
From the CLI, link your user-role
resource to your Red Hat user account by using your Amazon Resource Name (ARN):
$ rosa link user-role --role-arn <arn>
I: Linking User role
? Link the 'arn:aws:iam::<ARN>:role/ManagedOpenShift-User-Role-125' role with organization '<AWS ID>'? Yes
I: Successfully linked role-arn 'arn:aws:iam::<ARN>:role/ManagedOpenShift-User-Role-125' with organization account '<AWS ID>'
See Account-wide IAM role and policy reference for a list of IAM roles needed for cluster creation.
You can associate multiple AWS accounts with your Red Hat organization. Associating multiple accounts lets you create Red Hat OpenShift Service on AWS (ROSA) clusters on any of the associated AWS accounts from your Red Hat organization.
With this feature, you can create clusters in different AWS regions by using multiple AWS profiles as region-bound environments.
You have an AWS account.
You are using OpenShift Cluster Manager to create clusters.
You have the permissions required to install AWS account-wide roles.
You have installed and configured the latest AWS (aws
) and ROSA (rosa
) CLIs on your installation host.
You have created your ocm-role
and user-role
IAM roles.
To associate an additional AWS account, first create a profile in your local AWS configuration. Then, associate the account with your Red Hat organization by creating the ocm-role
, user, and account roles in the additional AWS account.
To create the roles in an additional region, specify the --profile <aws-profile>
parameter when running the rosa create
commands and replace <aws_profile>
with the additional account profile name:
To specify an AWS account profile when creating an OpenShift Cluster Manager role:
$ rosa create --profile <aws_profile> ocm-role
To specify an AWS account profile when creating a user role:
$ rosa create --profile <aws_profile> user-role
To specify an AWS account profile when creating the account roles:
$ rosa create --profile <aws_profile> account-roles
If you do not specify a profile, the default AWS profile is used. |
An AWS opt-in region is a region that is not enabled by default. If you want to deploy a Red Hat OpenShift Service on AWS (ROSA) cluster that uses the AWS Security Token Service (STS) in an opt-in region, you must meet the following requirements:
The region must be enabled in your AWS account. For more information about enabling opt-in regions, see Managing AWS Regions in the AWS documentation.
The security token version in your AWS account must be set to version 2. You cannot use version 1 security tokens for opt-in regions.
Updating to security token version 2 can impact the systems that store the tokens, due to the increased token length. For more information, see the AWS documentation on setting STS preferences. |
If you want to create a Red Hat OpenShift Service on AWS (ROSA) cluster with the AWS Security Token Service (STS) in an AWS opt-in region, you must set the security token version to version 2 in your AWS account.
You have installed and configured the latest AWS CLI on your installation host.
List the ID of the AWS account that is defined in your AWS CLI configuration:
$ aws sts get-caller-identity --query Account --output json
Ensure that the output matches the ID of the relevant AWS account.
List the security token version that is set in your AWS account:
$ aws iam get-account-summary --query SummaryMap.GlobalEndpointTokenVersion --output json
1
To update the security token version to version 2 for all regions in your AWS account, run the following command:
$ aws iam set-security-token-service-preferences --global-endpoint-token-version v2Token
Updating to security token version 2 can impact the systems that store the tokens, due to the increased token length. For more information, see the AWS documentation on setting STS preferences. |
When you use STS as your cluster credential method, Red Hat is not responsible for creating and managing Amazon Web Services (AWS) IAM policies, IAM users, or IAM roles. For information on creating these roles and policies, see the following sections on IAM roles.
To use the ocm
CLI, you must have an ocm-role
and user-role
resource.
See OpenShift Cluster Manager IAM role resources.
If you have a single cluster, see Account-wide IAM role and policy reference.
For each cluster, you must have the necessary operator roles. See Cluster-specific Operator IAM role reference.
This is an overview of the provisioned Amazon Web Services (AWS) components on a deployed Red Hat OpenShift Service on AWS (ROSA) cluster.
AWS EC2 instances are required to deploy the control plane and data plane functions for Red Hat OpenShift Service on AWS.
Instance types can vary for control plane and infrastructure nodes, depending on the worker node count.
At a minimum, the following EC2 instances are deployed:
Three m5.2xlarge
control plane nodes
Two r5.xlarge
infrastructure nodes
Two m5.xlarge
worker nodes
The instance type shown for worker nodes is the default value, but you can customize the instance type for worker nodes according to the needs of your workload.
For further guidance on worker node counts, see the information about initial planning considerations in the "Limits and scalability" topic listed in the "Additional resources" section of this page.
Amazon Elastic Block Store (Amazon EBS) block storage is used for both local node storage and persistent volume storage. The following values are the default size of the local, ephemeral storage provisioned for each EC2 instance.
Volume requirements for each EC2 instance:
Control Plane Volume
Size: 350GB
Type: gp3
Input/Output Operations Per Second: 1000
Infrastructure Volume
Size: 300GB
Type: gp3
Input/Output Operations Per Second: 900
Worker Volume
Default size: 300GB
Minimum size: 128GB
Minimum size: 75GB
Type: gp3
Input/Output Operations Per Second: 900
Clusters deployed before the release of OpenShift Container Platform 4.11 use gp2 type storage by default. |
Each cluster can use up to two Classic Load Balancers for application router and up to two Network Load Balancers for API.
For more information, see the ELB documentation for AWS.
The image registry is backed by AWS S3 storage. Resources Pruning of resources is performed regularly to optimize S3 usage and cluster performance.
Two buckets are required with a typical size of 2TB each. |
Configure your VPC according to the following requirements:
Subnets: Two subnets for a cluster with a single availability zone, or six subnets for a cluster with multiple availability zones.
Red Hat strongly recommends using unique subnets for each cluster. Sharing subnets between multiple clusters is not recommended.
A public subnet connects directly to the internet through an internet gateway. A private subnet connects to the internet through a network address translation (NAT) gateway. |
Route tables: One route table per private subnet, and one additional table per cluster.
Internet gateways: One Internet Gateway per cluster.
NAT gateways: One NAT Gateway per public subnet.
AWS security groups provide security at the protocol and port access level; they are associated with EC2 instances and Elastic Load Balancing (ELB) load balancers. Each security group contains a set of rules that filter traffic coming in and out of one or more EC2 instances.
Ensure that the ports required for cluster installation and operation are open on your network and configured to allow access between hosts. The requirements for the default security groups are listed in Required ports for default security groups.
Group | Type | IP Protocol | Port range |
---|---|---|---|
MasterSecurityGroup |
|
|
|
|
|
||
|
|
||
|
|
||
WorkerSecurityGroup |
|
|
|
|
|
||
BootstrapSecurityGroup |
|
|
|
|
|
When you create a cluster using an existing non-managed VPC, you can add additional custom security groups during cluster creation. Custom security groups are subject to the following limitations:
You must create the custom security groups in AWS before you create the cluster. For more information, see Amazon EC2 security groups for Linux instances.
You must associate the custom security groups with the VPC that the cluster will be installed into. Your custom security groups cannot be associated with another VPC.
You might need to request additional quota for your VPC if you are adding additional custom security groups. For information on AWS quota requirements for ROSA, see Required AWS service quotas in Prepare your environment. For information on requesting an AWS quota increase, see Requesting a quota increase.
During cluster deployment, Red Hat OpenShift Service on AWS requires a minimum bandwidth of 120 Mbps between cluster resources and public internet resources. When network connectivity is slower than 120 Mbps (for example, when connecting through a proxy) the cluster installation process times out and deployment fails.
After deployment, network requirements are determined by your workload. However, a minimum bandwidth of 120 Mbps helps to ensure timely cluster and operator upgrades.
If you are using a firewall to control egress traffic from your Red Hat OpenShift Service on AWS, you must configure your firewall to grant access to the certain domain and port combinations below. Red Hat OpenShift Service on AWS requires this access to provide a fully managed OpenShift service.
Only ROSA clusters deployed with PrivateLink can use a firewall to control egress traffic. |
You have configured an Amazon S3 gateway endpoint in your AWS Virtual Private Cloud (VPC). This endpoint is required to complete requests from the cluster to the Amazon S3 service.
Allowlist the following URLs that are used to install and download packages and tools:
Domain | Port | Function |
---|---|---|
|
443 |
Provides core container images. |
|
443 |
Provides core container images. |
|
443 |
Provides core container images. |
|
443 |
Provides core container images. |
|
443 |
Provides core container images. |
|
443 |
Provides core container images. |
|
443 |
Provides core container images. |
|
443 |
Provides core container images. |
|
443 |
Required. The |
|
443 |
Provides core container images. |
|
443 |
Provides core container images. |
|
443 |
Hosts all the container images that are stored on the Red Hat Ecosytem Catalog. Additionally, the registry provides access to the |
|
443 |
Required. Hosts a signature store that a container client requires for verifying images when pulling them from |
|
443 |
Required for all third-party images and certified Operators. |
|
443 |
Required. Allows interactions between the cluster and OpenShift Console Manager to enable functionality, such as scheduling upgrades. |
|
443 |
The |
|
443 |
Provides core container images as a fallback when quay.io is not available. |
|
443 |
The |
|
443 |
Used by ROSA for STS implementation with managed OIDC configuration. |
Allowlist the following telemetry URLs:
Domain | Port | Function |
---|---|---|
|
443 |
Required for telemetry. |
|
443 |
Required for telemetry. |
|
443 |
Required for telemetry. |
|
443 |
Required for telemetry and Red Hat Insights. |
|
443 |
Required for managed OpenShift-specific telemetry. |
|
443 |
Required for managed OpenShift-specific telemetry. |
Managed clusters require enabling telemetry to allow Red Hat to react more quickly to problems, better support the customers, and better understand how product upgrades impact clusters. For more information about how remote health monitoring data is used by Red Hat, see About remote health monitoring in the Additional resources section.
Allowlist the following Amazon Web Services (AWS) API URls:
Domain | Port | Function |
---|---|---|
|
443 |
Required to access AWS services and resources. |
Alternatively, if you choose to not use a wildcard for Amazon Web Services (AWS) APIs, you must allowlist the following URLs:
Domain | Port | Function |
---|---|---|
|
443 |
Used to install and manage clusters in an AWS environment. |
|
443 |
Used to install and manage clusters in an AWS environment. |
|
443 |
Used to install and manage clusters in an AWS environment. |
|
443 |
Used to install and manage clusters in an AWS environment. |
|
443 |
Used to install and manage clusters in an AWS environment, for clusters configured to use the global endpoint for AWS STS. |
|
443 |
Used to install and manage clusters in an AWS environment, for clusters configured to use regionalized endpoints for AWS STS. See AWS STS regionalized endpoints for more information. |
|
443 |
Used to install and manage clusters in an AWS environment. This endpoint is always us-east-1, regardless of the region the cluster is deployed in. |
|
443 |
Used to install and manage clusters in an AWS environment. |
|
443 |
Used to install and manage clusters in an AWS environment. |
|
443 |
Allows the assignment of metadata about AWS resources in the form of tags. |
Allowlist the following OpenShift URLs:
Domain | Port | Function |
---|---|---|
|
443 |
Used to access mirrored installation content and images. This site is also a source of release image signatures. |
|
443 |
Used to check if updates are available for the cluster. |
Allowlist the following site reliability engineering (SRE) and management URLs:
Domain | Port | Function |
---|---|---|
|
443 |
This alerting service is used by the in-cluster alertmanager to send alerts notifying Red Hat SRE of an event to take action on. |
|
443 |
This alerting service is used by the in-cluster alertmanager to send alerts notifying Red Hat SRE of an event to take action on. |
|
443 |
Alerting service used by Red Hat OpenShift Service on AWS to send periodic pings that indicate whether the cluster is available and running. |
|
443 |
Alerting service used by Red Hat OpenShift Service on AWS to send periodic pings that indicate whether the cluster is available and running. |
|
443 |
Required. Used by the |
|
22 |
The SFTP server used by |