Menu Close
Chapter 9. Deploying ROSA without AWS STS
9.1. AWS prerequisites for ROSA
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.
You must ensure that the prerequisites are met before installing ROSA. This requirements document does not apply to AWS Security Token Service (STS). If you are using STS, see the STS-specific requirements.
9.1.1. Deployment Prerequisites
To deploy Red Hat OpenShift Service on AWS (ROSA) into your existing Amazon Web Services (AWS) account, Red Hat requires that several prerequisites are met.
Red Hat recommends the use of AWS Organizations to manage multiple AWS accounts. The AWS Organizations, managed by the customer, host multiple AWS accounts. There is a root account in the organization that all accounts will refer to in the account hierarchy.
It is a best practice for the ROSA cluster to be hosted in an AWS account within an AWS Organizational Unit. A service control policy (SCP) is created and applied to the AWS Organizational Unit that manages what services the AWS sub-accounts are permitted to access. The SCP applies only to available permissions within a single AWS account for all AWS sub-accounts within the Organizational Unit. It is also possible to apply a SCP to a single AWS account. All other accounts in the customer’s AWS Organizations are managed in whatever manner the customer requires. Red Hat Site Reliability Engineers (SRE) will not have any control over SCPs within AWS Organizations.
9.1.2. Customer Requirements
Red Hat OpenShift Service on AWS (ROSA) clusters must meet several prerequisites before they can be deployed.
In order to create the cluster, the user must be logged in as an IAM user and not an assumed role or STS user.
9.1.2.1. Account
- The customer ensures that the AWS limits are sufficient to support Red Hat OpenShift Service on AWS provisioned within the customer’s AWS account.
The customer’s AWS account should be in the customer’s AWS Organizations with the applicable service control policy (SCP) applied.
NoteIt is not a requirement that the customer’s account be within the AWS Organizations or for the SCP to be applied, however Red Hat must be able to perform all the actions listed in the SCP without restriction.
- The customer’s AWS account should not be transferable to Red Hat.
- The customer may not impose AWS usage restrictions on Red Hat activities. Imposing restrictions will severely hinder Red Hat’s ability to respond to incidents.
The customer may deploy native AWS services within the same AWS account.
NoteCustomers are encouraged, but not mandated, to deploy resources in a Virtual Private Cloud (VPC) separate from the VPC hosting Red Hat OpenShift Service on AWS and other Red Hat supported services.
9.1.2.2. Access requirements
To appropriately manage the Red Hat OpenShift Service on AWS service, Red Hat must have the
AdministratorAccess
policy applied to the administrator role at all times. This requirement does not apply if you are using AWS Security Token Service (STS).NoteThis policy only provides Red Hat with permissions and capabilities to change resources in the customer-provided AWS account.
- Red Hat must have AWS console access to the customer-provided AWS account. This access is protected and managed by Red Hat.
- The customer must not utilize the AWS account to elevate their permissions within the Red Hat OpenShift Service on AWS cluster.
-
Actions available in the
rosa
CLI utility or OpenShift Cluster Manager console must not be directly performed in the customer’s AWS account.
9.1.2.3. Support requirements
- Red Hat recommends that the customer have at least Business Support from AWS.
- Red Hat has authority from the customer to request AWS support on their behalf.
- Red Hat has authority 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.
9.1.2.4. Security requirements
- Volume snapshots will remain within the customer’s AWS account and customer-specified region.
- Red Hat must have ingress access to EC2 hosts and the API server from allow-listed IP addresses.
- Red Hat must have egress allowed to forward system and audit logs to a Red Hat managed central logging stack.
9.1.3. Required customer procedure
Complete these steps before deploying Red Hat OpenShift Service on AWS (ROSA).
Procedure
- If you, as the customer, are utilizing AWS Organizations, then you must use an AWS account within your organization or create a new one.
- To ensure that Red Hat can perform necessary actions, you must either create a service control policy (SCP) or ensure that none is applied to the AWS account.
- Attach the SCP to the AWS account.
- Follow the ROSA procedures for setting up the environment.
9.1.3.1. Minimum required service control policy (SCP)
Service control policy (SCP) management is the responsibility of the customer. These policies are maintained in the AWS Organizations and control what services are available within the attached AWS accounts.
The minimum SCP requirement does not apply when using AWS security token service (STS). For more information about STS, see AWS prerequisites for ROSA with STS.
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 Support | All | Allow | |
AWS Key Management Service | All | Allow | |
AWS Security Token Service | All | 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 |
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ec2:*" ], "Resource": [ "*" ] }, { "Effect": "Allow", "Action": [ "autoscaling:*" ], "Resource": [ "*" ] }, { "Effect": "Allow", "Action": [ "s3:*" ], "Resource": [ "*" ] }, { "Effect": "Allow", "Action": [ "iam:*" ], "Resource": [ "*" ] }, { "Effect": "Allow", "Action": [ "elasticloadbalancing:*" ], "Resource": [ "*" ] }, { "Effect": "Allow", "Action": [ "cloudwatch:*" ], "Resource": [ "*" ] }, { "Effect": "Allow", "Action": [ "events:*" ], "Resource": [ "*" ] }, { "Effect": "Allow", "Action": [ "logs:*" ], "Resource": [ "*" ] }, { "Effect": "Allow", "Action": [ "support:*" ], "Resource": [ "*" ] }, { "Effect": "Allow", "Action": [ "kms:*" ], "Resource": [ "*" ] }, { "Effect": "Allow", "Action": [ "sts:*" ], "Resource": [ "*" ] }, { "Effect": "Allow", "Action": [ "tag:*" ], "Resource": [ "*" ] }, { "Effect": "Allow", "Action": [ "route53:*" ], "Resource": [ "*" ] }, { "Effect": "Allow", "Action": [ "servicequotas:ListServices", "servicequotas:GetRequestedServiceQuotaChange", "servicequotas:GetServiceQuota", "servicequotas:RequestServiceQuotaIncrease", "servicequotas:ListServiceQuotas" ], "Resource": [ "*" ] } ] }
9.1.4. Red Hat managed IAM references for AWS
Red Hat is responsible for creating and managing the following Amazon Web Services (AWS) resources: IAM policies, IAM users, and IAM roles.
9.1.4.1. IAM Policies
IAM policies are subject to modification as the capabilities of Red Hat OpenShift Service on AWS change.
The
AdministratorAccess
policy is used by the administration role. This policy provides Red Hat the access necessary to administer the Red Hat OpenShift Service on AWS (ROSA) cluster in the customer’s AWS account.{ "Version": "2012-10-17", "Statement": [ { "Action": "*", "Resource": "*", "Effect": "Allow" } ] }
9.1.4.2. IAM users
The osdManagedAdmin
user is created immediately after installing ROSA into the customer’s AWS account.
9.1.5. Provisioned AWS Infrastructure
This is an overview of the provisioned Amazon Web Services (AWS) components on a deployed Red Hat OpenShift Service on AWS (ROSA) cluster. For a more detailed listing of all provisioned AWS components, see the OpenShift Container Platform documentation.
9.1.5.1. EC2 instances
AWS EC2 instances are required for deploying the control plane and data plane functions of ROSA in the AWS public cloud.
Instance types can vary for control plane and infrastructure nodes, depending on the worker node count. At a minimum, the following EC2 instances will be deployed:
-
Three
m5.2xlarge
control plane nodes -
Two
r5.xlarge
infrastructure nodes -
Two
m5.xlarge
customizable worker nodes
For further guidance on worker node counts, see the link to "Initial Planning Considerations" in the "Additional resources" section of this page.
9.1.5.2. AWS Elastic Block Store (EBS) storage
Amazon EBS block storage is used for both local node storage and persistent volume storage.
Volume requirements for each EC2 instance:
Control Plane Volume
- Size: 350GB
- Type: io1
- Input/Output Operations Per Second: 1000
Infrastructure Volume
- Size: 300GB
- Type: gp2
- Input/Output Operations Per Second: 900
Worker Volume
- Size: 300GB
- Type: gp2
- Input/Output Operations Per Second: 900
9.1.5.3. Elastic load balancers
Up to two Network Elastic Load Balancers (ELBs) for API and up to two Classic ELBs for application router. For more information, see the ELB documentation for AWS.
9.1.5.4. S3 storage
The image registry and Elastic Block Store (EBS) volume snapshots are backed by AWS S3 storage. Pruning of resources is performed regularly to optimize S3 usage and cluster performance.
Two buckets are required with a typical size of 2TB each.
9.1.5.5. VPC
Customers should expect to see one VPC per cluster. Additionally, the VPC will need the following configurations:
- Subnets: Two subnets for a cluster with a single availability zone, or six subnets for a cluster with multiple availability zones.
- Router tables: One router 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.
9.1.5.5.1. Sample VPC Architecture

