Red Hat SummitQuesto contenuto non è disponibile nella lingua selezionata.
Chapter 2. Detailed requirements for deploying Red Hat OpenShift Service on AWS
To deploy a Red Hat OpenShift Service on AWS cluster with Security Token Service (STS), configure your AWS account with the required quotas, IAM permissions, and firewall egress rules, including an Amazon S3 gateway endpoint. Complete the requirements before deploying your cluster.
2.1. AWS account
You must have an AWS account with the following considerations to deploy a Red Hat OpenShift Service on AWS cluster.
- Your AWS account must allow sufficient quota to deploy your cluster.
- If your organization applies and enforces service control policies (SCPs), 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.
2.2. Support requirements
To receive Red Hat support, your account must use a specific AWS plan and have the required permissions on your account.
- 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.
2.3. Security requirements
Before deploying your cluster, ensure that you plan for your egresses and ingresses to have access to certain domains and IP addresses.
- 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 the domains documented in the "AWS Firewall prerequisites" section. Clusters with egress zero are exempt from this requirement.
2.4. Requirements for using OpenShift Cluster Manager
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.
2.4.1. AWS account association
When you provision Red Hat OpenShift Service on AWS using OpenShift Cluster Manager (console.redhat.com), 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.
2.5. Associating your AWS account with IAM roles
You can associate or link your AWS account with existing IAM roles by using the ROSA command-line interface (CLI) (rosa).
Prerequisites
- 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 CLI (
aws) and ROSA CLI on your installation host. You have created the
ocm-roleanduser-roleIAM 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-roleIf
Yesis displayed in theLinkedcolumn for both roles, you have already linked the roles to an AWS account.
Procedure
In the ROSA CLI, link your
ocm-roleresource to your Red Hat organization by using your Amazon Resource Name (ARN):NoteYou must have Red Hat Organization Administrator privileges to run the
rosa linkcommand. After you link theocm-roleresource with your AWS account, it takes effect and is visible to all users in the organization.$ rosa link ocm-role --role-arn <arn>For example:
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>'In the ROSA CLI, link your
user-roleresource to your Red Hat user account by using your Amazon Resource Name (ARN):$ rosa link user-role --role-arn <arn>For example:
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>'
2.6. Associating multiple AWS accounts with your Red Hat organization
You can associate multiple AWS accounts with your Red Hat organization. Associating multiple accounts lets you create Red Hat OpenShift Service on AWS clusters on any of the associated AWS accounts from your Red Hat organization.
With this capability, you can create clusters on different AWS profiles according to characteristics that make sense for your business, for example, by using one AWS profile for each region to create region-bound environments.
Prerequisites
- 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 CLI (
aws) and ROSA command-line interface (CLI) (rosa) on your installation host. -
You have created the
ocm-roleanduser-roleIAM roles for Red Hat OpenShift Service on AWS.
Procedure
To specify an AWS account profile when creating an OpenShift Cluster Manager role:
$ rosa create --profile <aws_profile> ocm-roleTo specify an AWS account profile when creating a user role:
$ rosa create --profile <aws_profile> user-roleTo specify an AWS account profile when creating the account roles:
$ rosa create --profile <aws_profile> account-rolesNoteIf you do not specify a profile, the default AWS profile and its associated AWS region are used.
2.7. Requirements for deploying a cluster in an opt-in region
An AWS opt-in region is a region that is not enabled in your AWS account by default. If you want to deploy a Red Hat OpenShift Service on AWS 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.
ImportantUpdating 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.
2.8. Setting the AWS security token version
If you want to create a Red Hat OpenShift Service on AWS 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.
Prerequisites
- You have installed and configured the latest AWS CLI on your installation host.
Procedure
List the ID of the AWS account that is defined in your AWS CLI configuration:
$ aws sts get-caller-identity --query Account --output jsonEnsure 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 jsonFor example:
1To 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 v2TokenImportantUpdating 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.
2.9. Provisioned AWS Infrastructure
This is an overview of the provisioned Amazon Web Services (AWS) components on a deployed Red Hat OpenShift Service on AWS cluster.
2.9.1. EC2 instances
AWS EC2 instances are required to deploy Red Hat OpenShift Service on AWS.
At a minimum, two m5.xlarge EC2 instances are deployed for use as 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.
2.9.2. Amazon Elastic Block Store storage
Amazon Elastic Block Store (Amazon EBS) block storage is used for both local node storage and persistent volume storage. By default, the following storage is provisioned for each EC2 instance:
Node volumes
-
Type:
AWS EBS GP3 - Default size: 300 GiB (adjustable at creation time)
- Minimum size: 75 GiB
-
Type:
Workload persistent volumes
-
Default storage class:
gp3-csi -
Provisioner:
ebs.csi.aws.com - Dynamic persistent volume provisioning
-
Default storage class:
2.9.3. Elastic Load Balancing
By default, one Network Load Balancer is created for use by the default ingress controller. You can create additional load balancers of the following types according to the needs of your workload:
- Classic Load Balancer
- Network Load Balancer
- Application Load Balancer
For more information, see the ELB documentation for AWS.
2.9.4. S3 storage
The image registry is backed by AWS S3 storage. Resources are pruned regularly to optimize S3 usage and cluster performance.
Two buckets are required with a typical size of 2TB each.
2.9.5. VPC
Configure your VPC according to the following requirements:
Subnets: Every cluster requires a minimum of one private subnet for every availability zone. For example, 1 private subnet is required for a single-zone cluster, and 3 private subnets are required for a cluster with 3 availability zones.
If your cluster needs direct access to a network that is external to the cluster, including the public internet, you require at least one public subnet.
Red Hat strongly recommends using unique subnets for each cluster. Sharing subnets between multiple clusters is not recommended.
NoteA 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.
2.9.6. Security groups
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 |
|---|---|---|---|
| WorkerSecurityGroup |
|
|
|
|
|
|
2.10. Additional custom security groups
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 Red Hat OpenShift Service on AWS see Required AWS service quotas in Prepare your environment. For information on requesting an AWS quota increase, see Requesting a quota increase.
2.11. Networking prerequisites
During cluster deployment, Red Hat OpenShift Service on AWS requires a minimum bandwidth of 120 Mbps between cluster infrastructure and the public internet or private network locations that give deployment resources. When network connectivity is slower than 120 Mbps, the cluster installation process times out, and deployment fails. After cluster deployment, your workloads determine network requirements. A minimum bandwidth of 120 Mbps helps to ensure timely cluster and Operator upgrades.
| 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 Red Hat OpenShift Service on AWS for STS implementation with managed OIDC configuration. |
| Domain | Port | Function |
|---|---|---|
|
| 443 | Required for telemetry. |
|
| 443 | Required for telemetry. |
|
| 443 | Required for telemetry. |
|
| 443 | Required for telemetry and Red Hat Lightspeed. |
|
| 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.
| 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. |
| 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. |
| 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 |
2.12. Firewall prerequisites for Red Hat OpenShift Service on AWS
If you are using a firewall to control egress traffic from Red Hat OpenShift Service on AWS, your Virtual Private Cloud (VPC) must be able to complete requests from the cluster to the Amazon S3 service, for example, via an Amazon S3 gateway. You must also configure your firewall to grant access to the following domain and port combinations.
2.12.1. Domains for installation 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 | Provides core container images. |
|
| 443 |
Required. 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. Used to check for available updates to the cluster. |
|
| 443 | Required. 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. |
|
| 443 | This is for GovCloud only. |
2.12.2. Domains for telemetry
| Domain | Port | Function |
|---|---|---|
|
| 443 | Required for telemetry. |
|
| 443 | Required. Allows interactions between the cluster and OpenShift Console Manager to enable functionality, such as scheduling upgrades. |
|
| 443 |
Required. The |
|
| 443 | This is for GovCloud only. |
|
| 443 | This is for GovCloud only. |
|
| 443 | This is for GovCloud only. |
|
| 443 | This is for GovCloud only. |
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.
2.12.3. Domains for Amazon Web Services (AWS) APIs
| Domain | Port | Function |
|---|---|---|
|
| 443 |
Required. Used to access the AWS Secure Token Service (STS) regional endpoint. Ensure that you replace |
2.12.4. Domains for your workload
Your workload may require access to other sites that provide resources for programming languages or frameworks.
- Allow access to sites that provide resources required by your builds.
- Allow access to outbound URLs required for your workload, for example, OpenShift Outbound URLs to Allow.
2.12.5. Optional domains to enable third-party content
| Domain | Port | Function |
|---|---|---|
|
| 443 | Optional. Required for all third-party-images and certified operators. |
|
| 443 |
Optional. Provides access to container images hosted on |
|
| 443 | Optional. Required for Sonatype Nexus, F5 Big IP operators. |
2.12.6. Outbound firewall rules for the ROSA CLI for clusters with egress zero
If you use a bastion host to connect to a private cluster with egress zero, you must add the following rules to your firewall so that it can connect and authenticate to the cluster.
| Domain | Port | From/To | Function |
|---|---|---|---|
|
| 443 | ROSA CLI running on bastion host |
The OpenShift console uses authentication from |
|
| 443 | ROSA CLI running on bastion host | Required for registering a Red Hat OpenShift Service on AWS cluster into Red Hat Hybrid Cloud Console. |
|
| 443 | ROSA CLI running on bastion host | Used for creating IAM roles and attaching permissions. |
|
| 443 | ROSA CLI running on bastion host | Checks AWS quotas to ensure they satisfy ROSA installation requirements. Alternatively, you can create a VPC endpoint for servicequota service to avoid whitelisting this URL from your firewall. |
|
| 443 | ROSA CLI running on bastion host | Used to get short-lived token to access AWS service. Alternatively, you can create a VPC endpoint for STS service to avoid whitelisting this url from your firewall. |
|
| 443 | ROSA CLI running on bastion host | Used to retrieve EC2 instance related information such as subnets. Alternatively, you can create a VPC endpoint for EC2 service to avoid whitelisting this URL from your firewall. |
2.12.7. Outbound firewall rules from Red Hat Hybrid Cloud Console for clusters with egress zero
| Domain | Port | From/To | Function |
|---|---|---|---|
|
| 443 | Red Hat OpenShift Service on AWS cluster | Used to access the AWS Secure Token Service (STS) regional endpoint to retrieve a short-lived token to access AWS services. Alternatively, you can create a VPC endpoint for STS service to avoid whitelisting this URL from your firewall. |
|
| 443 | Any browser to access Red Hat Hybrid Cloud Console | To manage a Red Hat OpenShift Service on AWS cluster from Hybrid Cloud Console. |
|
| 443 | Any browser to access Red Hat Hybrid Cloud Console |
The Red Hat Hybrid Cloud Console site uses authentication from |
2.13. Tagging your subnets
If you created your own VPC to create a Red Hat OpenShift Service on AWS cluster, you must tag your VPC subnets. Automated service preflight checks verify that these resources are tagged correctly before you can use these resources for a cluster. The following table shows how your resources should be tagged:
| Resource | Key | Value |
|---|---|---|
| Public subnet |
|
|
| Private subnet |
|
|
You must tag at least one private subnet and, if applicable, one public subnet.
Prerequisites
- You have created a VPC.
-
You have installed the
awsCLI.
Procedure
Tag your resources in your terminal by running the following commands:
For public subnets, run:
$ aws ec2 create-tags --resources <public-subnet-id> --region <aws_region> --tags Key=kubernetes.io/role/elb,Value=1For private subnets, run:
$ aws ec2 create-tags --resources <private-subnet-id> --region <aws_region> --tags Key=kubernetes.io/role/internal-elb,Value=1
Verification
Verify that the tag is correctly applied by running the following command:
$ aws ec2 describe-tags --filters "Name=resource-id,Values=<subnet_id>"For example:
TAGS Name <subnet-id> subnet <prefix>-subnet-public1-us-east-1a TAGS kubernetes.io/role/elb <subnet-id> subnet 1
'%20d='M201.5%20305.5c-13.8%200-24.9-11.1-24.9-24.6%200-13.8%2011.1-24.9%2024.9-24.9%2013.6%200%2024.6%2011.1%2024.6%2024.9%200%2013.6-11.1%2024.6-24.6%2024.6zM504%20256c0%20137-111%20248-248%20248S8%20393%208%20256%20119%208%20256%208s248%20111%20248%20248zm-132.3-41.2c-9.4%200-17.7%203.9-23.8%2010-22.4-15.5-52.6-25.5-86.1-26.6l17.4-78.3%2055.4%2012.5c0%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.3%2024.9-24.9s-11.1-24.9-24.9-24.9c-9.7%200-18%205.8-22.1%2013.8l-61.2-13.6c-3-.8-6.1%201.4-6.9%204.4l-19.1%2086.4c-33.2%201.4-63.1%2011.3-85.5%2026.8-6.1-6.4-14.7-10.2-24.1-10.2-34.9%200-46.3%2046.9-14.4%2062.8-1.1%205-1.7%2010.2-1.7%2015.5%200%2052.6%2059.2%2095.2%20132%2095.2%2073.1%200%20132.3-42.6%20132.3-95.2%200-5.3-.6-10.8-1.9-15.8%2031.3-16%2019.8-62.5-14.9-62.5zM302.8%20331c-18.2%2018.2-76.1%2017.9-93.6%200-2.2-2.2-6.1-2.2-8.3%200-2.5%202.5-2.5%206.4%200%208.6%2022.8%2022.8%2087.3%2022.8%20110.2%200%202.5-2.2%202.5-6.1%200-8.6-2.2-2.2-6.1-2.2-8.3%200zm7.7-75c-13.6%200-24.6%2011.1-24.6%2024.9%200%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.1%2024.9-24.6%200-13.8-11-24.9-24.9-24.9z'/%3e%3c/svg%3e){kind=small}