9.1.5.6. Security groups
AWS security groups provide security at the protocol and port access level; they are associated with EC2 instances and Elastic Load Balancers. Each security group contains a set of rules that filter traffic coming in and out of an EC2 instance. You must ensure the ports required for the OpenShift installation are open on your network and configured to allow access between hosts.
Group | Type | IP Protocol | Port range |
---|---|---|---|
MasterSecurityGroup |
|
|
|
|
| ||
|
| ||
|
| ||
WorkerSecurityGroup |
|
|
|
|
| ||
BootstrapSecurityGroup |
|
|
|
|
|
9.1.6. AWS firewall prerequisites
Only ROSA clusters deployed with PrivateLink may use a firewall to control egress traffic.
This section provides the necessary details that enable you to control egress traffic from your Red Hat OpenShift Service on AWS cluster. If you are using a firewall to control egress traffic, you must configure your firewall to grant access to the domain and port combinations below. Red Hat OpenShift Service on AWS requires this access to provide a fully managed OpenShift service.
Procedure
Allowlist the following URLs that are used to install and download packages and tools:
Domain Port Function registry.redhat.io
443
Provides core container images.
quay.io
443
Provides core container images.
*.quay.io
443
Provides core container images.
sso.redhat.com
443, 80
Required. The
https://console.redhat.com/openshift
site uses authentication fromsso.redhat.com
to download the pull secret and use Red Hat SaaS solutions to facilitate monitoring of your subscriptions, cluster inventory, chargeback reporting, and so on.quay-registry.s3.amazonaws.com
443
Provides core container images.
cm-quay-production-s3.s3.amazonaws.com
443
Provides core container images.
cart-rhcos-ci.s3.amazonaws.com
443
Provides Red Hat Enterprise Linux CoreOS (RHCOS) images.
openshift.org
443
Provides Red Hat Enterprise Linux CoreOS (RHCOS) images.
registry.access.redhat.com
443
Provides access to the odo CLI tool that helps developers build on OpenShift and Kubernetes.
console.redhat.com
443, 80
Required. Allows interactions between the cluster and OpenShift Console Manager to enable functionality, such as scheduling upgrades.
sso.redhat.com
443
The
https://console.redhat.com/openshift
site uses authentication fromsso.redhat.com
.pull.q1w2.quay.rhcloud.com
443
Provides core container images as a fallback when quay.io is not available.
.q1w2.quay.rhcloud.com
443
Provides core container images as a fallback when quay.io is not available.
NoteCreating a firewall with a ROSA private cluster (non-PrivateLink) is not supported.
When you add a site such as
quay.io
to your allowlist, do not add a wildcard entry such as*.quay.io
to your denylist. In most cases, image registries use a content delivery network (CDN) to serve images. If a firewall blocks access, then image downloads are denied when the initial download request is redirected to a host name such ascdn01.quay.io
.CDN host names, such as
cdn01.quay.io
, are covered when you add a wildcard entry, such as.quay.io
, in your allowlist.Allowlist the following telemetry URLs:
Domain Port Function cert-api.access.redhat.com
443
Required for telemetry.
api.access.redhat.com
443
Required for telemetry.
infogw.api.openshift.com
443
Required for telemetry.
console.redhat.com
443
Required for telemetry and Red Hat Insights.
observatorium.api.openshift.comm
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. See About remote health monitoring for more information about how remote health monitoring data is used by Red Hat.
Allowlist the following Amazon Web Services (AWS) API URls:
Domain Port Function .amazonaws.com
443
Required to access AWS services and resources.
Alternatively, if you wish to not use a wildcard for Amazon Web Services (AWS) APIs, you must allowlist the following URLs:
Domain Port Function ec2.amazonaws.com
443
Used to install and manage clusters in an AWS environment.
events.amazonaws.com
443
Used to install and manage clusters in an AWS environment.
iam.amazonaws.com
443
Used to install and manage clusters in an AWS environment.
route53.amazonaws.com
443
Used to install and manage clusters in an AWS environment.
sts.amazonaws.com
443
Used to install and manage clusters in an AWS environment.
tagging.us-east-1.amazonaws.com
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.
ec2.<aws_region>.amazonaws.com
443
Used to install and manage clusters in an AWS environment.
elasticloadbalancing.<aws_region>.amazonaws.com
443
Used to install and manage clusters in an AWS environment.
servicequotas.<aws region>.amazonaws.com
443, 80
Required. Used to confirm quotas for deploying the service.
tagging.<region>.amazonaws.com
443, 80
Allows the assignment of metadata about AWS resources in the form of tags.
Allowlist the following OpenShift URLs:
Domain Port Function mirror.openshift.com
443
Used to access mirrored installation content and images. This site is also a source of release image signatures, although the Cluster Version Operator (CVO) needs only a single functioning source.
storage.googleapis.com/openshift-release
(Recommended)443
Alternative site to mirror.openshift.com/. Used to download platform release signatures that are used by the cluster to know what images to pull from quay.io.
api.openshift.com
443
Used to check if updates are available for the cluster.
Allowlist the following site reliability engineering (SRE) and management URLs:
Domain Port Function api.pagerduty.com
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.
events.pagerduty.com
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.
api.deadmanssnitch.com
443
Alerting service used by OpenShift Dedicated to send periodic pings that indicate whether the cluster is available and running.
nosnch.in
443
Alerting service used by OpenShift Dedicated to send periodic pings that indicate whether the cluster is available and running.
*.osdsecuritylogs.splunkcloud.com
ORinputs1.osdsecuritylogs.splunkcloud.com
inputs2.osdsecuritylogs.splunkcloud.com
inputs4.osdsecuritylogs.splunkcloud.com
inputs5.osdsecuritylogs.splunkcloud.com
inputs6.osdsecuritylogs.splunkcloud.com
inputs7.osdsecuritylogs.splunkcloud.com
inputs8.osdsecuritylogs.splunkcloud.com
inputs9.osdsecuritylogs.splunkcloud.com
inputs10.osdsecuritylogs.splunkcloud.com
inputs11.osdsecuritylogs.splunkcloud.com
inputs12.osdsecuritylogs.splunkcloud.com
inputs13.osdsecuritylogs.splunkcloud.com
inputs14.osdsecuritylogs.splunkcloud.com
inputs15.osdsecuritylogs.splunkcloud.com
9997
Used by the
splunk-forwarder-operator
as a logging forwarding endpoint to be used by Red Hat SRE for log-based alerting.http-inputs-osdsecuritylogs.splunkcloud.com
443
Required. Used by the
splunk-forwarder-operator
as a logging forwarding endpoint to be used by Red Hat SRE for log-based alerting.sftp.access.redhat.com
(Recommended)22
The SFTP server used by
must-gather-operator
to upload diagnostic logs to help troubleshoot issues with the cluster.If you did not allow a wildcard for Amazon Web Services (AWS) APIs, you will need to also allow the S3 bucket used for the internal OpenShift registry. To retrieve that endpoint, run the following command once the cluster has successfully been provisioned:
$ oc -n openshift-image-registry get pod -l docker-registry=default -o json | jq '.items[].spec.containers[].env[] | select(.name=="REGISTRY_STORAGE_S3_BUCKET")'
The S3 endpoint should be in the following format: '<cluster-name>-<random-string>-image-registry-<cluster-region>-<random-string>.s3.dualstack.<cluster-region>.amazonaws.com'.
- Allowlist any site that provides resources for a language or framework that your builds require.
- Allowlist any outbound URLs that depend on the languages and frameworks used in OpenShift. See OpenShift Outbound URLs to Allow for a list of recommended URLs to be allowed on the firewall or proxy.
9.1.7. Next steps
9.1.8. Additional resources
- See Intial Planning Considerations for guidance on worker node count.
- See SRE access to all Red Hat OpenShift Service on AWS clusters for information about how Red Hat site reliability engineering accesses ROSA clusters.
- Understanding the ROSA deployment workflow
9.2. Understanding the ROSA deployment workflow
Before you create a Red Hat OpenShift Service on AWS (ROSA) cluster that uses the AWS Security Token Service (STS), you must complete the AWS prerequisites, verify that the required AWS service quotas are available, and set up your environment.
This document provides an overview of the ROSA with STS deployment workflow stages and refers to detailed resources for each stage.
9.2.1. Overview of the ROSA deployment workflow
You can follow the workflow stages outlined in this section to set up and access a Red Hat OpenShift Service on AWS (ROSA) cluster.
- Perform the AWS prerequisites. To deploy a ROSA cluster, your AWS account must meet the prerequisite requirements.
- Review the required AWS service quotas. To prepare for your cluster deployment, review the AWS service quotas that are required to run a ROSA cluster.
-
Configure your AWS account. Before you create a ROSA cluster, you must enable ROSA in your AWS account, install and configure the AWS CLI (
aws
) tool, and verify the AWS CLI tool configuration. -
Install the ROSA and OpenShift CLI tools and verify the AWS servce quotas. Install and configure the ROSA CLI (
aws
) and the OpenShift CLI (oc
). You can verify if the required AWS resource quotas are available by using the ROSA CLI. -
Create a ROSA cluster or Create a ROSA cluster using AWS PrivateLink. Use the ROSA CLI (
rosa
) to create a cluster. You can optionally create a ROSA cluster with AWS PrivateLink. -
Access a cluster. You can configure an identity provider and grant cluster administrator privileges to the identity provider users as required. You can also access a newly deployed cluster quickly by configuring a
cluster-admin
user. - Revoke access to a ROSA cluster for a user. You can revoke access to a ROSA cluster from a user by using the ROSA CLI or the web console.
-
Delete a ROSA cluster. You can delete a ROSA cluster by using the ROSA CLI (
rosa
).
9.2.2. Additional resources
- For information about using the ROSA deployment workflow to create a cluster that uses the AWS Security Token Service (STS), see Understanding the ROSA with STS deployment workflow.
- Configuring identity providers
- Deleting a cluster
- Deleting access to a cluster
- Command quick reference for creating clusters and users
9.3. Required AWS service quotas
Review this list of the required Amazon Web Service (AWS) service quotas that are required to run an Red Hat OpenShift Service on AWS cluster.
9.3.1. Required AWS service quotas
The table below describes the AWS service quotas and levels required to create and run an Red Hat OpenShift Service on AWS cluster.
The AWS SDK allows ROSA to check quotas, but the AWS SDK calculation does not include your existing usage. Therefore, it is possible that the quota check can pass in the AWS SDK yet the cluster creation can fail. To fix this issue, increase your quota.
If you need to modify or increase a specific quota, see Amazon’s documentation on requesting a quota increase.
Quota name | Service code | Quota code | Minimum required value | Recommended value |
---|---|---|---|---|
Number of EIPs - VPC EIPs | ec2 | L-0263D0A3 | 5 | 5 |
Running On-Demand Standard (A, C, D, H, I, M, R, T, Z) instances | ec2 | L-1216C47A | 100 | 100 |
VPCs per Region | vpc | L-F678F1CE | 5 | 5 |
Internet gateways per Region | vpc | L-A4707A72 | 5 | 5 |
Network interfaces per Region | vpc | L-DF5E4CA3 | 5,000 | 5,000 |
General Purpose SSD (gp2) volume storage | ebs | L-D18FCD1D | 50 | 300 |
Number of EBS snapshots | ebs | L-309BACF6 | 300 | 300 |
Provisioned IOPS | ebs | L-B3A130E6 | 300,000 | 300,000 |
Provisioned IOPS SSD (io1) volume storage | ebs | L-FD252861 | 50 | 300 |
Application Load Balancers per Region | elasticloadbalancing | L-53DA6B97 | 50 | 50 |
Classic Load Balancers per Region | elasticloadbalancing | L-E9E9831D | 20 | 20 |
9.3.2. Next steps
9.3.3. Additional resources
9.4. Configuring your AWS account
After you complete the AWS prerequisites, configure your AWS account and enable the Red Hat OpenShift Service on AWS (ROSA) service.
9.4.1. Configuring your AWS account
To configure your AWS account to use the ROSA service, complete the following steps.
Prerequisites
- Review and complete the deployment prerequisites and policies.
- Create a Red Hat account, if you do not already have one. Then, check your email for a verification link. You will need these credentials to install ROSA.
Procedure
Log in to the Amazon Web Services (AWS) account that you want to use.
A dedicated AWS account is recommended to run production clusters. If you are using AWS Organizations, you can use an AWS account within your organization or create a new one.
If you are using AWS Organizations and you need to have a service control policy (SCP) applied to the AWS account you plan to use, see AWS Prerequisites for details on the minimum required SCP.
As part of the cluster creation process,
rosa
establishes anosdCcsAdmin
IAM user. This user uses the IAM credentials you provide when configuring the AWS CLI.NoteThis user has
Programmatic
access enabled and theAdministratorAccess
policy attached to it.Enable the ROSA service in the AWS Console.
- Sign in to your AWS account.
- To enable ROSA, go to the ROSA service and select Enable OpenShift.
Install and configure the AWS CLI.
Follow the AWS command-line interface documentation to install and configure the AWS CLI for your operating system.
Specify the correct
aws_access_key_id
andaws_secret_access_key
in the.aws/credentials
file. See AWS Configuration basics in the AWS documentation.Set a default AWS region.
NoteIt is recommended to set the default AWS region by using the environment variable.
The ROSA service evaluates regions in the following priority order:
-
The region specified when running a
rosa
command with the--region
flag. -
The region set in the
AWS_DEFAULT_REGION
environment variable. See Environment variables to configure the AWS CLI in the AWS documentation. - The default region set in your AWS configuration file. See Quick configuration with aws configure in the AWS documentation.
-
The region specified when running a
Optional: Configure your AWS CLI settings and credentials by using an AWS named profile.
rosa
evaluates AWS named profiles in the following priority order:-
The profile specified when running a
rosa
command with the--profile
flag. -
The profile set in the
AWS_PROFILE
environment variable. See Named profiles in the AWS documentation.
-
The profile specified when running a
Verify the AWS CLI is installed and configured correctly by running the following command to query the AWS API:
$ aws sts get-caller-identity
Example output
--------------------------------------------------------------------------------- | GetCallerIdentity | +-------------------------------------------------------------------------------+ |+-----------------------------------+-----------------------+-----------------+| || Account | Arn | UserID || |+-----------------------------------+-----------------------+-----------------+| || <account_name> | arn:aws:iam<string>:user:name | <userID> || |+-----------------------------------+-----------------------+-----------------+|
After completing these steps, install ROSA.
9.4.2. Next steps
9.4.3. Additional resources
9.5. Installing the ROSA CLI
After you configure your AWS account, install Red Hat OpenShift Service on AWS (ROSA).
9.5.1. Installing ROSA
Complete the following steps to install ROSA before creating a cluster.
Prerequisites
- Review and complete the AWS prerequisites and ROSA policies.
- Create a Red Hat account, if you do not already have one. Then, check your email for a verification link. You will need these credentials to install ROSA.
- Configure your AWS account and enable the ROSA service in your AWS account.
Procedure
Install
rosa
, the Red Hat OpenShift Service on AWS command-line interface (CLI).-
Download the latest release of the
rosa
CLI for your operating system. -
Optional: Rename the executable file you downloaded to
rosa
. This documentation usesrosa
to refer to the executable file. Optional: Add
rosa
to your path.Example
$ mv rosa /usr/local/bin/rosa
Enter the following command to verify your installation:
$ rosa
Example output
Command line tool for ROSA. Usage: rosa [command] Available Commands: completion Generates bash completion scripts create Create a resource from stdin delete Delete a specific resource describe Show details of a specific resource edit Edit a specific resource help Help about any command init Applies templates to support Managed OpenShift on AWS clusters list List all resources of a specific type login Log in to your Red Hat account logout Log out logs Show logs of a specific resource verify Verify resources are configured correctly for cluster install version Prints the version of the tool Flags: --debug Enable debug mode. -h, --help help for rosa -v, --v Level log level for V logs Use "rosa [command] --help" for more information about a command.
Optional: Generate the command completion scripts for the
rosa
CLI. The following example generates the Bash completion scripts for a Linux machine:$ rosa completion bash | sudo tee /etc/bash_completion.d/rosa
Optional: Enable
rosa
command completion from your existing terminal. The following example enables Bash completion forrosa
in an existing terminal on a Linux machine:$ source /etc/bash_completion.d/rosa
-
Download the latest release of the
Enter the following command to verify that your AWS account has the necessary permissions.
$ rosa verify permissions
Example output
I: Validating SCP policies... I: AWS SCP policies ok
Log in to your Red Hat account with
rosa
.Enter the following command.
$ rosa login
Replace
<my_offline_access_token>
with your token.Example output
To login to your Red Hat account, get an offline access token at https://console.redhat.com/openshift/token/rosa ? Copy the token and paste it here: <my-offline-access-token>
Example output continued
I: Logged in as 'rh-rosa-user' on 'https://api.openshift.com'
Verify that your AWS account has the necessary quota to deploy an Red Hat OpenShift Service on AWS cluster.
$ rosa verify quota --region=us-west-2
Example output
I: Validating AWS quota... I: AWS quota ok
NoteSometimes your AWS quota varies by region. If you receive any errors, try a different region.
If you need to increase your quota, go to your AWS console, and request a quota increase for the service that failed.
After both the permissions and quota checks pass, proceed to the next step.
Prepare your AWS account for cluster deployment:
Run the following command to verify your Red Hat and AWS credentials are setup correctly. Check that your AWS Account ID, Default Region and ARN match what you expect. You can safely ignore the rows beginning with
OCM
for now.$ rosa whoami
Example output
AWS Account ID: 000000000000 AWS Default Region: us-east-2 AWS ARN: arn:aws:iam::000000000000:user/hello OCM API: https://api.openshift.com OCM Account ID: 1DzGIdIhqEWyt8UUXQhSoWaaaaa OCM Account Name: Your Name OCM Account Username: you@domain.com OCM Account Email: you@domain.com OCM Organization ID: 1HopHfA2hcmhup5gCr2uH5aaaaa OCM Organization Name: Red Hat OCM Organization External ID: 0000000
Initialize your AWS account. This step runs a CloudFormation template that prepares your AWS account for cluster deployment and management. This step typically takes 1-2 minutes to complete.
$ rosa init
Example output
I: Logged in as 'rh-rosa-user' on 'https://api.openshift.com' I: Validating AWS credentials... I: AWS credentials are valid! I: Validating SCP policies... I: AWS SCP policies ok I: Validating AWS quota... I: AWS quota ok I: Ensuring cluster administrator user 'osdCcsAdmin'... I: Admin user 'osdCcsAdmin' created successfully! I: Verifying whether OpenShift command-line tool is available... E: OpenShift command-line tool is not installed. Run 'rosa download oc' to download the latest version, then add it to your PATH.
Install the OpenShift CLI (
oc
) from therosa
CLI.Enter this command to download the latest version of the
oc
CLI:$ rosa download oc
-
After downloading the
oc
CLI, unzip it and add it to your path. Enter this command to verify that the
oc
CLI is installed correctly:$ rosa verify oc
After installing ROSA, you are ready to create a cluster.
9.5.2. Next steps
9.5.3. Additional resources
9.6. Creating a ROSA cluster without AWS STS
After you set up your environment and install Red Hat OpenShift Service on AWS (ROSA), create a cluster.
This document describes how to set up a ROSA cluster. Alternatively, you can create a ROSA cluster with AWS PrivateLink.
9.6.1. Creating your cluster
You can create an Red Hat OpenShift Service on AWS cluster using the rosa
CLI.
Prerequisites
You have installed Red Hat OpenShift Service on AWS.
AWS Shared VPCs are not currently supported for ROSA installs.
Procedure
You can create a cluster using the default settings or by specifying custom settings using the interactive mode. To view other options when creating a cluster, enter
rosa create cluster --help
.Creating a cluster can take up to 40 minutes.
NoteMultiple availability zones (AZ) are recommended for production workloads. The default is a single availability zone. Use
--help
for an example of how to set this option manually or use interactive mode to be prompted for this setting.To create your cluster with the default cluster settings:
$ rosa create cluster --cluster-name=<cluster_name>
Example output
I: Creating cluster with identifier '1de87g7c30g75qechgh7l5b2bha6r04e' and name 'rh-rosa-test-cluster1' I: To view list of clusters and their status, run `rosa list clusters` I: Cluster 'rh-rosa-test-cluster1' has been created. I: Once the cluster is 'Ready' you will need to add an Identity Provider and define the list of cluster administrators. See `rosa create idp --help` and `rosa create user --help` for more information. I: To determine when your cluster is Ready, run `rosa describe cluster rh-rosa-test-cluster1`.
To create a cluster using interactive prompts:
$ rosa create cluster --interactive
To configure your networking IP ranges, you can use the following default ranges. For more information when using manual mode, use
rosa create cluster --help | grep cidr
. In interactive mode, you are prompted for the settings.- Node CIDR: 10.0.0.0/16
- Service CIDR: 172.30.0.0/16
- Pod CIDR: 10.128.0.0/14
Enter the following command to check the status of your cluster. During cluster creation, the
State
field from the output will transition frompending
toinstalling
, and finally toready
.$ rosa describe cluster --cluster=<cluster_name>
Example output
Name: rh-rosa-test-cluster1 OpenShift Version: 4.6.8 DNS: *.example.com ID: uniqueidnumber External ID: uniqueexternalidnumber AWS Account: 123456789101 API URL: https://api.rh-rosa-test-cluster1.example.org:6443 Console URL: https://console-openshift-console.apps.rh-rosa-test-cluster1.example.or Nodes: Master: 3, Infra: 2, Compute: 2 Region: us-west-2 Multi-AZ: false State: ready Channel Group: stable Private: No Created: Jan 15 2021 16:30:55 UTC Details Page: https://console.redhat.com/examplename/details/idnumber
NoteIf installation fails or the
State
field does not change toready
after 40 minutes, check the installation troubleshooting documentation for more details.Track the progress of the cluster creation by watching the OpenShift installer logs:
$ rosa logs install --cluster=<cluster_name> --watch
9.6.2. Next steps
9.6.3. Additional resources
9.7. Deleting access to a ROSA cluster
Delete access to a Red Hat OpenShift Service on AWS (ROSA) cluster using the rosa
command-line.
9.7.1. Revoking dedicated-admin
access using the rosa
CLI
You can revoke access for a dedicated-admin
user if you are the user who created the cluster, the organization administrator user, or the super administrator user.
Prerequisites
- You have added an Identity Provider (IDP) to your cluster.
- You have the IDP user name for the user whose privileges you are revoking.
- You are logged in to the cluster.
Procedure
Enter the following command to revoke the
dedicated-admin
access of a user:$ rosa revoke user dedicated-admin --user=<idp_user_name> --cluster=<cluster_name>
Enter the following command to verify that your user no longer has
dedicated-admin
access. The output does not list the revoked user.$ oc get groups dedicated-admins
9.7.2. Revoking cluster-admin
access using the rosa
CLI
Only the user who created the cluster can revoke access for cluster-admin
users.
Prerequisites
- You have added an Identity Provider (IDP) to your cluster.
- You have the IDP user name for the user whose privileges you are revoking.
- You are logged in to the cluster.
Procedure
Enter the following command to revoke the
cluster-admin
access of a user:$ rosa revoke user cluster-admins --user=myusername --cluster=mycluster
Enter the following command to verify that the user no longer has
cluster-admin
access. The output does not list the revoked user.$ oc get groups cluster-admins
9.8. Deleting a ROSA cluster
Delete a Red Hat OpenShift Service on AWS (ROSA) cluster using the rosa
command-line.
9.8.1. Prerequisites
If Red Hat OpenShift Service on AWS created a VPC, you must remove the following items from your cluster before you can successfully delete your cluster:
- Network configurations, such as VPN configurations and VPC peering connections
- Any additional services that were added to the VPC
If these configurations and services remain, the cluster does not delete properly.
9.8.2. Deleting a cluster
You can delete an Red Hat OpenShift Service on AWS cluster using the rosa
CLI.
Procedure
Enter the following command to delete a cluster and watch the logs, replacing
<cluster_name>
with the name or ID of your cluster:$ rosa delete cluster --cluster=<cluster_name> --watch
To clean up your CloudFormation stack, enter the following command:
$ rosa init --delete-stack
9.9. Command quick reference for creating clusters and users
9.9.1. Command quick reference list
If you have already created your first cluster and users, this list can serve as a command quick reference list when creating additional clusters and users.
## Configures your AWS account and ensures everything is setup correctly $ rosa init ## Starts the cluster creation process (~30-40minutes) $ rosa create cluster --cluster-name=<cluster_name> ## Connect your IDP to your cluster $ rosa create idp --cluster=<cluster_name> --interactive ## Promotes a user from your IDP to dedicated-admin level $ rosa grant user dedicated-admin --user=<idp_user_name> --cluster=<cluster_name> ## Checks if your install is ready (look for State: Ready), ## and provides your Console URL to login to the web console. $ rosa describe cluster --cluster=<cluster_name>