mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-05 12:46:18 +01:00
OSDOCS-10781
This commit is contained in:
Janelle Neczypor
committed by
openshift-cherrypick-robot
openshift-cherrypick-robot
parent
9c99d7a327
commit
4be9c2884a
@@ -22,7 +22,7 @@ include::modules/osd-rhoam.adoc[leveloffset=+1]
|
||||
|
||||
[role="_additional-resources"]
|
||||
.Additional resources
|
||||
* link:https://access.redhat.com/documentation/en-us/red_hat_openshift_api_management[Red Hat OpenShift API Management] documentation
|
||||
* link:https://access.redhat.com/documentation/en-us/red_hat_openshift_api_management[Red{nbsp}Hat OpenShift API Management] documentation
|
||||
|
||||
////
|
||||
include::modules/rosa-rhoda.adoc[leveloffset=+1]
|
||||
@@ -30,7 +30,7 @@ include::modules/rosa-rhoda.adoc[leveloffset=+1]
|
||||
[role="_additional-resources"]
|
||||
.Additional resources
|
||||
|
||||
* link:https://www.redhat.com/en/technologies/cloud-computing/openshift/openshift-database-access[Red Hat OpenShift Database Access] product page
|
||||
* link:https://www.redhat.com/en/technologies/cloud-computing/openshift/openshift-database-access[Red{nbsp}Hat OpenShift Database Access] product page
|
||||
////
|
||||
// This module and additional resource are no longer included in the document due to OSDOCS-5817.
|
||||
|
||||
@@ -38,5 +38,5 @@ include::modules/rosa-rhods.adoc[leveloffset=+1]
|
||||
|
||||
[role="_additional-resources"]
|
||||
.Additional resources
|
||||
* link:https://access.redhat.com/documentation/en-us/red_hat_openshift_data_science/1[Red Hat OpenShift Data Science] documentation
|
||||
* link:https://www.redhat.com/en/technologies/cloud-computing/openshift/openshift-data-science[Red Hat OpenShift Data Science] product page
|
||||
* link:https://access.redhat.com/documentation/en-us/red_hat_openshift_data_science/1[Red{nbsp}Hat OpenShift Data Science] documentation
|
||||
* link:https://www.redhat.com/en/technologies/cloud-computing/openshift/openshift-data-science[Red{nbsp}Hat OpenShift Data Science] product page
|
||||
|
||||
@@ -9,7 +9,7 @@ You can create roles with permissions that adhere to the principal of least priv
|
||||
|
||||
[IMPORTANT]
|
||||
====
|
||||
Although the policies and commands presented in this topic will work in conjunction with one another, you might have other restrictions within your AWS environment that make the policies for these commands insufficient for your specific needs. Red Hat provides these examples as a baseline, assuming no other AWS Identity and Access Management (IAM) restrictions are present.
|
||||
Although the policies and commands presented in this topic will work in conjunction with one another, you might have other restrictions within your AWS environment that make the policies for these commands insufficient for your specific needs. Red{nbsp}Hat provides these examples as a baseline, assuming no other AWS Identity and Access Management (IAM) restrictions are present.
|
||||
====
|
||||
|
||||
[NOTE]
|
||||
|
||||
@@ -194,7 +194,7 @@ stringData:
|
||||
EOF
|
||||
----
|
||||
+
|
||||
. Install the Red Hat AWS Load Balancer Operator:
|
||||
. Install the AWS Load Balancer Operator:
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
|
||||
@@ -58,7 +58,7 @@ $ oc get authentication.config.openshift.io cluster -o json \
|
||||
"https://xxxxx.cloudfront.net/xxxxx"
|
||||
----
|
||||
+
|
||||
If your output is different, do not proceed. See xref:../rosa_install_access_delete_clusters/rosa-sts-creating-a-cluster-quickly.adoc#rosa-sts-creating-a-cluster-quickly[Red Hat documentation on creating an STS cluster] before continuing this process.
|
||||
If your output is different, do not proceed. See xref:../rosa_install_access_delete_clusters/rosa-sts-creating-a-cluster-quickly.adoc#rosa-sts-creating-a-cluster-quickly[Red{nbsp}Hat documentation on creating an STS cluster] before continuing this process.
|
||||
|
||||
. Set the `SecurityContextConstraints` permission to allow the CSI driver to run by running the following command:
|
||||
+
|
||||
|
||||
@@ -13,7 +13,7 @@ toc::[]
|
||||
|
||||
. A Provisioned ROSA cluster
|
||||
+
|
||||
This lab assumes you have access to a successfully provisioned a ROSA cluster. If you have not yet created a ROSA cluster, see xref:../../rosa_getting_started/rosa-quickstart-guide-ui.html#rosa-getting-started-prerequisites_rosa-quickstart-guide-ui[Red Hat OpenShift Service on AWS quickstart guide] for more information.
|
||||
This lab assumes you have access to a successfully provisioned a ROSA cluster. If you have not yet created a ROSA cluster, see xref:../../rosa_getting_started/rosa-quickstart-guide-ui.adoc#rosa-getting-started-prerequisites_rosa-quickstart-guide-ui[Red{nbsp}Hat OpenShift Service on AWS quick start guide] for more information.
|
||||
|
||||
. The OpenShift Command Line Interface (CLI)
|
||||
+
|
||||
|
||||
@@ -19,7 +19,7 @@ toc::[]
|
||||
|
||||
While wildcard certificates provide simplicity by securing all first-level subdomains of a given domain with a single certificate, other use cases can require the use of individual certificates per domain.
|
||||
|
||||
Learn how to use the link:https://docs.openshift.com/container-platform/latest/security/cert_manager_operator/index.html[cert-manager Operator for Red Hat OpenShift] and link:https://letsencrypt.org/[Let's Encrypt] to dynamically issue certificates for routes created using a custom domain.
|
||||
Learn how to use the link:https://docs.openshift.com/container-platform/latest/security/cert_manager_operator/index.html[cert-manager Operator for Red{nbsp}Hat OpenShift] and link:https://letsencrypt.org/[Let's Encrypt] to dynamically issue certificates for routes created using a custom domain.
|
||||
|
||||
[id="cloud-experts-dynamic-certificate-custom-domain-prerequisites"]
|
||||
== Prerequisites
|
||||
@@ -170,10 +170,10 @@ $ oc new-project cert-manager-operator
|
||||
+
|
||||
[IMPORTANT]
|
||||
====
|
||||
Do not attempt to use more than one `cert-manager` Operator in your cluster. If you have a community `cert-manager` Operator installed in your cluster, you must uninstall it before installing the `cert-manager` Operator for Red Hat OpenShift.
|
||||
Do not attempt to use more than one `cert-manager` Operator in your cluster. If you have a community `cert-manager` Operator installed in your cluster, you must uninstall it before installing the `cert-manager` Operator for Red{nbsp}Hat OpenShift.
|
||||
====
|
||||
+
|
||||
. Install the `cert-manager` Operator for Red Hat OpenShift:
|
||||
. Install the `cert-manager` Operator for Red{nbsp}Hat OpenShift:
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
|
||||
@@ -9,9 +9,9 @@ toc::[]
|
||||
//rosaworkshop.io content metadata
|
||||
//Brought into ROSA product docs 2023-11-30
|
||||
|
||||
Administration (admin) privileges are not automatically granted to users that you add to your cluster. If you want to grant admin-level privileges to certain users, you will need to manually grant them to each user. You can grant admin privileges from either the ROSA command line interface (CLI) or the Red Hat OpenShift Cluster Manager web user interface (UI).
|
||||
Administration (admin) privileges are not automatically granted to users that you add to your cluster. If you want to grant admin-level privileges to certain users, you will need to manually grant them to each user. You can grant admin privileges from either the ROSA command line interface (CLI) or the Red{nbsp}Hat OpenShift Cluster Manager web user interface (UI).
|
||||
|
||||
Red Hat offers two types of admin privileges:
|
||||
Red{nbsp}Hat offers two types of admin privileges:
|
||||
|
||||
* `cluster-admin`: `cluster-admin` privileges give the admin user full privileges within the cluster.
|
||||
|
||||
@@ -64,7 +64,7 @@ image:cloud-experts-getting-started-admin-rights-admin-panel.png[]
|
||||
$ oc get all -n openshift-apiserver
|
||||
----
|
||||
|
||||
== Using the Red Hat OpenShift Cluster Manager UI
|
||||
== Using the Red{nbsp}Hat OpenShift Cluster Manager UI
|
||||
|
||||
. Log in to the {cluster-manager-url}.
|
||||
. Select your cluster.
|
||||
|
||||
@@ -78,7 +78,7 @@ $ rosa delete account-roles --prefix <prefix> --mode auto --yes
|
||||
|
||||
== Deleting a ROSA cluster using the UI
|
||||
|
||||
. Log in to the Red Hat OpenShift Cluster Manager, and locate the cluster you want to delete.
|
||||
. Log in to the {cluster-manager-url}, and locate the cluster you want to delete.
|
||||
|
||||
. Click the three dots to the right of the cluster.
|
||||
+
|
||||
|
||||
@@ -9,14 +9,14 @@ toc::[]
|
||||
//rosaworkshop.io content metadata
|
||||
//Brought into ROSA product docs 2023-11-20
|
||||
|
||||
This tutorial outlines the detailed steps to deploy a {product-title} (ROSA) cluster using the Red Hat OpenShift Cluster Manager user interface (UI).
|
||||
This tutorial outlines the detailed steps to deploy a {product-title} (ROSA) cluster using the Red{nbsp}Hat OpenShift Cluster Manager user interface (UI).
|
||||
|
||||
== Deployment workflow
|
||||
The overall deployment workflow follows these steps:
|
||||
|
||||
. Create the account wide roles and policies.
|
||||
. Associate your AWS account with your Red Hat account.
|
||||
.. Create and link the Red Hat OpenShift Cluster Manager role.
|
||||
. Associate your AWS account with your Red{nbsp}Hat account.
|
||||
.. Create and link the Red{nbsp}Hat OpenShift Cluster Manager role.
|
||||
.. Create and link the user role.
|
||||
. Create the cluster.
|
||||
|
||||
@@ -56,7 +56,7 @@ I: To create a cluster with these roles, run the following command:
|
||||
rosa create cluster --sts
|
||||
----
|
||||
|
||||
== Associating your AWS account with your Red Hat account
|
||||
== Associating your AWS account with your Red{nbsp}Hat account
|
||||
This step tells the OpenShift Cluster Manager what AWS account you want to use when deploying ROSA.
|
||||
|
||||
[NOTE]
|
||||
@@ -64,7 +64,7 @@ This step tells the OpenShift Cluster Manager what AWS account you want to use w
|
||||
If you have already associated your AWS accounts, skip this step.
|
||||
====
|
||||
|
||||
. Open the {hybrid-console} by visiting the {cluster-manager-url} and logging in to your Red Hat account.
|
||||
. Open the {hybrid-console} by visiting the {cluster-manager-url} and logging in to your Red{nbsp}Hat account.
|
||||
|
||||
. Click *Create Cluster*.
|
||||
|
||||
@@ -115,7 +115,7 @@ For the purposes of this tutorial, use the *Admin OpenShift Cluster Manager role
|
||||
$ rosa create ocm-role --mode auto --admin --yes
|
||||
----
|
||||
+
|
||||
This command creates the OpenShift Cluster Manager role and associates it with your Red Hat account.
|
||||
This command creates the OpenShift Cluster Manager role and associates it with your Red{nbsp}Hat account.
|
||||
+
|
||||
.Example output
|
||||
+
|
||||
@@ -159,7 +159,7 @@ As defined in the xref:../../../rosa_architecture/rosa-sts-about-iam-resources.a
|
||||
$ rosa list user-role
|
||||
----
|
||||
|
||||
. Run the following command to create the user role and to link it to your Red Hat account:
|
||||
. Run the following command to create the user role and to link it to your Red{nbsp}Hat account:
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
|
||||
@@ -11,7 +11,7 @@ toc::[]
|
||||
|
||||
This tutorial outlines deploying a {hcp-title-first} cluster.
|
||||
|
||||
With {hcp-title}, you can decouple the control plane from the data plane. This is a new deployment model for ROSA in which the control plane is hosted in a Red Hat-owned AWS account. The control plane is no longer hosted in your AWS account, reducing your AWS infrastructure expenses. The control plane is dedicated to a single cluster and is highly available. For more information, see the xref:../../../rosa_hcp/rosa-hcp-sts-creating-a-cluster-quickly.adoc#rosa-hcp-sts-creating-a-cluster-quickly[{hcp-title} documentation].
|
||||
With {hcp-title}, you can decouple the control plane from the data plane. This is a new deployment model for ROSA in which the control plane is hosted in a Red{nbsp}Hat-owned AWS account. The control plane is no longer hosted in your AWS account, reducing your AWS infrastructure expenses. The control plane is dedicated to a single cluster and is highly available. For more information, see the xref:../../../rosa_hcp/rosa-hcp-sts-creating-a-cluster-quickly.adoc#rosa-hcp-sts-creating-a-cluster-quickly[{hcp-title} documentation].
|
||||
|
||||
== Prerequisites
|
||||
|
||||
|
||||
@@ -28,7 +28,7 @@ Run the following command _once_ for each AWS account and y-stream OpenShift ver
|
||||
rosa create account-roles --mode auto --yes
|
||||
----
|
||||
|
||||
== Creating Red Hat OpenShift Cluster Manager roles
|
||||
== Creating Red{nbsp}Hat OpenShift Cluster Manager roles
|
||||
. Create one OpenShift Cluster Manager role for each AWS account by running the following command:
|
||||
+
|
||||
[source,terminal]
|
||||
|
||||
@@ -18,29 +18,29 @@ You can add additional email addresses for communications about your cluster.
|
||||
. Click the *Support* tab.
|
||||
. Click *Add notification contact*, and enter the additional email addresses.
|
||||
|
||||
== Contacting Red Hat for support using the UI
|
||||
== Contacting Red{nbsp}Hat for support using the UI
|
||||
|
||||
. On the {cluster-manager} UI, click the *Support* tab.
|
||||
. Click *Open support case*.
|
||||
|
||||
== Contacting Red Hat for support using the support page
|
||||
== Contacting Red{nbsp}Hat for support using the support page
|
||||
|
||||
. Go to the link:https://support.redhat.com[Red Hat support page].
|
||||
. Go to the link:https://support.redhat.com[Red{nbsp}Hat support page].
|
||||
. Click *Open a new Case*.
|
||||
+
|
||||
image::obtain-support-case.png[]
|
||||
|
||||
. Log in to your Red Hat account.
|
||||
. Log in to your Red{nbsp}Hat account.
|
||||
. Select the reason for contacting support.
|
||||
+
|
||||
image::obtain-support-reason.png[]
|
||||
|
||||
. Select *Red Hat OpenShift Service on AWS*.
|
||||
. Select *Red{nbsp}Hat OpenShift Service on AWS*.
|
||||
|
||||
image::obtain-support-select-rosa.png[]
|
||||
|
||||
. Click *continue*.
|
||||
. Enter a summary of the issue and the details of your request. Upload any files, logs, and screenshots. The more details you provide, the better Red Hat support can help your case.
|
||||
. Enter a summary of the issue and the details of your request. Upload any files, logs, and screenshots. The more details you provide, the better Red{nbsp}Hat support can help your case.
|
||||
+
|
||||
[NOTE]
|
||||
====
|
||||
@@ -54,11 +54,11 @@ image::obtain-support-summary.png[]
|
||||
. Click *Continue*.
|
||||
. Enter the following information about your case:
|
||||
.. *Support level:* Premium
|
||||
.. *Severity:* Review the Red Hat Support Severity Level Definitions to choose the correct one.
|
||||
.. *Severity:* Review the Red{nbsp}Hat Support Severity Level Definitions to choose the correct one.
|
||||
.. *Group:* If this is related to a few other cases you can select the corresponding group.
|
||||
.. *Language*
|
||||
.. *Send notifications:* Add any additional email addresses to keep notified of activity.
|
||||
.. *Red Hat associates:* If you are working with anyone from Red Hat and want to keep them in the loop you can enter their email address here.
|
||||
.. *Red{nbsp}Hat associates:* If you are working with anyone from Red{nbsp}Hat and want to keep them in the loop you can enter their email address here.
|
||||
.. *Alternate Case ID:* If you want to attach your own ID to it you can enter it here.
|
||||
. Click *Continue*.
|
||||
. On the review screen make sure you select the correct cluster ID that you are contacting support about.
|
||||
|
||||
@@ -14,7 +14,7 @@ toc::[]
|
||||
Ways to schedule a cluster upgrade include:
|
||||
|
||||
* *Manually using the command line interface (CLI)*: Start a one-time immediate upgrade or schedule a one-time upgrade for a future date and time.
|
||||
* *Manually using the Red Hat OpenShift Cluster Manager user interface (UI)*: Start a one-time immediate upgrade or schedule a one-time upgrade for a future date and time.
|
||||
* *Manually using the Red{nbsp}Hat OpenShift Cluster Manager user interface (UI)*: Start a one-time immediate upgrade or schedule a one-time upgrade for a future date and time.
|
||||
* *Automated upgrades*: Set an upgrade window for recurring y-stream upgrades whenever a new version is available without needing to manually schedule it. Minor versions have to be manually scheduled.
|
||||
|
||||
For more details about cluster upgrades, run the following command:
|
||||
|
||||
@@ -9,16 +9,16 @@ toc::[]
|
||||
//rosaworkshop.io content metadata
|
||||
//Brought into ROSA product docs 2024-01-18
|
||||
|
||||
Red Hat OpenShift Service on AWS (ROSA) is a fully-managed turnkey application platform that allows you to focus on what matters most, delivering value to your customers by building and deploying applications. Red Hat and AWS SRE experts manage the underlying platform so you do not have to worry about infrastructure management. ROSA provides seamless integration with a wide range of AWS compute, database, analytics, machine learning, networking, mobile, and other services to further accelerate the building and delivering of differentiating experiences to your customers.
|
||||
Red{nbsp}Hat OpenShift Service on AWS (ROSA) is a fully-managed turnkey application platform that allows you to focus on what matters most, delivering value to your customers by building and deploying applications. Red{nbsp}Hat and AWS SRE experts manage the underlying platform so you do not have to worry about infrastructure management. ROSA provides seamless integration with a wide range of AWS compute, database, analytics, machine learning, networking, mobile, and other services to further accelerate the building and delivering of differentiating experiences to your customers.
|
||||
|
||||
ROSA makes use of AWS Security Token Service (STS) to obtain credentials to manage infrastructure in your AWS account. AWS STS is a global web service that creates temporary credentials for IAM users or federated users. ROSA uses this to assign short-term, limited-privilege, security credentials. These credentials are associated with IAM roles that are specific to each component that makes AWS API calls. This method aligns with the principals of least privilege and secure practices in cloud service resource management. The ROSA command line interface (CLI) tool manages the STS credentials that are assigned for unique tasks and takes action on AWS resources as part of OpenShift functionality.
|
||||
//For a detailed explanation, see "ROSA with STS Explained" (add xref when page is migrated).
|
||||
|
||||
== Key features of ROSA
|
||||
* *Native AWS service:* Access and use Red Hat OpenShift on-demand with a self-service onboarding experience through the AWS management console.
|
||||
* *Native AWS service:* Access and use Red{nbsp}Hat OpenShift on-demand with a self-service onboarding experience through the AWS management console.
|
||||
* *Flexible, consumption-based pricing:* Scale to your business needs and pay as you go with flexible pricing and an on-demand hourly or annual billing model.
|
||||
* *Single bill for Red Hat OpenShift and AWS usage:* Customers will receive a single bill from AWS for both Red Hat OpenShift and AWS consumption.
|
||||
* *Fully integrated support experience:* Installation, management, maintenance, and upgrades are performed by Red Hat site reliability engineers (SREs) with joint Red Hat and Amazon support and a 99.95% service-level agreement (SLA).
|
||||
* *Single bill for Red{nbsp}Hat OpenShift and AWS usage:* Customers will receive a single bill from AWS for both Red{nbsp}Hat OpenShift and AWS consumption.
|
||||
* *Fully integrated support experience:* Installation, management, maintenance, and upgrades are performed by Red{nbsp}Hat site reliability engineers (SREs) with joint Red{nbsp}Hat and Amazon support and a 99.95% service-level agreement (SLA).
|
||||
* *AWS service integration:* AWS has a robust portfolio of cloud services, such as compute, storage, networking, database, analytics, and machine learning. All of these services are directly accessible through ROSA. This makes it easier to build, operate, and scale globally and on-demand through a familiar management interface.
|
||||
* *Maximum Availability:* Deploy clusters across multiple availability zones in supported regions to maximize availability and maintain high availability for your most demanding mission-critical applications and data.
|
||||
* *Cluster node scaling:* Easily add or remove compute nodes to match resource demand.
|
||||
@@ -29,7 +29,7 @@ ROSA makes use of AWS Security Token Service (STS) to obtain credentials to mana
|
||||
In ROSA, everything you need to deploy and manage containers is bundled, including container management, Operators, networking, load balancing, service mesh, CI/CD, firewall, monitoring, registry, authentication, and authorization capabilities. These components are tested together for unified operations as a complete platform. Automated cluster operations, including over-the-air platform upgrades, further enhance your Kubernetes experience.
|
||||
|
||||
== Basic responsibilities
|
||||
In general, cluster deployment and upkeep is Red Hat's or AWS's responsibility, while applications, users, and data is the customer's responsibility. For a more detailed breakdown of responsibilities, see the xref:../../rosa_architecture/rosa_policy_service_definition/rosa-policy-responsibility-matrix.adoc#rosa-policy-responsibility-matrix[responsibility matrix].
|
||||
In general, cluster deployment and upkeep is Red{nbsp}Hat's or AWS's responsibility, while applications, users, and data is the customer's responsibility. For a more detailed breakdown of responsibilities, see the xref:../../rosa_architecture/rosa_policy_service_definition/rosa-policy-responsibility-matrix.adoc#rosa-policy-responsibility-matrix[responsibility matrix].
|
||||
|
||||
== Roadmap and feature requests
|
||||
Visit the link:https://github.com/openshift-cs/managed-openshift/projects/2[ROSA roadmap] to stay up-to-date with the status of features currently in development. Open a new issue if you have any suggestions for the product team.
|
||||
@@ -48,7 +48,7 @@ All nodes in a ROSA cluster must be located in the same AWS region. For clusters
|
||||
For a ROSA cluster, the minimum is 2 worker nodes for single availability zone and 3 worker nodes for multiple availability zones.
|
||||
|
||||
=== Underlying node operating system
|
||||
As with all OpenShift v4.x offerings, the control plane, infra and worker nodes run Red Hat Enterprise Linux CoreOS (RHCOS).
|
||||
As with all OpenShift v4.x offerings, the control plane, infra and worker nodes run Red{nbsp}Hat Enterprise Linux CoreOS (RHCOS).
|
||||
|
||||
=== Node hibernation or shut-down
|
||||
At this time, ROSA does not have a hibernation or shut-down feature for nodes. The shutdown and hibernation feature is an OpenShift platform feature that is not yet mature enough for widespread cloud services use.
|
||||
@@ -75,13 +75,13 @@ Customers can upgrade to the newest version of OpenShift and use the features fr
|
||||
== Support
|
||||
You can open a ticket directly from the {cluster-manager-url}. See the xref:../../support/getting-support.adoc#getting-support[ROSA support documentation] for more details about obtaining support.
|
||||
|
||||
You can also visit the link:http://access.redhat.com/[Red Hat Customer Portal] to search or browse through the Red Hat knowledge base of articles and solutions relating to Red Hat products or submit a support case to Red Hat Support.
|
||||
You can also visit the link:http://access.redhat.com/[Red{nbsp}Hat Customer Portal] to search or browse through the Red{nbsp}Hat knowledge base of articles and solutions relating to Red{nbsp}Hat products or submit a support case to Red{nbsp}Hat Support.
|
||||
|
||||
=== Limited support
|
||||
If a ROSA cluster is not upgraded before the "end of life" date, the cluster continues to operate in a limited support status. The SLA for that cluster will no longer be applicable, but you can still get support for that cluster. See the xref:../../rosa_architecture/rosa_policy_service_definition/rosa-life-cycle.adoc#rosa-life-cycle[limited support status] documentation for more details.
|
||||
|
||||
.Additional support resources
|
||||
* link:https://access.redhat.com/[Red Hat Support]
|
||||
* link:https://access.redhat.com/[Red{nbsp}Hat Support]
|
||||
* link:https://aws.amazon.com/premiumsupport/[AWS Support]
|
||||
+
|
||||
AWS support customers must have a valid AWS support contract
|
||||
@@ -90,7 +90,7 @@ AWS support customers must have a valid AWS support contract
|
||||
Refer to the xref:../../rosa_architecture/rosa_policy_service_definition/rosa-service-definition.adoc#rosa-sdpolicy-sla_rosa-service-definition[ROSA SLA] page for details.
|
||||
|
||||
== Notifications and communication
|
||||
Red Hat will provide notifications regarding new Red Hat and AWS features, updates, and scheduled maintenance through email and the {hybrid-console-second} service log.
|
||||
Red{nbsp}Hat will provide notifications regarding new Red{nbsp}Hat and AWS features, updates, and scheduled maintenance through email and the {hybrid-console-second} service log.
|
||||
|
||||
== Open Service Broker for AWS (OBSA)
|
||||
You can use OSBA with ROSA. However, the preferred method is the more recent link:https://github.com/aws-controllers-k8s/community[AWS Controller for Kubernetes]. See link:https://aws.amazon.com/partners/servicebroker/[Open Service Broker for AWS] for more information on OSBA.
|
||||
@@ -135,16 +135,16 @@ Currently, the ROSA CLI does not accept multi-region KMS keys for EBS encryption
|
||||
ROSA uses several different cloud services such as virtual machines, storage, and load balancers. You can see a defined list in the xref:../../rosa_planning/rosa-sts-aws-prereqs.adoc#rosa-aws-policy-provisioned_rosa-sts-aws-prereqs[AWS prerequisites].
|
||||
|
||||
== Credential methods
|
||||
There are two credential methods to grant Red Hat the permissions needed to perform the required actions in your AWS account: AWS with STS or an IAM user with admin permissions. AWS with STS is the preferred method, and the IAM user method will eventually be deprecated. AWS with STS better aligns with the principles of least privilege and secure practices in cloud service resource management.
|
||||
There are two credential methods to grant Red{nbsp}Hat the permissions needed to perform the required actions in your AWS account: AWS with STS or an IAM user with admin permissions. AWS with STS is the preferred method, and the IAM user method will eventually be deprecated. AWS with STS better aligns with the principles of least privilege and secure practices in cloud service resource management.
|
||||
//See the section [ROSA with STS Explained] section for a detailed explanation.
|
||||
|
||||
== Prerequisite permission or failure errors
|
||||
Check for a newer version of the ROSA CLI. Every release of the ROSA CLI is located in two places: link:https://github.com/openshift/rosa/releases[Github] and the link:https://www.openshift.com/products/rosa/download[Red Hat signed binary releases].
|
||||
Check for a newer version of the ROSA CLI. Every release of the ROSA CLI is located in two places: link:https://github.com/openshift/rosa/releases[Github] and the link:https://www.openshift.com/products/rosa/download[Red{nbsp}Hat signed binary releases].
|
||||
|
||||
== Storage
|
||||
Refer to the xref:../../rosa_architecture/rosa_policy_service_definition/rosa-service-definition.adoc#rosa-sdpolicy-storage_rosa-service-definition[storage] section of the service definition.
|
||||
|
||||
OpenShift includes the CSI driver for AWS EFS. For more information, see xref:../../storage/container_storage_interface/osd-persistent-storage-aws-efs-csi.adoc#osd-persistent-storage-aws-efs-csi[Setting up AWS EFS for Red Hat OpenShift Service on AWS].
|
||||
OpenShift includes the CSI driver for AWS EFS. For more information, see xref:../../storage/container_storage_interface/osd-persistent-storage-aws-efs-csi.adoc#osd-persistent-storage-aws-efs-csi[Setting up AWS EFS for Red{nbsp}Hat OpenShift Service on AWS].
|
||||
|
||||
== Using a VPC
|
||||
At installation you can select to deploy to an existing VPC or bring your own VPC. You can then select the required subnets and provide a valid CIDR range that encompasses the subnets for the installation program when using those subnets.
|
||||
@@ -176,11 +176,11 @@ ROSA STS clusters do not have backups. Users must have their own backup policies
|
||||
You can define a custom domain for your applications. See xref:../../applications/deployments/rosa-config-custom-domains-applications.adoc#rosa-config-custom-domains-applications[Configuring custom domains for applications] for more information.
|
||||
|
||||
== ROSA domain certificates
|
||||
Red Hat infrastructure (Hive) manages certificate rotation for default application ingress.
|
||||
Red{nbsp}Hat infrastructure (Hive) manages certificate rotation for default application ingress.
|
||||
|
||||
== Disconnected environments
|
||||
ROSA does not support an air-gapped, disconnected environment. The ROSA cluster must have egress to the internet to access our registry, S3, and send metrics. The service requires a number of egress endpoints.
|
||||
Ingress can be limited to a PrivateLink for Red Hat SREs and a VPN for customer access.
|
||||
Ingress can be limited to a PrivateLink for Red{nbsp}Hat SREs and a VPN for customer access.
|
||||
|
||||
//== Creating your first ROSA cluster
|
||||
|
||||
@@ -190,9 +190,9 @@ Ingress can be limited to a PrivateLink for Red Hat SREs and a VPN for customer
|
||||
.Additional Resources
|
||||
|
||||
* ROSA product pages:
|
||||
** link:https://www.openshift.com/products/amazon-openshift[Red Hat product page]
|
||||
** link:https://www.openshift.com/products/amazon-openshift[Red{nbsp}Hat product page]
|
||||
** link:https://aws.amazon.com/rosa/[AWS product page]
|
||||
** link:https://access.redhat.com/products/red-hat-openshift-service-aws[Red Hat customer portal]
|
||||
** link:https://access.redhat.com/products/red-hat-openshift-service-aws[Red{nbsp}Hat Customer Portal]
|
||||
* ROSA specific resources
|
||||
** link:https://docs.aws.amazon.com/ROSA/latest/userguide/getting-started.html[AWS ROSA getting started guide]
|
||||
** xref:../../welcome/index.adoc#welcome-index[ROSA documentation]
|
||||
@@ -205,4 +205,4 @@ Ingress can be limited to a PrivateLink for Red Hat SREs and a VPN for customer
|
||||
** link:https://red.ht/rosa-roadmap[ROSA roadmap]
|
||||
* link:https://learn.openshift.com[Learn about OpenShift]
|
||||
* {cluster-manager-url}
|
||||
* link:https://support.redhat.com[Red Hat Support]
|
||||
* link:https://support.redhat.com[Red{nbsp}Hat Support]
|
||||
|
||||
@@ -27,7 +27,7 @@ This tutorial will:
|
||||
|
||||
[id="different-credential-methods-rosa"]
|
||||
== Different credential methods to deploy ROSA
|
||||
As part of ROSA, Red Hat manages infrastructure resources in your AWS account and must be granted the necessary permissions. There are currently two supported methods for granting those permissions:
|
||||
As part of ROSA, Red{nbsp}Hat manages infrastructure resources in your AWS account and must be granted the necessary permissions. There are currently two supported methods for granting those permissions:
|
||||
|
||||
* Using static IAM user credentials with an `AdministratorAccess` policy
|
||||
+
|
||||
@@ -120,7 +120,7 @@ The roles and policies can be created automatically by the ROSA CLI, or they can
|
||||
|
||||
[id="sts-process"]
|
||||
== ROSA with STS workflow
|
||||
The user creates the required account-wide roles and account-wide policies. For more information, see the components section in this tutorial. During role creation, a trust policy, known as a cross-account trust policy, is created which allows a Red Hat-owned role to assume the roles. Trust policies are also created for the EC2 service, which allows workloads on EC2 instances to assume roles and obtain credentials. The user can then assign a corresponding permissions policy to each role.
|
||||
The user creates the required account-wide roles and account-wide policies. For more information, see the components section in this tutorial. During role creation, a trust policy, known as a cross-account trust policy, is created which allows a Red{nbsp}Hat-owned role to assume the roles. Trust policies are also created for the EC2 service, which allows workloads on EC2 instances to assume roles and obtain credentials. The user can then assign a corresponding permissions policy to each role.
|
||||
|
||||
After the account-wide roles and policies are created, the user can create a cluster. Once cluster creation is initiated, the Operator roles are created so that cluster Operators can make AWS API calls. These roles are then assigned to the corresponding permission policies that were created earlier and a trust policy with an OIDC provider. The Operator roles differ from the account-wide roles in that they ultimately represent the pods that need access to AWS resources. Because a user cannot attach IAM roles to pods, they must create a trust policy with an OIDC provider so that the Operator, and therefore the pods, can access the roles they need.
|
||||
|
||||
@@ -128,7 +128,7 @@ Once the user assigns the roles to the corresponding policy permissions, the fin
|
||||
|
||||
image::cloud-experts-sts-explained_creation_flow.png[]
|
||||
|
||||
When a new role is needed, the workload currently using the Red Hat role will assume the role in the AWS account, obtain temporary credentials from AWS STS, and begin performing the actions using API calls within the customer's AWS account as permitted by the assumed role's permissions policy. The credentials are temporary and have a maximum duration of one hour.
|
||||
When a new role is needed, the workload currently using the Red{nbsp}Hat role will assume the role in the AWS account, obtain temporary credentials from AWS STS, and begin performing the actions using API calls within the customer's AWS account as permitted by the assumed role's permissions policy. The credentials are temporary and have a maximum duration of one hour.
|
||||
|
||||
image::cloud-experts-sts-explained_highlevel.png[]
|
||||
|
||||
@@ -144,9 +144,9 @@ image::cloud-experts-sts-explained_oidc_op_roles.png[]
|
||||
== ROSA with STS use cases
|
||||
|
||||
.Creating nodes at cluster install
|
||||
The Red Hat installation program uses the `RH-Managed-OpenShift-Installer` role and a trust policy to assume the `Managed-OpenShift-Installer-Role` role in the customer's account. This process returns temporary credentials from AWS STS. The installation program begins making the required API calls with the temporary credentials just received from STS. The installation program creates the required infrastructure in AWS. The credentials expire within an hour and the installation program no longer has access to the customer's account.
|
||||
The Red{nbsp}Hat installation program uses the `RH-Managed-OpenShift-Installer` role and a trust policy to assume the `Managed-OpenShift-Installer-Role` role in the customer's account. This process returns temporary credentials from AWS STS. The installation program begins making the required API calls with the temporary credentials just received from STS. The installation program creates the required infrastructure in AWS. The credentials expire within an hour and the installation program no longer has access to the customer's account.
|
||||
|
||||
The same process also applies for support cases. In support cases, a Red Hat site reliability engineer (SRE) replaces the installation program.
|
||||
The same process also applies for support cases. In support cases, a Red{nbsp}Hat site reliability engineer (SRE) replaces the installation program.
|
||||
|
||||
.Scaling the cluster
|
||||
The `machine-api-operator` uses link:https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html[AssumeRoleWithWebIdentity] to assume the `machine-api-aws-cloud-credentials` role. This launches the sequence for the cluster Operators to receive the credentials. The `machine-api-operator` role can now make the relevant API calls to add more EC2 instances to the cluster.
|
||||
@@ -24,9 +24,9 @@ If you have received a private offer for the product, make sure to proceed accor
|
||||
|
||||
== Prerequisites
|
||||
|
||||
* Make sure to log into the Red Hat account that you plan to associate with the AWS account where you have activated {hcp-title} in previous steps.
|
||||
* Only a single AWS account that will be used for service billing can be associated with a Red Hat account. Typically an organizational AWS account that has other AWS accounts, such as developer accounts, linked would be the one that is to be billed, rather than individual AWS end user accounts.
|
||||
* Red Hat accounts belonging to the same Red Hat organization will be linked with the same AWS account. Therefore, you can manage who has access to creating {hcp-title} clusters on the Red Hat organization account level.
|
||||
* Make sure to log in to the Red{nbsp}Hat account that you plan to associate with the AWS account where you have activated {hcp-title} in previous steps.
|
||||
* Only a single AWS account that will be used for service billing can be associated with a Red{nbsp}Hat account. Typically an organizational AWS account that has other AWS accounts, such as developer accounts, linked would be the one that is to be billed, rather than individual AWS end user accounts.
|
||||
* Red{nbsp}Hat accounts belonging to the same Red{nbsp}Hat organization will be linked with the same AWS account. Therefore, you can manage who has access to creating {hcp-title} clusters on the Red{nbsp}Hat organization account level.
|
||||
|
||||
== Subscription enablement and AWS account setup
|
||||
|
||||
@@ -36,7 +36,7 @@ image::rosa-get-started.png[]
|
||||
+
|
||||
If you have activated ROSA before but did not complete the process, you can click the button and complete the account linking as described in the following steps.
|
||||
|
||||
. Confirm that you want your contact information to be shared with Red Hat and enable the service:
|
||||
. Confirm that you want your contact information to be shared with Red{nbsp}Hat and enable the service:
|
||||
+
|
||||
image::rosa-enable-2.png[]
|
||||
+
|
||||
@@ -58,31 +58,31 @@ image::rosa-prereq-5.png[]
|
||||
+
|
||||
The ELB service-linked role is created for you automatically. You can click any of the small *Info* blue links to get contextual help and resources.
|
||||
|
||||
== AWS and Red Hat account and subscription linking
|
||||
== AWS and Red{nbsp}Hat account and subscription linking
|
||||
|
||||
. Click the orange *Continue to Red Hat* button to proceed with account linking:
|
||||
. Click the orange *Continue to Red{nbsp}Hat* button to proceed with account linking:
|
||||
+
|
||||
image::rosa-continue-rh-6.png[]
|
||||
|
||||
. If you are not already logged in to your Red Hat account in your current browser's session, you will be asked to log in to your account:
|
||||
. If you are not already logged in to your Red{nbsp}Hat account in your current browser's session, you will be asked to log in to your account:
|
||||
+
|
||||
image::rosa-login-rh-account-7.png[]
|
||||
+
|
||||
* You can also register for a new Red Hat account or reset your password on this page.
|
||||
* Make sure to log into the Red Hat account that you plan to associate with the AWS account where you have activated {hcp-title} in previous steps.
|
||||
* Only a single AWS account that will be used for service billing can be associated with a Red Hat account. Typically an organizational AWS account that has other AWS accounts, such as developer accounts, linked would be the one that is to be billed, rather than individual AWS end user accounts.
|
||||
* Red Hat accounts belonging to the same Red Hat organization will be linked with the same AWS account. Therefore, you can manage who has access to creating {hcp-title} clusters on the Red Hat organization account level.
|
||||
* You can also register for a new Red{nbsp}Hat account or reset your password on this page.
|
||||
* Make sure to log in to the Red{nbsp}Hat account that you plan to associate with the AWS account where you have activated {hcp-title} in previous steps.
|
||||
* Only a single AWS account that will be used for service billing can be associated with a Red{nbsp}Hat account. Typically an organizational AWS account that has other AWS accounts, such as developer accounts, linked would be the one that is to be billed, rather than individual AWS end user accounts.
|
||||
* Red{nbsp}Hat accounts belonging to the same Red{nbsp}Hat organization will be linked with the same AWS account. Therefore, you can manage who has access to creating {hcp-title} clusters on the Red{nbsp}Hat organization account level.
|
||||
|
||||
. Complete the Red Hat account linking after reviewing the terms and conditions:
|
||||
. Complete the Red{nbsp}Hat account linking after reviewing the terms and conditions:
|
||||
+
|
||||
[NOTE]
|
||||
====
|
||||
This step is available only if the logged-in Red Hat account, or the Red Hat organization managing the Red Hat account, was not linked to an AWS account before.
|
||||
This step is available only if the logged-in Red{nbsp}Hat account, or the Red{nbsp}Hat organization managing the Red{nbsp}Hat account, was not linked to an AWS account before.
|
||||
====
|
||||
+
|
||||
image::rosa-rh-account-connection-8.png[]
|
||||
+
|
||||
Both the Red Hat and AWS account numbers are shown on this screen.
|
||||
Both the Red{nbsp}Hat and AWS account numbers are shown on this screen.
|
||||
|
||||
. Click the *Connect accounts* button if you agree with the service terms.
|
||||
+
|
||||
@@ -105,7 +105,7 @@ image::rosa-cluster-create-10.png[]
|
||||
image::rosa-deploy-11.png[]
|
||||
+
|
||||
* It is possible that these steps will be performed on a different machine than where the service enablement and account linking were completed.
|
||||
* As mentioned previously, any Red Hat account belonging to the Red Hat organization that was linked with the AWS account that activated the ROSA service will have access to creating a cluster and will be able to select the billing AWS account that was linked under this Red Hat organization previously.
|
||||
* As mentioned previously, any Red{nbsp}Hat account belonging to the Red{nbsp}Hat organization that was linked with the AWS account that activated the ROSA service will have access to creating a cluster and will be able to select the billing AWS account that was linked under this Red{nbsp}Hat organization previously.
|
||||
+
|
||||
The last section of this page shows cluster deployment options, either using the `rosa` CLI or through the web console:
|
||||
+
|
||||
@@ -153,7 +153,7 @@ image::rosa-create-cli-16.png[]
|
||||
+
|
||||
image::rosa-create-cli-billing-17.png[]
|
||||
+
|
||||
* Only AWS accounts that were linked to the Red Hat organization that is currently used will be shown.
|
||||
* Only AWS accounts that were linked to the Red{nbsp}Hat organization that is currently used will be shown.
|
||||
* The specified AWS account will be charged for using the ROSA service, regardless of whether the infrastructure AWS account is linked to it in the same AWS organization.
|
||||
* You can see an indicator of whether the ROSA contract is enabled for a given AWS billing account or not.
|
||||
* To select an AWS account that does not have the contract enabled, refer to the first few steps in this tutorial to enable the contract and allow the service charging, which is required for a successful cluster deployment.
|
||||
@@ -186,7 +186,7 @@ image::rosa-ui-account-21.png[]
|
||||
+
|
||||
image::rosa-ui-billing-22.png[]
|
||||
+
|
||||
* Only AWS accounts that were linked to the Red Hat organization that is currently used will be shown.
|
||||
* Only AWS accounts that were linked to the Red{nbsp}Hat organization that is currently used will be shown.
|
||||
* The specified AWS account will be charged for using the ROSA service, regardless of whether the infrastructure AWS account is linked to it in the same AWS organization.
|
||||
* You can see an indicator whether the ROSA contract is enabled for a given AWS billing account or not.
|
||||
* In case you would like to use an AWS account that does not have a contract enabled yet, you can either use the _Connect ROSA to a new AWS billing account_ to reach the ROSA AWS console page, where you can activate it after logging in using the respective AWS account by following steps described earlier in this tutorial, or ask the administrator of the AWS account to do that for you.
|
||||
|
||||
@@ -188,7 +188,7 @@ stringData:
|
||||
EOF
|
||||
----
|
||||
+
|
||||
. Install the Red Hat AWS Load Balancer Operator:
|
||||
. Install the AWS Load Balancer Operator:
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
@@ -439,5 +439,5 @@ The expected result is a `403 Forbidden` error, which means the AWS WAF is prote
|
||||
[id="additional-resources_{context}"]
|
||||
== Additional resources
|
||||
|
||||
* link:https://docs.openshift.com/rosa/applications/deployments/osd-config-custom-domains-applications.html[Custom domains for applications] in the Red Hat documentation
|
||||
* link:https://docs.openshift.com/rosa/applications/deployments/osd-config-custom-domains-applications.html[Custom domains for applications] in the Red{nbsp}Hat documentation
|
||||
* link:https://youtu.be/-HorEsl2ho4[Adding Extra Security with AWS WAF, CloudFront and ROSA | Amazon Web Services] on YouTube
|
||||
@@ -355,5 +355,5 @@ The expected result is a `403 Forbidden` error, which means the AWS WAF is prote
|
||||
[id="additional-resources_{context}"]
|
||||
== Additional resources
|
||||
|
||||
* link:https://docs.openshift.com/rosa/applications/deployments/rosa-config-custom-domains-applications.html[Custom domains for applications] in the Red Hat documentation
|
||||
* link:https://docs.openshift.com/rosa/applications/deployments/rosa-config-custom-domains-applications.html[Custom domains for applications] in the Red{nbsp}Hat documentation
|
||||
* link:https://youtu.be/-HorEsl2ho4[Adding Extra Security with AWS WAF, CloudFront and ROSA | Amazon Web Services] on YouTube
|
||||
@@ -4,6 +4,6 @@
|
||||
include::_attributes/attributes-openshift-dedicated.adoc[]
|
||||
:context: tutorials-overview
|
||||
|
||||
Step-by-step tutorials from Red Hat experts to help you get the most out of your Managed OpenShift cluster.
|
||||
Step-by-step tutorials from Red{nbsp}Hat experts to help you get the most out of your Managed OpenShift cluster.
|
||||
|
||||
In an effort to make this Cloud Expert tutorial content available quickly, it may not yet be tested on every supported configuration.
|
||||
|
||||
@@ -52,7 +52,7 @@ The credentials defined in this step are not visible after you select *Add* in t
|
||||
ifdef::osd-distro[]
|
||||
.. Select a *Group.*
|
||||
** If you are installing {product-title} using the Customer Cloud Subscription (CCS) infrastructure type, choose either the `dedicated-admins` or `cluster-admins` group. Users in the `dedicated-admins` group have standard administrative privileges for {product-title}. Users in the `cluster-admins` group have full administrative access to the cluster.
|
||||
** If you are installing {product-title} using the Red Hat cloud account infrastructure type, the `dedicated-admins` group is automatically selected.
|
||||
** If you are installing {product-title} using the Red{nbsp}Hat cloud account infrastructure type, the `dedicated-admins` group is automatically selected.
|
||||
endif::osd-distro[]
|
||||
ifdef::rosa-distro[]
|
||||
.. Select a *Group*. Users in the `dedicated-admins` group have standard administrative privileges for {product-title}. Users in the `cluster-admins` group have full administrative access to the cluster.
|
||||
|
||||
@@ -53,7 +53,7 @@ link:http://openid.net/specs/openid-connect-core-1_0.html#StandardClaims[OpenID
|
||||
for more information.
|
||||
|
||||
.Prerequisites
|
||||
* Before you configure OpenID Connect, check the installation prerequisites for any Red Hat product or service you want to use with your {product-title} cluster.
|
||||
* Before you configure OpenID Connect, check the installation prerequisites for any Red{nbsp}Hat product or service you want to use with your {product-title} cluster.
|
||||
|
||||
.Procedure
|
||||
|
||||
|
||||
@@ -11,7 +11,7 @@ You can create additional machine pools for your {product-title} (ROSA) cluster
|
||||
.Prerequisites
|
||||
|
||||
* You installed and configured the latest {product-title} (ROSA) CLI, `rosa`, on your workstation.
|
||||
* You logged in to your Red Hat account using the ROSA CLI (`rosa`).
|
||||
* You logged in to your Red{nbsp}Hat account using the ROSA CLI (`rosa`).
|
||||
* You created a ROSA cluster.
|
||||
|
||||
.Procedure
|
||||
@@ -66,7 +66,7 @@ For fault-tolerant worker machine pools, choosing a Multi-AZ machine pool distri
|
||||
* A Multi-AZ machine pool with three availability zones can have a machine count in multiples of 3 only, such as 3, 6, 9, and so on.
|
||||
* A Single-AZ machine pool with one availability zone can have a machine count in multiples of 1, such as 1,2,3,4 and so on.
|
||||
====
|
||||
<10> Optional: For machine pools in clusters that do not have Red Hat managed VPCs, you can select additional custom security groups to use in your machine pools. You must have already created the security groups and associated them with the VPC that you selected for this cluster. You cannot add or edit security groups after you create the machine pool. For more information, see the requirements for security groups in the "Additional resources" section.
|
||||
<10> Optional: For machine pools in clusters that do not have Red{nbsp}Hat managed VPCs, you can select additional custom security groups to use in your machine pools. You must have already created the security groups and associated them with the VPC that you selected for this cluster. You cannot add or edit security groups after you create the machine pool. For more information, see the requirements for security groups in the "Additional resources" section.
|
||||
+
|
||||
[IMPORTANT]
|
||||
====
|
||||
|
||||
@@ -30,7 +30,7 @@ endif::openshift-rosa[]
|
||||
ifndef::openshift-rosa[]
|
||||
{product-title}
|
||||
endif::[]
|
||||
subscriptions, resource quotas and deployment scenario. For more information, contact your sales representative or Red Hat support.
|
||||
subscriptions, resource quotas and deployment scenario. For more information, contact your sales representative or Red{nbsp}Hat support.
|
||||
====
|
||||
endif::openshift-rosa[]
|
||||
|
||||
@@ -64,7 +64,7 @@ ifdef::openshift-dedicated[]
|
||||
+
|
||||
[NOTE]
|
||||
====
|
||||
The *Enable autoscaling* option is only available for {product-title} if you have the `capability.cluster.autoscale_clusters` subscription. For more information, contact your sales representative or Red Hat support.
|
||||
The *Enable autoscaling* option is only available for {product-title} if you have the `capability.cluster.autoscale_clusters` subscription. For more information, contact your sales representative or Red{nbsp}Hat support.
|
||||
====
|
||||
endif::openshift-dedicated[]
|
||||
.. Set the minimum and maximum node count limits for autoscaling. The cluster autoscaler does not reduce or increase the machine pool node count beyond the limits that you specify.
|
||||
|
||||
@@ -5,7 +5,7 @@
|
||||
:_mod-docs-content-type: PROCEDURE
|
||||
[id="deleting-machine-pools-cli{context}"]
|
||||
= Deleting a machine pool using the ROSA CLI
|
||||
You can delete a machine pool for your Red Hat OpenShift Service on AWS (ROSA) cluster by using the ROSA CLI.
|
||||
You can delete a machine pool for your Red{nbsp}Hat OpenShift Service on AWS (ROSA) cluster by using the ROSA CLI.
|
||||
|
||||
[NOTE]
|
||||
====
|
||||
|
||||
@@ -13,7 +13,7 @@ ifdef::openshift-rosa[]
|
||||
= Deleting a machine pool using OpenShift Cluster Manager
|
||||
endif::openshift-rosa[]
|
||||
|
||||
You can delete a machine pool for your Red Hat OpenShift Service on AWS (ROSA) cluster by using OpenShift Cluster Manager.
|
||||
You can delete a machine pool for your Red{nbsp}Hat OpenShift Service on AWS (ROSA) cluster by using OpenShift Cluster Manager.
|
||||
|
||||
.Prerequisites
|
||||
|
||||
|
||||
@@ -34,7 +34,7 @@ endif::[]
|
||||
|
||||
. Click *Open console*.
|
||||
|
||||
. Your cluster console opens in a new browser window. Login to your Red Hat account with your configured identity provider credentials.
|
||||
. Your cluster console opens in a new browser window. Log in to your Red{nbsp}Hat account with your configured identity provider credentials.
|
||||
|
||||
. In the *Administrator* perspective, select *Home* -> *Projects* -> *Create Project*.
|
||||
|
||||
|
||||
@@ -6,5 +6,5 @@
|
||||
[id="rosa-install-policy_{context}"]
|
||||
= Installation policy
|
||||
|
||||
While Red Hat recommends installation of the latest support release, {product-title} supports
|
||||
While Red{nbsp}Hat recommends installation of the latest support release, {product-title} supports
|
||||
installation of any supported release as covered by the preceding policy.
|
||||
|
||||
@@ -11,17 +11,17 @@ endif::[]
|
||||
[id="rosa-limited-support_{context}"]
|
||||
= Limited support status
|
||||
|
||||
When a cluster transitions to a _Limited Support_ status, Red Hat no longer proactively monitors the cluster, the SLA is no longer applicable, and credits requested against the SLA are denied. It does not mean that you no longer have product support. In some cases, the cluster can return to a fully-supported status if you remediate the violating factors. However, in other cases, you might have to delete and recreate the cluster.
|
||||
When a cluster transitions to a _Limited Support_ status, Red{nbsp}Hat no longer proactively monitors the cluster, the SLA is no longer applicable, and credits requested against the SLA are denied. It does not mean that you no longer have product support. In some cases, the cluster can return to a fully-supported status if you remediate the violating factors. However, in other cases, you might have to delete and recreate the cluster.
|
||||
|
||||
A cluster might transition to a Limited Support status for many reasons, including the following scenarios:
|
||||
|
||||
ifndef::rosa-with-hcp[]
|
||||
If you do not upgrade a cluster to a supported version before the end-of-life date:: Red Hat does not make any runtime or SLA guarantees for versions after their end-of-life date. To receive continued support, upgrade the cluster to a supported version prior to the end-of-life date. If you do not upgrade the cluster prior to the end-of-life date, the cluster transitions to a Limited Support status until it is upgraded to a supported version.
|
||||
If you do not upgrade a cluster to a supported version before the end-of-life date:: Red{nbsp}Hat does not make any runtime or SLA guarantees for versions after their end-of-life date. To receive continued support, upgrade the cluster to a supported version before the end-of-life date. If you do not upgrade the cluster before the end-of-life date, the cluster transitions to a Limited Support status until it is upgraded to a supported version.
|
||||
+
|
||||
Red Hat provides commercially reasonable support to upgrade from an unsupported version to a supported version. However, if a supported upgrade path is no longer available, you might have to create a new cluster and migrate your workloads.
|
||||
Red{nbsp}Hat provides commercially reasonable support to upgrade from an unsupported version to a supported version. However, if a supported upgrade path is no longer available, you might have to create a new cluster and migrate your workloads.
|
||||
endif::rosa-with-hcp[]
|
||||
|
||||
If you remove or replace any native {product-title} components or any other component that is installed and managed by Red Hat:: If cluster administrator permissions were used, Red Hat is not responsible for any of your or your authorized users’ actions, including those that affect infrastructure services, service availability, or data loss. If Red Hat detects any such actions, the cluster might transition to a Limited Support status. Red Hat notifies you of the status change and you should either revert the action or create a support case to explore remediation steps that might require you to delete and recreate the cluster.
|
||||
If you remove or replace any native {product-title} components or any other component that is installed and managed by Red{nbsp}Hat:: If cluster administrator permissions were used, Red{nbsp}Hat is not responsible for any of your or your authorized users’ actions, including those that affect infrastructure services, service availability, or data loss. If Red{nbsp}Hat detects any such actions, the cluster might transition to a Limited Support status. Red{nbsp}Hat notifies you of the status change and you should either revert the action or create a support case to explore remediation steps that might require you to delete and recreate the cluster.
|
||||
|
||||
If you have questions about a specific action that might cause a cluster to transition to a Limited Support status or need further assistance, open a support ticket.
|
||||
|
||||
|
||||
@@ -11,16 +11,16 @@ endif::[]
|
||||
[id="rosa-mandatory-upgrades_{context}"]
|
||||
= Mandatory upgrades
|
||||
|
||||
If a critical or important CVE, or other bug identified by Red Hat, significantly impacts the security or stability of the cluster, the customer must upgrade to the next supported patch release within two link:https://access.redhat.com/articles/2623321[business days].
|
||||
If a critical or important CVE, or other bug identified by Red{nbsp}Hat, significantly impacts the security or stability of the cluster, the customer must upgrade to the next supported patch release within two link:https://access.redhat.com/articles/2623321[business days].
|
||||
|
||||
In extreme circumstances and based on Red Hat's assessment of the CVE criticality to the environment, Red Hat will notify customers that they have two link:https://access.redhat.com/articles/2623321[business days] to schedule or manually update their cluster to the latest, secure patch release. In the case that an update is not performed after two link:https://access.redhat.com/articles/2623321[business days], Red Hat will automatically update the
|
||||
In extreme circumstances and based on Red{nbsp}Hat's assessment of the CVE criticality to the environment, Red{nbsp}Hat will notify customers that they have two link:https://access.redhat.com/articles/2623321[business days] to schedule or manually update their cluster to the latest, secure patch release. In the case that an update is not performed after two link:https://access.redhat.com/articles/2623321[business days], Red{nbsp}Hat will automatically update the
|
||||
ifdef::rosa-with-hcp[]
|
||||
cluster's control plane
|
||||
endif::rosa-with-hcp[]
|
||||
ifndef::rosa-with-hcp[]
|
||||
cluster
|
||||
endif::rosa-with-hcp[]
|
||||
to the latest, secure patch release to mitigate potential security breach(es) or instability. Red Hat might, at its own discretion, temporarily delay an automated update if requested by a customer through a link:https://access.redhat.com/support[support case].
|
||||
to the latest, secure patch release to mitigate potential security breach(es) or instability. Red{nbsp}Hat might, at its own discretion, temporarily delay an automated update if requested by a customer through a link:https://access.redhat.com/support[support case].
|
||||
|
||||
ifeval::["{context}" == "rosa-hcp-life-cycle"]
|
||||
:!rosa-with-hcp:
|
||||
|
||||
@@ -10,11 +10,11 @@ endif::[]
|
||||
[id="rosa-minor-versions_{context}"]
|
||||
= Minor versions (x.Y.z)
|
||||
|
||||
Starting with the 4.8 OpenShift Container Platform minor version, Red Hat supports all minor versions for at least a 16 month period following general availability of the given minor version. Patch versions are not affected by the support period.
|
||||
Starting with the 4.8 OpenShift Container Platform minor version, Red{nbsp}Hat supports all minor versions for at least a 16 month period following general availability of the given minor version. Patch versions are not affected by the support period.
|
||||
|
||||
Customers are notified 60, 30, and 15 days before the end of the support period. Clusters must be upgraded to the latest patch version of the oldest supported minor version before the end of the support period, or
|
||||
ifdef::rosa-with-hcp[]
|
||||
Red Hat will automatically upgrade the control plane to the next supported minor version.
|
||||
Red{nbsp}Hat will automatically upgrade the control plane to the next supported minor version.
|
||||
endif::rosa-with-hcp[]
|
||||
ifndef::rosa-with-hcp[]
|
||||
the cluster will enter a "Limited Support" status.
|
||||
|
||||
@@ -7,13 +7,6 @@
|
||||
[id="life-cycle-overview_{context}"]
|
||||
= Overview
|
||||
|
||||
Red Hat provides a published product life cycle for {product-title} in order for customers and
|
||||
partners to effectively plan, deploy, and support their applications running on the platform. Red
|
||||
Hat publishes this life cycle in order to provide as much transparency as possible and might make
|
||||
exceptions from these policies as conflicts arise.
|
||||
Red{nbsp}Hat provides a published product life cycle for {product-title} in order for customers and partners to effectively plan, deploy, and support their applications running on the platform. Red{nbsp}Hat publishes this life cycle to provide as much transparency as possible and might make exceptions from these policies as conflicts arise.
|
||||
|
||||
{product-title} is a managed instance of Red Hat OpenShift and maintains an independent release
|
||||
schedule. More details about the managed offering can be found in the {product-title} service
|
||||
definition. The availability of Security Advisories and Bug Fix Advisories for a specific version
|
||||
are dependent upon the Red Hat OpenShift Container Platform life cycle policy and subject to the
|
||||
{product-title} maintenance schedule.
|
||||
{product-title} is a managed instance of Red{nbsp}Hat OpenShift and maintains an independent release schedule. More details about the managed offering can be found in the {product-title} service definition. The availability of Security Advisories and Bug Fix Advisories for a specific version are dependent upon the Red{nbsp}Hat OpenShift Container Platform life cycle policy and subject to the {product-title} maintenance schedule.
|
||||
|
||||
@@ -6,11 +6,9 @@
|
||||
[id="rosa-patch-versions_{context}"]
|
||||
= Patch versions (x.y.Z)
|
||||
|
||||
During the period in which a minor version is supported, Red Hat supports all OpenShift Container
|
||||
Platform patch versions unless otherwise specified.
|
||||
During the period in which a minor version is supported, Red{nbsp}Hat supports all OpenShift Container Platform patch versions unless otherwise specified.
|
||||
|
||||
For reasons of platform security and stability, a patch release may be deprecated, which would
|
||||
prevent installations of that release and trigger mandatory upgrades off that release.
|
||||
For reasons of platform security and stability, a patch release may be deprecated, which would prevent installations of that release and trigger mandatory upgrades off that release.
|
||||
|
||||
.Example
|
||||
. 4.7.6 is found to contain a critical CVE.
|
||||
|
||||
@@ -6,6 +6,4 @@
|
||||
[id="rosa-supported-versions_{context}"]
|
||||
= Supported versions exception policy
|
||||
|
||||
Red Hat reserves the right to add or remove new or existing versions, or delay upcoming minor
|
||||
release versions, that have been identified to have one or more critical production impacting bugs
|
||||
or security issues without advance notice.
|
||||
Red{nbsp}Hat reserves the right to add or remove new or existing versions, or delay upcoming minor release versions, that have been identified to have one or more critical production impacting bugs or security issues without advance notice.
|
||||
|
||||
@@ -21,7 +21,7 @@ By default, only the cluster owner receives cluster notification emails. You can
|
||||
. Click the **Support** tab.
|
||||
. On the **Support** tab, find the **Notification contacts** section.
|
||||
. Click **Add notification contact**.
|
||||
. In the **Red Hat username or email** field, enter the email address or the user name of the new recipient.
|
||||
. In the **Red{nbsp}Hat username or email** field, enter the email address or the user name of the new recipient.
|
||||
//. In the type field, select the types of cluster notification to send to this recipient.
|
||||
. Click **Add contact**.
|
||||
|
||||
|
||||
@@ -11,20 +11,20 @@ Cluster notifications are designed to keep you informed about the health of your
|
||||
|
||||
Most cluster notifications are generated and sent automatically to ensure that you are immediately informed of problems or important changes to the state of your cluster.
|
||||
|
||||
In certain situations, Red Hat Site Reliability Engineering (SRE) creates and sends cluster notifications to provide additional context and guidance for a complex issue.
|
||||
In certain situations, Red{nbsp}Hat Site Reliability Engineering (SRE) creates and sends cluster notifications to provide additional context and guidance for a complex issue.
|
||||
|
||||
Cluster notifications are not sent for low-impact events, low-risk security updates, routine operations and maintenance, or minor, transient issues that are quickly resolved by SRE.
|
||||
|
||||
Red Hat services automatically send notifications when:
|
||||
Red{nbsp}Hat services automatically send notifications when:
|
||||
|
||||
* Remote health monitoring or environment verification checks detect an issue in your cluster, for example, when a worker node has low disk space.
|
||||
* Significant cluster life cycle events occur, for example, when scheduled maintenance or upgrades begin, or cluster operations are impacted by an event, but do not require customer intervention.
|
||||
* Significant cluster management changes occur, for example, when cluster ownership or administrative control is transferred from one user to another.
|
||||
* Your cluster subscription is changed or updated, for example, when Red Hat makes updates to subscription terms or features available to your cluster.
|
||||
* Your cluster subscription is changed or updated, for example, when Red{nbsp}Hat makes updates to subscription terms or features available to your cluster.
|
||||
|
||||
SRE creates and sends notifications when:
|
||||
|
||||
* An incident results in a degradation or outage that impacts your cluster's availability or performance, for example, your cloud provider has a regional outage. SRE sends subsequent notifications to inform you of incident resolution progress, and when the incident is resolved.
|
||||
* A security vulnerability, security breach, or unusual activity is detected on your cluster.
|
||||
* Red Hat detects that changes you have made are creating or may result in cluster instability.
|
||||
* Red Hat detects that your workloads are causing performance degradation or instability in your cluster.
|
||||
* Red{nbsp}Hat detects that changes you have made are creating or may result in cluster instability.
|
||||
* Red{nbsp}Hat detects that your workloads are causing performance degradation or instability in your cluster.
|
||||
|
||||
@@ -9,7 +9,7 @@
|
||||
|
||||
Each cluster notification has an associated severity level to help you identify notifications with the greatest impact to your business. You can filter cluster notifications according to these severity levels in the {hybrid-console}, in the **Cluster history** tab for your cluster.
|
||||
|
||||
Red Hat uses the following severity levels for cluster notifications, from most to least severe:
|
||||
Red{nbsp}Hat uses the following severity levels for cluster notifications, from most to least severe:
|
||||
|
||||
Critical:: Immediate action is required. One or more key functions of a service or cluster is not working, or will stop working soon. A critical alert is important enough to page on-call staff and interrupt regular workflows.
|
||||
Major:: Immediate action is strongly recommended. One or more key functions of the cluster will soon stop working. A major issue may lead to a critical issue if it is not addressed in a timely manner.
|
||||
|
||||
@@ -9,7 +9,7 @@
|
||||
|
||||
Each cluster notification has an associated notification type to help you identify notifications that are relevant to your role and responsibilities. You can filter cluster notifications according to these types in the {hybrid-console}, in the **Cluster history** tab for your cluster.
|
||||
|
||||
Red Hat uses the following notification types to indicate notification relevance.
|
||||
Red{nbsp}Hat uses the following notification types to indicate notification relevance.
|
||||
|
||||
Capacity management:: Notifications for events related to updating, creating, or deleting node pools, machine pools, compute replicas or quotas (load balancer, storage, etc.).
|
||||
Cluster access:: Notifications for events related to adding or deleting groups, roles or identity providers, for example, when SRE cannot access your cluster because STS credentials have expired, when there is a configuration problem with your AWS roles, or when you add or remove identity providers.
|
||||
|
||||
@@ -16,7 +16,7 @@ ifdef::rosa-hcp[]
|
||||
All {hcp-title} clusters are created with an AWS PrivateLink connection to expose the private Kubernetes API server to the customer's virtual private cloud (VPC).
|
||||
endif::rosa-hcp[]
|
||||
ifndef::rosa-hcp[]
|
||||
A {product-title} cluster can be created without any requirements on public subnets, internet gateways, or network address translation (NAT) gateways. In this configuration, Red Hat uses AWS PrivateLink to manage and monitor a cluster to avoid all public ingress network traffic. Without a public subnet, it is not possible to configure an application router as public. Configuring private application routers is the only option.
|
||||
A {product-title} cluster can be created without any requirements on public subnets, internet gateways, or network address translation (NAT) gateways. In this configuration, Red{nbsp}Hat uses AWS PrivateLink to manage and monitor a cluster to avoid all public ingress network traffic. Without a public subnet, it is not possible to configure an application router as public. Configuring private application routers is the only option.
|
||||
endif::rosa-hcp[]
|
||||
|
||||
For more information, see link:https://aws.amazon.com/privatelink/[AWS PrivateLink] on the AWS website.
|
||||
|
||||
@@ -5,7 +5,7 @@
|
||||
[id="osd-aws-privatelink-architecture.adoc_{context}"]
|
||||
= AWS PrivateLink architecture
|
||||
|
||||
The Red Hat managed infrastructure that creates AWS PrivateLink clusters is hosted on private subnets. The connection between Red Hat and the customer-provided infrastructure is created through AWS PrivateLink VPC endpoints.
|
||||
The Red{nbsp}Hat managed infrastructure that creates AWS PrivateLink clusters is hosted on private subnets. The connection between Red{nbsp}Hat and the customer-provided infrastructure is created through AWS PrivateLink VPC endpoints.
|
||||
|
||||
[NOTE]
|
||||
====
|
||||
|
||||
@@ -67,7 +67,7 @@ endif::[]
|
||||
|
||||
|`sso.redhat.com`
|
||||
|443
|
||||
|Required. The `https://console.redhat.com/openshift` site uses authentication from `sso.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.
|
||||
|Required. The `https://console.redhat.com/openshift` site uses authentication from `sso.redhat.com` to download the pull secret and use Red{nbsp}Hat SaaS solutions to facilitate monitoring of your subscriptions, cluster inventory, chargeback reporting, and so on.
|
||||
|
||||
|`quay-registry.s3.amazonaws.com`
|
||||
|443
|
||||
@@ -91,7 +91,7 @@ endif::[]
|
||||
|
||||
|`registry.access.redhat.com`
|
||||
|443
|
||||
|Hosts all the container images that are stored on the Red Hat Ecosytem Catalog. Additionally, the registry provides access to the `odo` CLI tool that helps developers build on OpenShift and Kubernetes.
|
||||
|Hosts all the container images that are stored on the Red{nbsp}Hat Ecosytem Catalog. Additionally, the registry provides access to the `odo` CLI tool that helps developers build on OpenShift and Kubernetes.
|
||||
|
||||
|`access.redhat.com`
|
||||
|443
|
||||
@@ -180,11 +180,11 @@ endif::fedramp[]
|
||||
|
||||
|`console.redhat.com`
|
||||
|443
|
||||
|Required for telemetry and Red Hat Insights.
|
||||
|Required for telemetry and Red{nbsp}Hat Insights.
|
||||
|
||||
|`cloud.redhat.com/api/ingress`
|
||||
|443
|
||||
|Required for telemetry and Red Hat Insights.
|
||||
|Required for telemetry and Red{nbsp}Hat Insights.
|
||||
|
||||
|`observatorium-mst.api.openshift.com`
|
||||
|443
|
||||
@@ -195,8 +195,8 @@ endif::fedramp[]
|
||||
|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.
|
||||
Managed clusters require enabling telemetry to allow Red{nbsp}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{nbsp}Hat, see _About remote health monitoring_ in the _Additional resources_ section.
|
||||
|
||||
. Allowlist the following Amazon Web Services (AWS) API URls:
|
||||
+
|
||||
@@ -286,11 +286,11 @@ Alternatively, if you choose to not use a wildcard for Amazon Web Services (AWS)
|
||||
|
||||
|`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.
|
||||
|This alerting service is used by the in-cluster alertmanager to send alerts notifying Red{nbsp}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.
|
||||
|This alerting service is used by the in-cluster alertmanager to send alerts notifying Red{nbsp}Hat SRE of an event to take action on.
|
||||
|
||||
|`api.deadmanssnitch.com`
|
||||
|443
|
||||
@@ -317,11 +317,11 @@ OR
|
||||
`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.
|
||||
|Used by the `splunk-forwarder-operator` as a logging forwarding endpoint to be used by Red{nbsp}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.
|
||||
|Required. Used by the `splunk-forwarder-operator` as a logging forwarding endpoint to be used by Red{nbsp}Hat SRE for log-based alerting.
|
||||
|
||||
|`sftp.access.redhat.com` (Recommended)
|
||||
|22
|
||||
|
||||
@@ -4,14 +4,14 @@
|
||||
// * adding_service_cluster/rosa-available-services.adoc
|
||||
:_mod-docs-content-type: CONCEPT
|
||||
[id="osd-rhoam_{context}"]
|
||||
= Red Hat OpenShift API Management
|
||||
= Red{nbsp}Hat OpenShift API Management
|
||||
|
||||
The Red Hat OpenShift API Management (OpenShift API Management) service is available as an add-on to your {product-title} on AWS cluster. OpenShift API Management is a managed API traffic control and API program management solution. It is based on the 3scale API Management platform and implements single sign-on for Red Hat solutions to secure and protect your APIs.
|
||||
The Red{nbsp}Hat OpenShift API Management (OpenShift API Management) service is available as an add-on to your {product-title} on AWS cluster. OpenShift API Management is a managed API traffic control and API program management solution. It is based on the 3scale API Management platform and implements single sign-on for Red{nbsp}Hat solutions to secure and protect your APIs.
|
||||
|
||||
This OpenShift API Management entitlement provides:
|
||||
|
||||
ifdef::openshift-rosa[]
|
||||
* Availability to any cluster that meets the resource requirements listed in the Red Hat OpenShift API Management service definition.
|
||||
* Availability to any cluster that meets the resource requirements listed in the Red{nbsp}Hat OpenShift API Management service definition.
|
||||
endif::[]
|
||||
ifdef::openshift-dedicated[]
|
||||
* Availability to any cluster that meets the resource requirements listed in the {product-title} service definition.
|
||||
|
||||
@@ -17,7 +17,7 @@ The access and identity authorization table includes responsibilities for managi
|
||||
|Customer responsibilities
|
||||
|
||||
|Logging
|
||||
|**Red Hat**
|
||||
|**Red{nbsp}Hat**
|
||||
|
||||
- Adhere to an industry standards-based tiered internal access process for platform audit logs.
|
||||
|
||||
@@ -27,45 +27,45 @@ The access and identity authorization table includes responsibilities for managi
|
||||
- For third-party or custom application logging solutions, the customer is responsible for access management.
|
||||
|
||||
|Application networking
|
||||
|**Red Hat**
|
||||
|**Red{nbsp}Hat**
|
||||
|
||||
- Provide native OpenShift RBAC and `dedicated-admin` capabilities.
|
||||
|
||||
|- Configure OpenShift `dedicated-admin` and RBAC to control access to route configuration as required.
|
||||
- Manage organization administrators for Red Hat to grant access to {cluster-manager}. The cluster manager is used to configure router options and provide service load balancer quota.
|
||||
- Manage organization administrators for Red{nbsp}Hat to grant access to {cluster-manager}. The cluster manager is used to configure router options and provide service load balancer quota.
|
||||
|
||||
|Cluster networking
|
||||
|**Red Hat**
|
||||
|**Red{nbsp}Hat**
|
||||
|
||||
- Provide customer access controls through {cluster-manager}.
|
||||
|
||||
- Provide native OpenShift RBAC and `dedicated-admin` capabilities.
|
||||
|
||||
|- Manage Red Hat organization membership of Red Hat accounts.
|
||||
- Manage organization administrators for Red Hat to grant access to {cluster-manager}.
|
||||
|- Manage Red{nbsp}Hat organization membership of Red{nbsp}Hat accounts.
|
||||
- Manage organization administrators for Red{nbsp}Hat to grant access to {cluster-manager}.
|
||||
- Configure OpenShift `dedicated-admin` and RBAC to control access to route configuration as required.
|
||||
|
||||
|Virtual networking management
|
||||
|**Red Hat**
|
||||
|**Red{nbsp}Hat**
|
||||
|
||||
- Provide customer access controls through {cluster-manager}.
|
||||
|
||||
|- Manage optional user access to AWS components through {cluster-manager}.
|
||||
|
||||
|Virtual storage management
|
||||
|**Red Hat**
|
||||
|**Red{nbsp}Hat**
|
||||
|
||||
- Provide customer access controls through
|
||||
Red Hat OpenShift Cluster Manager.
|
||||
Red{nbsp}Hat OpenShift Cluster Manager.
|
||||
|
||||
|- Manage optional user access to AWS components through {cluster-manager}.
|
||||
- Create AWS IAM roles and attached policies necessary to enable ROSA service access.
|
||||
|
||||
|Virtual compute management
|
||||
|**Red Hat**
|
||||
|**Red{nbsp}Hat**
|
||||
|
||||
- Provide customer access controls through
|
||||
Red Hat OpenShift Cluster Manager.
|
||||
Red{nbsp}Hat OpenShift Cluster Manager.
|
||||
|
||||
|- Manage optional user access to AWS components through {cluster-manager}.
|
||||
- Create AWS IAM roles and attached policies necessary to enable ROSA service access.
|
||||
|
||||
@@ -16,7 +16,7 @@ Labels are assigned as key-value pairs. Each key must be unique to the object it
|
||||
|
||||
ifdef::openshift-rosa[]
|
||||
* You installed and configured the latest {product-title} (ROSA) CLI, `rosa`, on your workstation.
|
||||
* You logged in to your Red Hat account using the ROSA CLI (`rosa`).
|
||||
* You logged in to your Red{nbsp}Hat account using the ROSA CLI (`rosa`).
|
||||
* You created a {product-title} (ROSA) cluster.
|
||||
endif::openshift-rosa[]
|
||||
ifndef::openshift-rosa[]
|
||||
|
||||
@@ -8,7 +8,7 @@
|
||||
[id="rosa-adding-taints-cli{context}"]
|
||||
= Adding taints to a machine pool using the ROSA CLI
|
||||
|
||||
You can add taints to a machine pool for your Red Hat OpenShift Service on AWS (ROSA) cluster by using the ROSA CLI.
|
||||
You can add taints to a machine pool for your Red{nbsp}Hat OpenShift Service on AWS (ROSA) cluster by using the ROSA CLI.
|
||||
|
||||
[NOTE]
|
||||
====
|
||||
@@ -18,7 +18,7 @@ For users of ROSA CLI `rosa` version 1.2.25 and prior versions, the number of ta
|
||||
|
||||
ifdef::openshift-rosa[]
|
||||
* You installed and configured the latest AWS (`aws`), ROSA (`rosa`), and OpenShift (`oc`) CLIs on your workstation.
|
||||
* You logged in to your Red Hat account by using the `rosa` CLI.
|
||||
* You logged in to your Red{nbsp}Hat account by using the `rosa` CLI.
|
||||
* You created a {product-title} (ROSA) cluster.
|
||||
endif::openshift-rosa[]
|
||||
ifndef::openshift-rosa[]
|
||||
|
||||
@@ -8,7 +8,7 @@
|
||||
[id="rosa-adding-taints-ocm{context}"]
|
||||
= Adding taints to a machine pool using OpenShift Cluster Manager
|
||||
|
||||
You can add taints to a machine pool for your Red Hat OpenShift Service on AWS (ROSA) cluster by using OpenShift Cluster Manager.
|
||||
You can add taints to a machine pool for your Red{nbsp}Hat OpenShift Service on AWS (ROSA) cluster by using OpenShift Cluster Manager.
|
||||
|
||||
.Prerequisites
|
||||
|
||||
@@ -16,7 +16,7 @@ ifndef::openshift-rosa[]
|
||||
* You created an OpenShift Dedicated cluster.
|
||||
endif::[]
|
||||
ifdef::openshift-rosa[]
|
||||
* You created a Red Hat OpenShift Service on AWS (ROSA) cluster.
|
||||
* You created a Red{nbsp}Hat OpenShift Service on AWS (ROSA) cluster.
|
||||
endif::[]
|
||||
* You have an existing machine pool that does not contain any taints and contains at least two instances.
|
||||
|
||||
|
||||
@@ -19,7 +19,7 @@ A cluster must have at least one machine pool that does not contain any taints.
|
||||
ifndef::openshift-rosa[]
|
||||
.Prerequisites
|
||||
// ifdef::openshift-rosa[]
|
||||
// * You created a Red Hat OpenShift Service on AWS (ROSA) cluster.
|
||||
// * You created a Red{nbsp}Hat OpenShift Service on AWS (ROSA) cluster.
|
||||
// endif::openshift-rosa[]
|
||||
* You created an {product-title} cluster.
|
||||
* You have an existing machine pool that does not contain any taints and contains at least two instances.
|
||||
|
||||
@@ -16,7 +16,7 @@ This feature is only supported on {hcp-title-first} clusters.
|
||||
.Prerequisites
|
||||
|
||||
* You installed and configured the latest {product-title} (ROSA) CLI, `rosa`, on your workstation.
|
||||
* You logged in to your Red Hat account by using the ROSA CLI.
|
||||
* You logged in to your Red{nbsp}Hat account by using the ROSA CLI.
|
||||
* You created a {hcp-title-first} cluster.
|
||||
* You have an existing machine pool.
|
||||
* You have an existing tuning configuration.
|
||||
|
||||
@@ -12,7 +12,7 @@ In {product-rosa} (ROSA) Classic, both the control plane and the worker nodes ar
|
||||
|
||||
With ROSA Classic, you can create clusters that are accessible over public or private networks.
|
||||
|
||||
You can customize access patterns for your API server endpoint and Red Hat SRE management in the following ways:
|
||||
You can customize access patterns for your API server endpoint and Red{nbsp}Hat SRE management in the following ways:
|
||||
|
||||
* Public - API server endpoint and application routes are internet-facing.
|
||||
|
||||
|
||||
@@ -14,7 +14,7 @@ Once you have created an identity-based IAM policy, attach it to the relevant IA
|
||||
+
|
||||
[NOTE]
|
||||
====
|
||||
You can change the default IAM `ManagedOpenShift-Support-Role` role. For more information about roles, see link:https://docs.openshift.com/rosa/rosa_architecture/rosa_policy_service_definition/rosa-sre-access.html#rosa-policy-rh-access_rosa-sre-access[Red Hat support access].
|
||||
You can change the default IAM `ManagedOpenShift-Support-Role` role. For more information about roles, see link:https://docs.openshift.com/rosa/rosa_architecture/rosa_policy_service_definition/rosa-sre-access.html#rosa-policy-rh-access_rosa-sre-access[Red{nbsp}Hat support access].
|
||||
====
|
||||
+
|
||||
. In the *Permissions* tab, select *Add Permissions* or *Create inline policy* from the *Add Permissions* drop-down list.
|
||||
@@ -25,6 +25,6 @@ You can change the default IAM `ManagedOpenShift-Support-Role` role. For more in
|
||||
|
||||
[IMPORTANT]
|
||||
====
|
||||
To ensure effective IP-based role assumption prevention, you must keep the allowlisted IPs up to date. Failure to do so may result in Red Hat site reliability engineering (SRE) being unable to access your account and affect your SLA. If you have further questions or require assistance, please reach out to our support team.
|
||||
To ensure effective IP-based role assumption prevention, you must keep the allowlisted IPs up to date. Failure to do so may result in Red{nbsp}Hat site reliability engineering (SRE) being unable to access your account and affect your SLA. If you have further questions or require assistance, please reach out to our support team.
|
||||
====
|
||||
|
||||
|
||||
@@ -3,10 +3,10 @@
|
||||
// * rosa_install_access_delete_clusters/rosa_getting_started_iam/rosa-aws-prereqs.adoc
|
||||
|
||||
[id="rosa-policy-iam_{context}"]
|
||||
= Red Hat managed IAM references for AWS
|
||||
= Red{nbsp}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.
|
||||
Red{nbsp}Hat is responsible for creating and managing the following Amazon Web Services (AWS) resources: IAM policies, IAM users, and IAM roles.
|
||||
|
||||
[id="rosa-iam-policies_{context}"]
|
||||
== IAM Policies
|
||||
@@ -16,7 +16,7 @@ Red Hat is responsible for creating and managing the following Amazon Web Servic
|
||||
IAM policies are subject to modification as the capabilities of {product-title} change.
|
||||
====
|
||||
|
||||
* The `AdministratorAccess` policy is used by the administration role. This policy provides Red Hat the access necessary to administer the {product-title} (ROSA) cluster in the customer's AWS account.
|
||||
* The `AdministratorAccess` policy is used by the administration role. This policy provides Red{nbsp}Hat the access necessary to administer the {product-title} (ROSA) cluster in the customer's AWS account.
|
||||
+
|
||||
----
|
||||
{
|
||||
|
||||
@@ -11,6 +11,6 @@ Complete these steps before deploying {product-title} (ROSA).
|
||||
|
||||
.Procedure
|
||||
. If you, as the customer, are utilizing AWS Organizations, then you must use an AWS account within your organization or link:https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts_create.html#orgs_manage_accounts_create-new[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.
|
||||
. To ensure that Red{nbsp}Hat can perform necessary actions, you must either create a service control policy (SCP) or ensure that none is applied to the AWS account.
|
||||
. link:https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html[Attach] the SCP to the AWS account.
|
||||
. Follow the ROSA procedures for setting up the environment.
|
||||
|
||||
@@ -18,39 +18,39 @@ In order to create the cluster, the user must be logged in as an IAM user and no
|
||||
+
|
||||
[NOTE]
|
||||
====
|
||||
It 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.
|
||||
It is not a requirement that the customer's account be within the AWS Organizations or for the SCP to be applied, however Red{nbsp}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's AWS account should not be transferable to Red{nbsp}Hat.
|
||||
* The customer may not impose AWS usage restrictions on Red{nbsp}Hat activities. Imposing restrictions will severely hinder Red{nbsp}Hat’s ability to respond to incidents.
|
||||
* The customer may deploy native AWS services within the same AWS account.
|
||||
+
|
||||
[NOTE]
|
||||
====
|
||||
Customers are encouraged, but not mandated, to deploy resources in a Virtual Private Cloud (VPC) separate from the VPC hosting {product-title} and other Red Hat supported services.
|
||||
Customers are encouraged, but not mandated, to deploy resources in a Virtual Private Cloud (VPC) separate from the VPC hosting {product-title} and other Red{nbsp}Hat supported services.
|
||||
====
|
||||
|
||||
[id="rosa-access-requirements_{context}"]
|
||||
== Access requirements
|
||||
* To appropriately manage the {product-title} 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).
|
||||
* To appropriately manage the {product-title} service, Red{nbsp}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).
|
||||
+
|
||||
[NOTE]
|
||||
====
|
||||
This policy only provides Red Hat with permissions and capabilities to change resources in the customer-provided AWS account.
|
||||
This policy only provides Red{nbsp}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.
|
||||
* Red{nbsp}Hat must have AWS console access to the customer-provided AWS account. This access is protected and managed by Red{nbsp}Hat.
|
||||
* The customer must not utilize the AWS account to elevate their permissions within the {product-title} cluster.
|
||||
* Actions available in the {product-title} (ROSA) CLI, `rosa`, or {cluster-manager-url} console must not be directly performed in the customer's AWS account.
|
||||
|
||||
[id="rosa-support-requirements_{context}"]
|
||||
== Support requirements
|
||||
* Red Hat recommends that the customer have at least link:https://aws.amazon.com/premiumsupport/plans/[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 {product-title} clusters in the same manner, unless otherwise specified in this requirements section.
|
||||
* Red{nbsp}Hat recommends that the customer have at least link:https://aws.amazon.com/premiumsupport/plans/[Business Support] from AWS.
|
||||
* Red{nbsp}Hat has authority from the customer to request AWS support on their behalf.
|
||||
* Red{nbsp}Hat has authority from the customer to request AWS resource limit increases on the customer's account.
|
||||
* Red{nbsp}Hat manages the restrictions, limitations, expectations, and defaults for all {product-title} clusters in the same manner, unless otherwise specified in this requirements section.
|
||||
|
||||
[id="rosa-security-requirements_{context}"]
|
||||
== 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.
|
||||
* Red{nbsp}Hat must have ingress access to EC2 hosts and the API server from allow-listed IP addresses.
|
||||
* Red{nbsp}Hat must have egress allowed to forward system and audit logs to a Red{nbsp}Hat managed central logging stack.
|
||||
|
||||
@@ -5,7 +5,7 @@
|
||||
[id="rosa-whoami_{context}"]
|
||||
= whoami
|
||||
|
||||
Display information about your AWS and Red Hat accounts by using the following command syntax:
|
||||
Display information about your AWS and Red{nbsp}Hat accounts by using the following command syntax:
|
||||
|
||||
.Syntax
|
||||
[source,terminal]
|
||||
|
||||
@@ -11,7 +11,7 @@ Use the following commands to configure the {product-title} (ROSA) CLI, `rosa`.
|
||||
[id="rosa-login_{context}"]
|
||||
== login
|
||||
|
||||
Log in to your Red Hat account, saving the credentials to the `rosa` configuration file. You must provide a token when logging in. You can copy your token from link:https://console.redhat.com/openshift/token/rosa[the ROSA token page].
|
||||
Log in to your Red{nbsp}Hat account, saving the credentials to the `rosa` configuration file. You must provide a token when logging in. You can copy your token from link:https://console.redhat.com/openshift/token/rosa[the ROSA token page].
|
||||
|
||||
The ROSA CLI (`rosa`) looks for a token in the following priority order:
|
||||
|
||||
|
||||
@@ -13,7 +13,7 @@ To configure your AWS account to use the ROSA service, complete the following st
|
||||
.Prerequisites
|
||||
|
||||
* Review and complete the deployment prerequisites and policies.
|
||||
* Create a link:https://cloud.redhat.com[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.
|
||||
* Create a link:https://cloud.redhat.com[Red{nbsp}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
|
||||
|
||||
|
||||
@@ -5,7 +5,7 @@
|
||||
[id="rosa-create-an-identity-based-policy_{context}"]
|
||||
= Create an identity-based IAM policy
|
||||
|
||||
You can create an identity-based Identity and Access Management (IAM) policy that denies access to all AWS actions when the request originates from an IP address other than Red Hat provided IPs.
|
||||
You can create an identity-based Identity and Access Management (IAM) policy that denies access to all AWS actions when the request originates from an IP address other than Red{nbsp}Hat provided IPs.
|
||||
|
||||
.Prerequisites
|
||||
|
||||
|
||||
@@ -280,14 +280,14 @@ a|--sts \| --non-sts
|
||||
When using `--private-link`, the `--subnet-ids` argument is required and only one private subnet is allowed per zone.
|
||||
|
||||
|--support-role-arn string
|
||||
|The ARN of the role used by Red Hat Site Reliabilty Engineers (SREs) to enable access to the cluster account to provide support.
|
||||
|The ARN of the role used by Red{nbsp}Hat Site Reliabilty Engineers (SREs) to enable access to the cluster account to provide support.
|
||||
|
||||
|--tags
|
||||
a|Tags that are used on resources created by {product-title} in AWS. Tags can help you manage, identify, organize, search for, and filter resources within AWS. Tags are comma separated, for example: "key value, foo bar".
|
||||
[IMPORTANT]
|
||||
====
|
||||
{product-title} only supports custom tags to Red Hat OpenShift resources during cluster creation. Once added, the tags cannot be removed or edited.
|
||||
Tags that are added by Red Hat are required for clusters to stay in compliance with Red Hat production service level agreements (SLAs). These tags must not be removed.
|
||||
{product-title} only supports custom tags to Red{nbsp}Hat OpenShift resources during cluster creation. Once added, the tags cannot be removed or edited.
|
||||
Tags that are added by Red{nbsp}Hat are required for clusters to stay in compliance with Red{nbsp}Hat production service level agreements (SLAs). These tags must not be removed.
|
||||
|
||||
{product-title} does not support adding additional tags outside of ROSA cluster-managed resources. These tags can be lost when AWS resources are managed by the ROSA cluster. In these cases, you might need custom solutions or tools to reconcile the tags and keep them intact.
|
||||
====
|
||||
|
||||
@@ -21,7 +21,7 @@ ifdef::getting-started[]
|
||||
|
||||
* You have an AWS account.
|
||||
* You installed and configured the latest {product-title} (ROSA) CLI, `rosa`, on your workstation.
|
||||
* You logged in to your Red Hat account using the ROSA CLI (`rosa`).
|
||||
* You logged in to your Red{nbsp}Hat account using the ROSA CLI (`rosa`).
|
||||
* You created a ROSA cluster.
|
||||
* You have created a cluster administrator user or added your user account to the configured identity provider.
|
||||
endif::[]
|
||||
|
||||
@@ -28,7 +28,7 @@ ifdef::getting-started[]
|
||||
|
||||
* You have an AWS account.
|
||||
* You installed and configured the latest {product-title} (ROSA) CLI, `rosa`, on your workstation.
|
||||
* You logged in to your Red Hat account using the ROSA CLI (`rosa`).
|
||||
* You logged in to your Red{nbsp}Hat account using the ROSA CLI (`rosa`).
|
||||
* You created a ROSA cluster.
|
||||
* You have a GitHub user account.
|
||||
endif::[]
|
||||
|
||||
@@ -26,7 +26,7 @@ ifdef::getting-started[]
|
||||
|
||||
* You have an AWS account.
|
||||
* You installed and configured the latest {product-title} (ROSA) CLI, `rosa`, on your workstation.
|
||||
* You logged in to your Red Hat account using the ROSA CLI (`rosa`).
|
||||
* You logged in to your Red{nbsp}Hat account using the ROSA CLI (`rosa`).
|
||||
* You created a ROSA cluster.
|
||||
endif::[]
|
||||
|
||||
|
||||
@@ -25,7 +25,7 @@ ifdef::getting-started[]
|
||||
.Prerequisites
|
||||
|
||||
* You installed and configured the latest {product-title} (ROSA) CLI, `rosa`, on your workstation.
|
||||
* You logged in to your Red Hat account using the ROSA CLI (`rosa`).
|
||||
* You logged in to your Red{nbsp}Hat account using the ROSA CLI (`rosa`).
|
||||
* You created a ROSA cluster.
|
||||
endif::[]
|
||||
|
||||
|
||||
@@ -11,7 +11,7 @@ Use the steps in this procedure to enable {product-title} (ROSA) in your AWS acc
|
||||
|
||||
.Prerequisites
|
||||
|
||||
* You have a Red Hat account.
|
||||
* You have a Red{nbsp}Hat account.
|
||||
* You have an AWS account.
|
||||
+
|
||||
[NOTE]
|
||||
@@ -33,7 +33,7 @@ The *Verify ROSA prerequisites* page opens.
|
||||
+
|
||||
If not, follow these steps:
|
||||
|
||||
.. Select the checkbox beside `I agree to share my contact information with Red Hat`.
|
||||
.. Select the checkbox beside `I agree to share my contact information with Red{nbsp}Hat`.
|
||||
.. Click *Enable ROSA*.
|
||||
+
|
||||
After a short wait, a green check mark and `You enabled ROSA` message are displayed.
|
||||
@@ -44,7 +44,7 @@ If you see `Your quotas don't meet the minimum requirements`, take note of the q
|
||||
|
||||
. Under *ELB service-linked role*, ensure that a green check mark and `AWSServiceRoleForElasticLoadBalancing already exists` are displayed.
|
||||
|
||||
. Click *Continue to Red Hat*.
|
||||
. Click *Continue to Red{nbsp}Hat*.
|
||||
+
|
||||
The *Get started with {product-title} (ROSA)* page opens in a new tab. You have already completed Step 1 on this page, and can now continue with Step 2.
|
||||
|
||||
|
||||
@@ -8,7 +8,7 @@
|
||||
|
||||
Before you create a {product-title} (ROSA) cluster, you must set up your environment by completing the following tasks:
|
||||
|
||||
* Verify ROSA prerequisites against your AWS and Red Hat accounts.
|
||||
* Verify ROSA prerequisites against your AWS and Red{nbsp}Hat accounts.
|
||||
* Install and configure the required command line interface (CLI) tools.
|
||||
* Verify the configuration of the CLI tools.
|
||||
|
||||
|
||||
@@ -21,7 +21,7 @@ ifdef::getting-started[]
|
||||
|
||||
* You have an AWS account.
|
||||
* You installed and configured the latest {product-title} (ROSA) CLI, `rosa`, on your workstation.
|
||||
* You logged in to your Red Hat account using the ROSA CLI (`rosa`).
|
||||
* You logged in to your Red{nbsp}Hat account using the ROSA CLI (`rosa`).
|
||||
* You created a ROSA cluster.
|
||||
* You have configured a GitHub identity provider for your cluster and added identity provider users.
|
||||
endif::[]
|
||||
|
||||
@@ -23,7 +23,7 @@ ifdef::getting-started[]
|
||||
|
||||
* You have an AWS account.
|
||||
* You installed and configured the latest {product-title} (ROSA) CLI, `rosa`, on your workstation.
|
||||
* You logged in to your Red Hat account using the ROSA CLI (`rosa`).
|
||||
* You logged in to your Red{nbsp}Hat account using the ROSA CLI (`rosa`).
|
||||
* You created a ROSA cluster.
|
||||
* You have a GitHub user account.
|
||||
* You have configured a GitHub identity provider for your cluster.
|
||||
|
||||
@@ -27,11 +27,11 @@ ifdef::getting-started[]
|
||||
.Prerequisites
|
||||
|
||||
* You have an AWS account.
|
||||
* You created a Red Hat account.
|
||||
* You created a Red{nbsp}Hat account.
|
||||
+
|
||||
[NOTE]
|
||||
====
|
||||
You can create a Red Hat account by navigating to link:https://console.redhat.com[console.redhat.com] and selecting *Register for a Red Hat account*.
|
||||
You can create a Red{nbsp}Hat account by navigating to link:https://console.redhat.com[console.redhat.com] and selecting *Register for a Red{nbsp}Hat account*.
|
||||
====
|
||||
endif::[]
|
||||
|
||||
@@ -104,7 +104,7 @@ You must open a new terminal to activate the configuration.
|
||||
For steps to configure `rosa` tab completion for different shell types, see the help menu by running `rosa completion --help`.
|
||||
====
|
||||
endif::[]
|
||||
.. Log in to your Red Hat account by using the ROSA CLI:
|
||||
.. Log in to your Red{nbsp}Hat account by using the ROSA CLI:
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
|
||||
@@ -20,7 +20,7 @@ ifdef::getting-started[]
|
||||
.Prerequisites
|
||||
|
||||
* You installed and configured the latest {product-title} (ROSA) CLI, `rosa`, on your workstation.
|
||||
* You logged in to your Red Hat account using the ROSA CLI (`rosa`).
|
||||
* You logged in to your Red{nbsp}Hat account using the ROSA CLI (`rosa`).
|
||||
* You created a ROSA cluster.
|
||||
* You have configured a GitHub identity provider for your cluster and added an identity provider user.
|
||||
* You granted `cluster-admin` or `dedicated-admin` privileges to a user.
|
||||
|
||||
@@ -76,7 +76,7 @@ $ rosa describe cluster --cluster=<cluster_name>
|
||||
+
|
||||
[NOTE]
|
||||
====
|
||||
If installation fails or the `State` field does not change to `ready` after 10 minutes, see the "Troubleshooting Red Hat OpenShift Service on AWS installations" documentation in the Additional resources section.
|
||||
If installation fails or the `State` field does not change to `ready` after 10 minutes, see the "Troubleshooting Red{nbsp}Hat OpenShift Service on AWS installations" documentation in the Additional resources section.
|
||||
====
|
||||
|
||||
. Enter the following command to follow the OpenShift installer logs to track the progress of your cluster:
|
||||
|
||||
@@ -15,7 +15,7 @@
|
||||
| *Classic*
|
||||
|
||||
| *Control plane hosting*
|
||||
| Control plane components, such as the API server etcd database, are hosted in a Red Hat-owned AWS account.
|
||||
| Control plane components, such as the API server etcd database, are hosted in a Red{nbsp}Hat-owned AWS account.
|
||||
| Control plane components, such as the API server etcd database, are hosted in a customer-owned AWS account.
|
||||
|
||||
| *Virtual Private Cloud (VPC)*
|
||||
|
||||
@@ -16,7 +16,7 @@ Before using the {product-title} (ROSA) CLI (`rosa`) to create {hcp-title-first}
|
||||
* You have available AWS service quotas.
|
||||
* You have enabled the ROSA service in the AWS Console.
|
||||
* You have installed and configured the latest ROSA CLI (`rosa`) on your installation host.
|
||||
* You have logged in to your Red Hat account by using the ROSA CLI.
|
||||
* You have logged in to your Red{nbsp}Hat account by using the ROSA CLI.
|
||||
|
||||
.Procedure
|
||||
|
||||
|
||||
@@ -58,7 +58,7 @@ endif::rosa-classic-sts[]
|
||||
|
||||
|`registry.access.redhat.com`
|
||||
|443
|
||||
|Required. Hosts all the container images that are stored on the Red Hat Ecosytem Catalog. Additionally, the registry provides access to the `odo` CLI tool that helps developers build on OpenShift and Kubernetes.
|
||||
|Required. Hosts all the container images that are stored on the Red{nbsp}Hat Ecosytem Catalog. Additionally, the registry provides access to the `odo` CLI tool that helps developers build on OpenShift and Kubernetes.
|
||||
|
||||
|`access.redhat.com`
|
||||
|443
|
||||
@@ -84,11 +84,11 @@ endif::rosa-classic-sts[]
|
||||
|
||||
|`sso.redhat.com`
|
||||
|443
|
||||
|Required. The `https://console.redhat.com/openshift` site uses authentication from `sso.redhat.com` to download the pull secret and use Red Hat SaaS solutions to facilitate monitoring of your subscriptions, cluster inventory, chargeback reporting, etc.
|
||||
|Required. The `https://console.redhat.com/openshift` site uses authentication from `sso.redhat.com` to download the pull secret and use Red{nbsp}Hat SaaS solutions to facilitate monitoring of your subscriptions, cluster inventory, chargeback reporting, etc.
|
||||
|===
|
||||
+
|
||||
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.
|
||||
Managed clusters require enabling telemetry to allow Red{nbsp}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{nbsp}Hat, see _About remote health monitoring_ in the _Additional resources_ section.
|
||||
|
||||
. Allowlist the following Amazon Web Services (AWS) API URls:
|
||||
+
|
||||
|
||||
@@ -86,7 +86,7 @@ The following is a list of possible `Status` field values:
|
||||
+
|
||||
* `issued` The break glass credential has been issued and is ready to use.
|
||||
* `expired` The break glass credential has expired and can no longer be used.
|
||||
* `failed` The break glass credential has failed to create. In this case, you receive a service log detailing the failure. For more information about service logs, see _Accessing the service logs for Red Hat OpenShift Service on AWS clusters_. For steps to contact Red Hat Support for assistance, see _Getting support_.
|
||||
* `failed` The break glass credential has failed to create. In this case, you receive a service log detailing the failure. For more information about service logs, see _Accessing the service logs for Red{nbsp}Hat OpenShift Service on AWS clusters_. For steps to contact Red{nbsp}Hat Support for assistance, see _Getting support_.
|
||||
* `awaiting_revocation` The break glass credential is currently being revoked, meaning it cannot be used.
|
||||
* `revoked` The break glass credential has been revoked and can no longer be used.
|
||||
+
|
||||
|
||||
@@ -14,7 +14,7 @@ When using the {product-title} (ROSA) CLI, `rosa`, to create a cluster, you can
|
||||
* You have available AWS service quotas.
|
||||
* You have enabled the ROSA service in the AWS Console.
|
||||
* You have installed and configured the latest ROSA CLI (`rosa`) on your installation host. Run `rosa version` to see your currently installed version of the ROSA CLI. If a newer version is available, the CLI provides a link to download this upgrade.
|
||||
* You have logged in to your Red Hat account by using the ROSA CLI.
|
||||
* You have logged in to your Red{nbsp}Hat account by using the ROSA CLI.
|
||||
* You have created an OIDC configuration.
|
||||
* You have verified that the AWS Elastic Load Balancing (ELB) service role exists in your AWS account.
|
||||
|
||||
@@ -88,7 +88,7 @@ The following `State` field changes are listed in the output as the cluster inst
|
||||
+
|
||||
[NOTE]
|
||||
====
|
||||
If the installation fails or the `State` field does not change to `ready` after more than 10 minutes, check the installation troubleshooting documentation for details. For more information, see _Troubleshooting installations_. For steps to contact Red Hat Support for assistance, see _Getting support for Red Hat OpenShift Service on AWS_.
|
||||
If the installation fails or the `State` field does not change to `ready` after more than 10 minutes, check the installation troubleshooting documentation for details. For more information, see _Troubleshooting installations_. For steps to contact Red{nbsp}Hat Support for assistance, see _Getting support for Red{nbsp}Hat OpenShift Service on AWS_.
|
||||
====
|
||||
+
|
||||
. Track the progress of the cluster creation by watching the {product-title} installation program logs. To check the logs, run the following command:
|
||||
|
||||
@@ -6,7 +6,7 @@
|
||||
= Install and uninstall add-ons
|
||||
|
||||
|
||||
This section describes how to install and uninstall Red Hat managed service add-ons to a cluster.
|
||||
This section describes how to install and uninstall Red{nbsp}Hat managed service add-ons to a cluster.
|
||||
|
||||
[id="rosa-install-addon_{context}"]
|
||||
== install addon
|
||||
|
||||
@@ -13,7 +13,7 @@ Install and configure the {product-title} (ROSA) CLI, `rosa`. You can also insta
|
||||
.Prerequisites
|
||||
|
||||
* Review and complete the AWS prerequisites and ROSA policies.
|
||||
* Create a link:https://cloud.redhat.com[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.
|
||||
* Create a link:https://cloud.redhat.com[Red{nbsp}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
|
||||
@@ -89,7 +89,7 @@ $ rosa completion bash | sudo tee /etc/bash_completion.d/rosa
|
||||
$ source /etc/bash_completion.d/rosa
|
||||
----
|
||||
|
||||
. Log in to your Red Hat account with `rosa`.
|
||||
. Log in to your Red{nbsp}Hat account with `rosa`.
|
||||
+
|
||||
.. Enter the following command.
|
||||
+
|
||||
@@ -157,7 +157,7 @@ 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.
|
||||
.. Run the following command to verify your Red{nbsp}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.
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
|
||||
@@ -11,7 +11,7 @@ Use the following steps to configure machine pools in Local Zones.
|
||||
|
||||
[IMPORTANT]
|
||||
====
|
||||
AWS Local Zones are supported on Red Hat OpenShift Service on AWS 4.12. See the link:https://access.redhat.com/articles/6989889[Red Hat Knowledgebase article] for information on how to enable Local Zones.
|
||||
AWS Local Zones are supported on Red{nbsp}Hat OpenShift Service on AWS 4.12. See the link:https://access.redhat.com/articles/6989889[Red{nbsp}Hat Knowledgebase article] for information on how to enable Local Zones.
|
||||
====
|
||||
.Prerequisites
|
||||
|
||||
|
||||
@@ -6,4 +6,4 @@
|
||||
[id="rosa-byo-odic-overview_{context}"]
|
||||
= Creating an OpenID Connect Configuration
|
||||
|
||||
When using a cluster hosted by Red Hat, you can create a managed or unmanaged OpenID Connect (OIDC) configuration by using the {product-title} (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 {cluster-manager}. When creating an unmanaged OIDC configuration, the CLI provides the private key for you.
|
||||
When using a cluster hosted by Red{nbsp}Hat, you can create a managed or unmanaged OpenID Connect (OIDC) configuration by using the {product-title} (ROSA) CLI, `rosa`. A managed OIDC configuration is stored within Red{nbsp}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 {cluster-manager}. When creating an unmanaged OIDC configuration, the CLI provides the private key for you.
|
||||
@@ -11,11 +11,11 @@ There are three options for OIDC verification:
|
||||
|
||||
* Unregistered, managed OIDC configuration
|
||||
+
|
||||
An unregistered, managed OIDC configuration is created for you during the cluster installation process. The configuration is hosted under Red Hat's AWS account. This option does not give you the ID that links to the OIDC configuration, so you can only use this type of OIDC configuration on a single cluster.
|
||||
An unregistered, managed OIDC configuration is created for you during the cluster installation process. The configuration is hosted under Red{nbsp}Hat's AWS account. This option does not give you the ID that links to the OIDC configuration, so you can only use this type of OIDC configuration on a single cluster.
|
||||
|
||||
* Registered, managed OIDC configuration
|
||||
+
|
||||
You create a registered, managed OIDC configuration before you start creating your clusters. This configuration is hosted under Red Hat's AWS account like the unregistered managed OIDC configuration. When you use this option for your OIDC configuration, you receive an ID that links to the OIDC configuration. Red Hat uses this ID to identify the issuer URL and private key. You can then use this URL and private key to create an identity provider and Operator roles. These resources are created under your AWS account by using Identity and Access Management (IAM) AWS services. You can also use the OIDC configuration ID during the cluster creation process.
|
||||
You create a registered, managed OIDC configuration before you start creating your clusters. This configuration is hosted under Red{nbsp}Hat's AWS account like the unregistered managed OIDC configuration. When you use this option for your OIDC configuration, you receive an ID that links to the OIDC configuration. Red{nbsp}Hat uses this ID to identify the issuer URL and private key. You can then use this URL and private key to create an identity provider and Operator roles. These resources are created under your AWS account by using Identity and Access Management (IAM) AWS services. You can also use the OIDC configuration ID during the cluster creation process.
|
||||
|
||||
* Registered, unmanaged OIDC configuration
|
||||
+
|
||||
@@ -27,5 +27,5 @@ For ROSA Classic, you may use any of the OIDC configuration options. If you are
|
||||
|
||||
[NOTE]
|
||||
====
|
||||
Reusing the OIDC configurations, OIDC provider, and Operator roles between clusters is not recommended for production clusters since the authentication verification is used throughout all of these clusters. Red Hat advises to only reuse resources on non-production test environments.
|
||||
Reusing the OIDC configurations, OIDC provider, and Operator roles between clusters is not recommended for production clusters since the authentication verification is used throughout all of these clusters. Red{nbsp}Hat advises to only reuse resources on non-production test environments.
|
||||
====
|
||||
@@ -11,7 +11,7 @@ Oversubscribing the physical resources on a node affects resource guarantees the
|
||||
|
||||
Some of the tested maximums are stretched only in a single dimension. They will vary when many objects are running on the cluster.
|
||||
|
||||
The numbers noted in this documentation are based on Red Hat testing methodology, setup, configuration, and tunings. These numbers can vary based on your own individual setup and environments.
|
||||
The numbers noted in this documentation are based on Red{nbsp}Hat testing methodology, setup, configuration, and tunings. These numbers can vary based on your own individual setup and environments.
|
||||
|
||||
While planning your environment, determine how many pods are expected to fit per node using the following formula:
|
||||
|
||||
|
||||
@@ -8,7 +8,7 @@
|
||||
|
||||
This section describes the policies about how cluster and configuration changes, patches, and releases are managed.
|
||||
|
||||
Red Hat is responsible for enabling changes to the cluster infrastructure and services that the customer will control, as well as maintaining versions for the control plane nodes, infrastructure nodes and services, and worker nodes. AWS is responsible for protecting the hardware infrastructure that runs all of the services offered in the
|
||||
Red{nbsp}Hat is responsible for enabling changes to the cluster infrastructure and services that the customer will control, as well as maintaining versions for the control plane nodes, infrastructure nodes and services, and worker nodes. AWS is responsible for protecting the hardware infrastructure that runs all of the services offered in the
|
||||
AWS Cloud. The customer is responsible for initiating infrastructure change requests and installing and maintaining optional services and networking configurations on the cluster, as well as all changes to customer data and customer applications.
|
||||
|
||||
[id="rosa-policy-customer-initiated-changes_{context}"]
|
||||
@@ -42,9 +42,9 @@ To enforce the maintenance exclusion, ensure machine pool autoscaling or automat
|
||||
====
|
||||
|
||||
[id="rosa-policy-red-hat-initiated-changes_{context}"]
|
||||
== Red Hat-initiated changes
|
||||
== Red{nbsp}Hat-initiated changes
|
||||
|
||||
Red Hat site reliability engineering (SRE) manages the infrastructure, code, and configuration of {product-title} using a GitOps workflow and fully automated CI/CD pipelines. This process ensures that Red Hat can safely introduce service improvements on a continuous basis without negatively impacting customers.
|
||||
Red{nbsp}Hat site reliability engineering (SRE) manages the infrastructure, code, and configuration of {product-title} using a GitOps workflow and fully automated CI/CD pipelines. This process ensures that Red{nbsp}Hat can safely introduce service improvements on a continuous basis without negatively impacting customers.
|
||||
|
||||
Every proposed change undergoes a series of automated verifications immediately upon check-in. Changes are then deployed to a staging environment where they undergo automated integration testing. Finally, changes are deployed to the production environment. Each step is fully automated.
|
||||
|
||||
@@ -55,12 +55,12 @@ Some changes are released to production incrementally, using feature flags to co
|
||||
[id="rosa-policy-patch-management_{context}"]
|
||||
== Patch management
|
||||
|
||||
OpenShift Container Platform software and the underlying immutable Red Hat CoreOS (RHCOS) operating system image are patched for bugs and vulnerabilities in regular z-stream upgrades. Read more about link:https://access.redhat.com/documentation/en-us/openshift_container_platform/4.6/html/architecture/architecture-rhcos[RHCOS architecture] in the OpenShift Container Platform documentation.
|
||||
OpenShift Container Platform software and the underlying immutable Red{nbsp}Hat CoreOS (RHCOS) operating system image are patched for bugs and vulnerabilities in regular z-stream upgrades. Read more about link:https://access.redhat.com/documentation/en-us/openshift_container_platform/4.6/html/architecture/architecture-rhcos[RHCOS architecture] in the OpenShift Container Platform documentation.
|
||||
|
||||
[id="rosa-policy-release-management_{context}"]
|
||||
== Release management
|
||||
|
||||
Red Hat does not automatically upgrade your clusters. You can schedule to upgrade the clusters at regular intervals (recurring upgrade) or just once (individual upgrade) using the {cluster-manager} web console. Red Hat might forcefully upgrade a cluster to a new z-stream version only if the cluster is affected by a critical impact CVE.
|
||||
Red{nbsp}Hat does not automatically upgrade your clusters. You can schedule to upgrade the clusters at regular intervals (recurring upgrade) or just once (individual upgrade) using the {cluster-manager} web console. Red{nbsp}Hat might forcefully upgrade a cluster to a new z-stream version only if the cluster is affected by a critical impact CVE.
|
||||
|
||||
[NOTE]
|
||||
====
|
||||
@@ -77,7 +77,7 @@ You can review the history of all cluster upgrade events in the {cluster-manager
|
||||
|Customer responsibilities
|
||||
|
||||
|Logging
|
||||
|**Red Hat**
|
||||
|**Red{nbsp}Hat**
|
||||
|
||||
- Centrally aggregate and monitor platform audit logs.
|
||||
|
||||
@@ -91,7 +91,7 @@ You can review the history of all cluster upgrade events in the {cluster-manager
|
||||
- Request platform audit logs through a support case for researching specific incidents.
|
||||
|
||||
|Application networking
|
||||
|**Red Hat**
|
||||
|**Red{nbsp}Hat**
|
||||
|
||||
- Set up public load balancers. Provide the ability to set up private load balancers and up to one additional load balancer when required.
|
||||
|
||||
@@ -108,7 +108,7 @@ You can review the history of all cluster upgrade events in the {cluster-manager
|
||||
- Configure any necessary DNS forwarding rules.
|
||||
|
||||
|Cluster networking
|
||||
|**Red Hat**
|
||||
|**Red{nbsp}Hat**
|
||||
|
||||
- Set up cluster management components, such as public or private service endpoints and necessary integration with Amazon VPC components.
|
||||
|
||||
@@ -118,7 +118,7 @@ You can review the history of all cluster upgrade events in the {cluster-manager
|
||||
- Request that the API service endpoint be made public or private on cluster creation or after cluster creation through {cluster-manager}.
|
||||
|
||||
|Virtual networking management
|
||||
|**Red Hat**
|
||||
|**Red{nbsp}Hat**
|
||||
|
||||
- Set up and configure Amazon VPC components required to provision the cluster, such as subnets, load balancers, internet gateways, and NAT gateways.
|
||||
|
||||
@@ -131,7 +131,7 @@ manage AWS VPN connectivity with on-premises resources, Amazon VPC-to-VPC connec
|
||||
- Request and configure any additional service load balancers for specific services.
|
||||
|
||||
|Virtual compute management
|
||||
|**Red Hat**
|
||||
|**Red{nbsp}Hat**
|
||||
|
||||
- Set up and configure the ROSA control plane and data plane to use Amazon EC2 instances for cluster compute.
|
||||
|
||||
@@ -142,7 +142,7 @@ machine pool using the OpenShift Cluster Manager or the ROSA CLI (`rosa`).
|
||||
- Manage changes to customer-deployed applications and application data.
|
||||
|
||||
|Cluster version
|
||||
|**Red Hat**
|
||||
|**Red{nbsp}Hat**
|
||||
|
||||
- Enable upgrade scheduling process.
|
||||
|
||||
@@ -155,7 +155,7 @@ machine pool using the OpenShift Cluster Manager or the ROSA CLI (`rosa`).
|
||||
- Test customer applications on patch releases to ensure compatibility.
|
||||
|
||||
|Capacity management
|
||||
|**Red Hat**
|
||||
|**Red{nbsp}Hat**
|
||||
|
||||
- Monitor the use of the control plane. Control planes include control plane nodes and infrastructure nodes.
|
||||
|
||||
@@ -164,10 +164,10 @@ machine pool using the OpenShift Cluster Manager or the ROSA CLI (`rosa`).
|
||||
| - Monitor worker node utilization and, if appropriate, enables the auto-scaling feature.
|
||||
- Determine the scaling strategy of the cluster. See the additional resources for more information on machine pools.
|
||||
- Use the provided {cluster-manager} controls to add or remove additional worker nodes as required.
|
||||
- Respond to Red Hat notifications regarding cluster resource requirements.
|
||||
- Respond to Red{nbsp}Hat notifications regarding cluster resource requirements.
|
||||
|
||||
|Virtual storage management
|
||||
|**Red Hat**
|
||||
|**Red{nbsp}Hat**
|
||||
|
||||
- Set up and configure Amazon EBS to provision local node storage and persistent volume storage for the cluster.
|
||||
|
||||
|
||||
@@ -6,19 +6,19 @@
|
||||
[id="rosa-policy-customer-responsibility_{context}"]
|
||||
= Additional customer responsibilities for data and applications
|
||||
|
||||
The customer is responsible for the applications, workloads, and data that they deploy to Red Hat
|
||||
OpenShift Service on AWS. However, Red Hat and AWS provide various tools to help the customer
|
||||
The customer is responsible for the applications, workloads, and data that they deploy to Red{nbsp}Hat
|
||||
OpenShift Service on AWS. However, Red{nbsp}Hat and AWS provide various tools to help the customer
|
||||
manage data and applications on the platform.
|
||||
|
||||
[cols="2a,3a,3a",options="header"]
|
||||
|===
|
||||
|
||||
|Resource
|
||||
|Red Hat and AWS
|
||||
|Red{nbsp}Hat and AWS
|
||||
|Customer responsibilities
|
||||
|
||||
|Customer data
|
||||
|**Red Hat**
|
||||
|**Red{nbsp}Hat**
|
||||
|
||||
- Maintain platform-level standards for data encryption as defined by industry security and
|
||||
compliance standards.
|
||||
@@ -32,11 +32,11 @@ Amazon RDS to store and manage data outside of the cluster and/or AWS.
|
||||
|- Maintain responsibility for all customer data stored on the platform and how customer applications consume and expose this data.
|
||||
|
||||
|Customer applications
|
||||
|**Red Hat**
|
||||
|**Red{nbsp}Hat**
|
||||
|
||||
- Provision clusters with OpenShift components installed so that customers can access the OpenShift and Kubernetes APIs to deploy and manage containerized applications.
|
||||
- Create clusters with image pull secrets so that customer deployments can pull images from the Red Hat Container Catalog registry.
|
||||
- Provide access to OpenShift APIs that a customer can use to set up Operators to add community, third-party, and Red Hat services to the cluster.
|
||||
- Create clusters with image pull secrets so that customer deployments can pull images from the Red{nbsp}Hat Container Catalog registry.
|
||||
- Provide access to OpenShift APIs that a customer can use to set up Operators to add community, third-party, and Red{nbsp}Hat services to the cluster.
|
||||
- Provide storage classes and plugins to support persistent volumes for use with customer applications.
|
||||
- Provide a container image registry so customers can securely store application container images on the cluster to deploy and manage applications.
|
||||
|
||||
@@ -44,10 +44,10 @@ Amazon RDS to store and manage data outside of the cluster and/or AWS.
|
||||
|
||||
- Provide Amazon EBS to support persistent volumes for use with customer applications.
|
||||
|
||||
- Provide Amazon S3 to support Red Hat provisioning of the container image registry.
|
||||
- Provide Amazon S3 to support Red{nbsp}Hat provisioning of the container image registry.
|
||||
|
||||
|- Maintain responsibility for customer and third-party applications, data, and their complete lifecycle.
|
||||
- If a customer adds Red Hat, community, third-party, their own, or other services to the cluster by using Operators or external images, the customer is responsible for these services and for working with the appropriate provider, including Red Hat, to troubleshoot any issues.
|
||||
- If a customer adds Red{nbsp}Hat, community, third-party, their own, or other services to the cluster by using Operators or external images, the customer is responsible for these services and for working with the appropriate provider, including Red{nbsp}Hat, to troubleshoot any issues.
|
||||
- Use the provided tools and features to configure and deploy; keep up to date; set up resource requests and limits; size the cluster to have enough resources to run apps; set up permissions; integrate with other services; manage any image streams or templates that the customer deploys; externally serve; save, back up, and restore data; and otherwise manage their highly available and resilient workloads.
|
||||
- Maintain responsibility for monitoring the applications run on {product-title}, including
|
||||
installing and operating software to gather metrics, create alerts, and protect secrets in the application.
|
||||
|
||||
@@ -21,14 +21,14 @@ One multi-zone cluster will not provide disaster avoidance or recovery in the ev
|
||||
|Customer responsibilities
|
||||
|
||||
|Virtual networking management
|
||||
|**Red Hat**
|
||||
|**Red{nbsp}Hat**
|
||||
|
||||
- Restore or recreate affected virtual network components that are necessary for the platform to function.
|
||||
|- Configure virtual networking connections with more than one tunnel where possible for protection against outages as recommended by the public cloud provider.
|
||||
- Maintain failover DNS and load balancing if using a global load balancer with multiple clusters.
|
||||
|
||||
|Virtual Storage management
|
||||
|**Red Hat**
|
||||
|**Red{nbsp}Hat**
|
||||
|
||||
- For ROSA clusters created with IAM user credentials, back up all Kubernetes objects on the cluster through hourly, daily, and weekly volume snapshots. Hourly backups are retained for 24 hrs (1 day), daily backups are retained for 168 hrs (1 week), and weekly backups are retained for 720 hrs (30 days).
|
||||
|
||||
@@ -36,7 +36,7 @@ One multi-zone cluster will not provide disaster avoidance or recovery in the ev
|
||||
|- Back up customer applications and application data.
|
||||
|
||||
|Virtual compute management
|
||||
|**Red Hat**
|
||||
|**Red{nbsp}Hat**
|
||||
|
||||
- Monitor the cluster and replace failed Amazon EC2 control plane or infrastructure nodes.
|
||||
|
||||
|
||||
@@ -9,7 +9,7 @@
|
||||
|
||||
{product-title} (ROSA) provides many features and options for protecting your workloads against downtime, but applications must be architected appropriately to take advantage of these features.
|
||||
|
||||
ROSA can help further protect you against many common Kubernetes issues by adding Red Hat site reliability engineering (SRE) support and the option to deploy a multiple availability zone cluster, but there are a number of ways in which a container or infrastructure can still fail. By understanding potential points of failure, you can understand risks and appropriately architect both your applications and your clusters to be as resilient as necessary at each specific level.
|
||||
ROSA can help further protect you against many common Kubernetes issues by adding Red{nbsp}Hat site reliability engineering (SRE) support and the option to deploy a multiple availability zone cluster, but there are several ways in which a container or infrastructure can still fail. By understanding potential points of failure, you can understand risks and appropriately architect both your applications and your clusters to be as resilient as necessary at each specific level.
|
||||
|
||||
[NOTE]
|
||||
====
|
||||
@@ -37,11 +37,11 @@ When accounting for possible node failures, it is also important to understand h
|
||||
== Cluster failure
|
||||
Single-AZ ROSA clusters have at least three control plane and two infrastructure nodes in the same availability zone (AZ) in the private subnet.
|
||||
|
||||
Multi-AZ ROSA clusters have at least three control plane nodes and three infrastructure nodes that are preconfigured for high availability, either in a single zone or across multiple zones, depending on the type of cluster you have selected. Control plane and infrastructure nodes have the same resiliency as worker nodes, with the added benefit of being managed completely by Red Hat.
|
||||
Multi-AZ ROSA clusters have at least three control plane nodes and three infrastructure nodes that are preconfigured for high availability, either in a single zone or across multiple zones, depending on the type of cluster you have selected. Control plane and infrastructure nodes have the same resiliency as worker nodes, with the added benefit of being managed completely by Red{nbsp}Hat.
|
||||
|
||||
In the event of a complete control plane outage, the OpenShift APIs will not function, and existing worker node pods are unaffected. However, if there is also a pod or node outage at the same time, the control planes must recover before new pods or nodes can be added or scheduled.
|
||||
|
||||
All services running on infrastructure nodes are configured by Red Hat to be highly available and distributed across infrastructure nodes. In the event of a complete infrastructure outage, these services are unavailable until these nodes have been recovered.
|
||||
All services running on infrastructure nodes are configured by Red{nbsp}Hat to be highly available and distributed across infrastructure nodes. In case of a complete infrastructure outage, these services are unavailable until these nodes have been recovered.
|
||||
|
||||
[id="rosa-policy-container-zone-failure_{context}"]
|
||||
== Zone failure
|
||||
|
||||
@@ -5,7 +5,7 @@
|
||||
[id="rosa-policy-incident_{context}"]
|
||||
= Incident and operations management
|
||||
|
||||
Red Hat is responsible for overseeing the service components required for default platform networking.
|
||||
Red{nbsp}Hat is responsible for overseeing the service components required for default platform networking.
|
||||
AWS is responsible for protecting the hardware infrastructure that runs all of the services offered in the AWS Cloud. The customer is responsible for incident and operations management of customer application data and any custom networking the customer has configured for the cluster network or virtual network.
|
||||
|
||||
[cols= "2a,3a,3a",options="header"]
|
||||
@@ -16,15 +16,15 @@ AWS is responsible for protecting the hardware infrastructure that runs all of t
|
||||
|Customer responsibilities
|
||||
|
||||
|Application networking
|
||||
|**Red Hat**
|
||||
|**Red{nbsp}Hat**
|
||||
|
||||
- Monitor native OpenShift router
|
||||
service, and respond to alerts.
|
||||
|- Monitor health of application routes, and the endpoints behind them.
|
||||
- Report outages to Red Hat and AWS.
|
||||
- Report outages to Red{nbsp}Hat and AWS.
|
||||
|
||||
|Virtual networking management
|
||||
|**Red Hat**
|
||||
|**Red{nbsp}Hat**
|
||||
|
||||
- Monitor AWS load balancers, Amazon VPC subnets, and AWS service components necessary for default
|
||||
platform networking. Respond to alerts.
|
||||
@@ -34,7 +34,7 @@ Direct Connect for potential issues or
|
||||
security threats.
|
||||
|
||||
|Virtual storage management
|
||||
|**Red Hat**
|
||||
|**Red{nbsp}Hat**
|
||||
|
||||
- Monitor Amazon EBS volumes attached to cluster nodes and Amazon S3 buckets used for the ROSA service’s built-in container image
|
||||
registry. Respond to alerts.
|
||||
@@ -44,28 +44,28 @@ used, create and control the key lifecycle and
|
||||
key policies for Amazon EBS encryption.
|
||||
|
||||
|Platform monitoring
|
||||
|**Red Hat**
|
||||
|**Red{nbsp}Hat**
|
||||
|
||||
- Maintain a centralized monitoring and alerting system for all ROSA cluster components, site reliability engineer (SRE) services, and underlying AWS accounts.
|
||||
|
|
||||
|
||||
|Incident management
|
||||
|**Red Hat**
|
||||
|**Red{nbsp}Hat**
|
||||
|
||||
- Raise and manage known incidents.
|
||||
- Share root cause analysis (RCA) drafts with the customer.
|
||||
|- Raise known incidents through a support case.
|
||||
|
||||
|Infrastructure and data resiliency
|
||||
|**Red Hat**
|
||||
|**Red{nbsp}Hat**
|
||||
|
||||
- There is no Red Hat-provided backup method available for ROSA clusters with STS.
|
||||
- Red Hat does not commit to any Recovery Point Objective (RPO) or Recovery Time Objective (RTO).
|
||||
- There is no Red{nbsp}Hat-provided backup method available for ROSA clusters with STS.
|
||||
- Red{nbsp}Hat does not commit to any Recovery Point Objective (RPO) or Recovery Time Objective (RTO).
|
||||
|- Take regular backups of data and deploy multi-AZ clusters with workloads that follow Kubernetes best practices to ensure high availability within a region.
|
||||
- If an entire cloud region is unavailable, install a new cluster in a different region and restore apps using backup data.
|
||||
|
||||
|Cluster capacity
|
||||
|**Red Hat**
|
||||
|**Red{nbsp}Hat**
|
||||
|
||||
- Manage the capacity of all control plane and infrastructure nodes on the cluster.
|
||||
- Evaluate cluster capacity during upgrades and in response to cluster alerts.
|
||||
@@ -96,11 +96,11 @@ Platform audit logs are securely forwarded to a centralized security information
|
||||
|
||||
[id="rosa-policy-incident-management_{context}"]
|
||||
== Incident management
|
||||
An incident is an event that results in a degradation or outage of one or more Red Hat services. An incident can be raised by a customer or a Customer Experience and Engagement (CEE) member through a support case, directly by the centralized monitoring and alerting system, or directly by a member of the SRE team.
|
||||
An incident is an event that results in a degradation or outage of one or more Red{nbsp}Hat services. An incident can be raised by a customer or a Customer Experience and Engagement (CEE) member through a support case, directly by the centralized monitoring and alerting system, or directly by a member of the SRE team.
|
||||
|
||||
Depending on the impact on the service and customer, the incident is categorized in terms of link:https://access.redhat.com/support/offerings/production/sla[severity].
|
||||
|
||||
When managing a new incident, Red Hat uses the following general workflow:
|
||||
When managing a new incident, Red{nbsp}Hat uses the following general workflow:
|
||||
|
||||
. An SRE first responder is alerted to a new incident and begins an initial investigation.
|
||||
. After the initial investigation, the incident is assigned an incident lead, who coordinates the recovery efforts.
|
||||
@@ -109,8 +109,8 @@ When managing a new incident, Red Hat uses the following general workflow:
|
||||
. The incident is documented and a root cause analysis (RCA) is performed within 5 business days of the incident.
|
||||
. An RCA draft document will be shared with the customer within 7 business days of the incident.
|
||||
|
||||
Red Hat also assists with customer incidents raised through support cases.
|
||||
Red Hat can assist with activities including but not limited to:
|
||||
Red{nbsp}Hat also assists with customer incidents raised through support cases.
|
||||
Red{nbsp}Hat can assist with activities including but not limited to:
|
||||
|
||||
* Forensic gathering, including isolating virtual compute
|
||||
* Guiding compute image collection
|
||||
@@ -157,4 +157,4 @@ Red Hat can assist with activities including but not limited to:
|
||||
|
||||
The impact of a cluster upgrade on capacity is evaluated as part of the upgrade testing process to ensure that capacity is not negatively impacted by new additions to the cluster. During a cluster upgrade, additional worker nodes are added to make sure that total cluster capacity is maintained during the upgrade process.
|
||||
|
||||
Capacity evaluations by the Red Hat SRE staff also happen in response to alerts from the cluster, after usage thresholds are exceeded for a certain period of time. Such alerts can also result in a notification to the customer.
|
||||
Capacity evaluations by the Red{nbsp}Hat SRE staff also happen in response to alerts from the cluster, after usage thresholds are exceeded for a certain period of time. Such alerts can also result in a notification to the customer.
|
||||
|
||||
@@ -7,11 +7,11 @@
|
||||
= Shared responsibilities for {product-title}
|
||||
|
||||
|
||||
While Red Hat and Amazon Web Services (AWS) manage the {product-title} services, the customer shares certain responsibilities. The {product-title} services are accessed remotely, hosted on public cloud resources, created in customer-owned AWS accounts, and have underlying platform and data security that is owned by Red Hat.
|
||||
While Red{nbsp}Hat and Amazon Web Services (AWS) manage the {product-title} services, the customer shares certain responsibilities. The {product-title} services are accessed remotely, hosted on public cloud resources, created in customer-owned AWS accounts, and have underlying platform and data security that is owned by Red{nbsp}Hat.
|
||||
|
||||
[IMPORTANT]
|
||||
====
|
||||
If the `cluster-admin` role is added to a user, see the responsibilities and exclusion notes in the link:https://www.redhat.com/en/about/agreements[Red Hat Enterprise Agreement Appendix 4 (Online Subscription Services)].
|
||||
If the `cluster-admin` role is added to a user, see the responsibilities and exclusion notes in the link:https://www.redhat.com/en/about/agreements[Red{nbsp}Hat Enterprise Agreement Appendix 4 (Online Subscription Services)].
|
||||
====
|
||||
|
||||
[cols="2a,3a,3a,3a,3a,3a",options="header"]
|
||||
@@ -30,23 +30,23 @@ If the `cluster-admin` role is added to a user, see the responsibilities and exc
|
||||
|
||||
|Developer services |Customer |Customer |Customer |Customer |Customer
|
||||
|
||||
|Platform monitoring |Red Hat |Red Hat |Red Hat |Red Hat |Red Hat
|
||||
|Platform monitoring |Red{nbsp}Hat |Red{nbsp}Hat |Red{nbsp}Hat |Red{nbsp}Hat |Red{nbsp}Hat
|
||||
|
||||
|Logging |Red Hat |Red Hat and Customer |Red Hat and Customer |Red Hat and Customer |Red Hat
|
||||
|Logging |Red{nbsp}Hat |Red{nbsp}Hat and Customer |Red{nbsp}Hat and Customer |Red{nbsp}Hat and Customer |Red{nbsp}Hat
|
||||
|
||||
|Application networking |Red Hat and Customer |Red Hat and Customer |Red Hat and Customer |Red Hat |Red Hat
|
||||
|Application networking |Red{nbsp}Hat and Customer |Red{nbsp}Hat and Customer |Red{nbsp}Hat and Customer |Red{nbsp}Hat |Red{nbsp}Hat
|
||||
|
||||
|Cluster networking |Red Hat |Red Hat and Customer |Red Hat and Customer |Red Hat |Red Hat
|
||||
|Cluster networking |Red{nbsp}Hat |Red{nbsp}Hat and Customer |Red{nbsp}Hat and Customer |Red{nbsp}Hat |Red{nbsp}Hat
|
||||
|
||||
|Virtual networking management |Red Hat and Customer |Red Hat and Customer |Red Hat and Customer |Red Hat and Customer |Red Hat and Customer
|
||||
|Virtual networking management |Red{nbsp}Hat and Customer |Red{nbsp}Hat and Customer |Red{nbsp}Hat and Customer |Red{nbsp}Hat and Customer |Red{nbsp}Hat and Customer
|
||||
|
||||
|Virtual compute management (control plane, infrastructure and worker nodes) |Red Hat |Red Hat |Red Hat |Red Hat |Red Hat
|
||||
|Virtual compute management (control plane, infrastructure and worker nodes) |Red{nbsp}Hat |Red{nbsp}Hat |Red{nbsp}Hat |Red{nbsp}Hat |Red{nbsp}Hat
|
||||
|
||||
|Cluster version |Red Hat |Red Hat and Customer |Red Hat |Red Hat |Red Hat
|
||||
|Cluster version |Red{nbsp}Hat |Red{nbsp}Hat and Customer |Red{nbsp}Hat |Red{nbsp}Hat |Red{nbsp}Hat
|
||||
|
||||
|Capacity management |Red Hat |Red Hat and Customer |Red Hat |Red Hat |Red Hat
|
||||
|Capacity management |Red{nbsp}Hat |Red{nbsp}Hat and Customer |Red{nbsp}Hat |Red{nbsp}Hat |Red{nbsp}Hat
|
||||
|
||||
|Virtual storage management |Red Hat |Red Hat |Red Hat |Red Hat |Red Hat
|
||||
|Virtual storage management |Red{nbsp}Hat |Red{nbsp}Hat |Red{nbsp}Hat |Red{nbsp}Hat |Red{nbsp}Hat
|
||||
|
||||
|AWS software (public AWS services) |AWS |AWS
|
||||
|AWS |AWS |AWS
|
||||
|
||||
@@ -14,14 +14,14 @@ The following table outlines the the responsibilities in regards to security an
|
||||
|Customer responsibilities
|
||||
|
||||
|Logging
|
||||
|**Red Hat**
|
||||
|**Red{nbsp}Hat**
|
||||
|
||||
- Send cluster audit logs to a Red Hat SIEM to analyze for security events. Retain audit logs for a defined period of time to support forensic analysis.
|
||||
- Send cluster audit logs to a Red{nbsp}Hat SIEM to analyze for security events. Retain audit logs for a defined period of time to support forensic analysis.
|
||||
|- Analyze application logs for security events.
|
||||
- Send application logs to an external endpoint through logging sidecar containers or third-party logging applications if longer retention is required than is offered by the default logging stack.
|
||||
|
||||
|Virtual networking management
|
||||
|**Red Hat**
|
||||
|**Red{nbsp}Hat**
|
||||
|
||||
- Monitor virtual networking components for potential issues and security threats.
|
||||
|
||||
@@ -31,7 +31,7 @@ The following table outlines the the responsibilities in regards to security an
|
||||
- Configure any necessary firewall rules or customer data center protections as required.
|
||||
|
||||
|Virtual storage management
|
||||
|**Red Hat**
|
||||
|**Red{nbsp}Hat**
|
||||
|
||||
- Monitor virtual storage components for potential issues and security threats.
|
||||
|
||||
@@ -56,7 +56,7 @@ images from unauthorized user access.
|
||||
persistent volume though OpenShift Cluster Manager.
|
||||
|
||||
|Virtual compute management
|
||||
|**Red Hat**
|
||||
|**Red{nbsp}Hat**
|
||||
|
||||
- Monitor virtual compute components for potential issues and security threats.
|
||||
|
||||
|
||||
@@ -10,7 +10,7 @@ Security and regulation compliance includes tasks such as the implementation of
|
||||
|
||||
[id="rosa-policy-data-classification_{context}"]
|
||||
== Data classification
|
||||
Red Hat defines and follows a data classification standard to determine the sensitivity of data and highlight inherent risk to the confidentiality and integrity of that data while it is collected, used, transmitted, stored, and processed. Customer-owned data is classified at the highest level of sensitivity and handling requirements.
|
||||
Red{nbsp}Hat defines and follows a data classification standard to determine the sensitivity of data and highlight inherent risk to the confidentiality and integrity of that data while it is collected, used, transmitted, stored, and processed. Customer-owned data is classified at the highest level of sensitivity and handling requirements.
|
||||
|
||||
[id="rosa-policy-data-management_{context}"]
|
||||
== Data management
|
||||
@@ -20,7 +20,7 @@ When a customer deletes their ROSA cluster, all cluster data is permanently dele
|
||||
|
||||
[id="rosa-policy-vulnerability-management_{context}"]
|
||||
== Vulnerability management
|
||||
Red Hat performs periodic vulnerability scanning of ROSA using industry standard tools. Identified vulnerabilities are tracked to their remediation according to timelines based on severity. Vulnerability scanning and remediation activities are documented for verification by third-party assessors in the course of compliance certification audits.
|
||||
Red{nbsp}Hat performs periodic vulnerability scanning of ROSA using industry standard tools. Identified vulnerabilities are tracked to their remediation according to timelines based on severity. Vulnerability scanning and remediation activities are documented for verification by third-party assessors in the course of compliance certification audits.
|
||||
|
||||
[id="rosa-policy-network-security_{context}"]
|
||||
== Network security
|
||||
@@ -31,7 +31,7 @@ Each ROSA cluster is protected by a secure network configuration using firewall
|
||||
|
||||
[id="rosa-policy-private-clusters-network-connectivity_{context}"]
|
||||
=== Private clusters and network connectivity
|
||||
Customers can optionally configure their ROSA cluster endpoints, such as web console, API, and application router, to be made private so that the cluster control plane and applications are not accessible from the Internet. Red Hat SRE still requires Internet-accessible endpoints that are protected with IP allow-lists.
|
||||
Customers can optionally configure their ROSA cluster endpoints, such as web console, API, and application router, to be made private so that the cluster control plane and applications are not accessible from the Internet. Red{nbsp}Hat SRE still requires Internet-accessible endpoints that are protected with IP allow-lists.
|
||||
|
||||
AWS customers can configure a private network connection to their ROSA cluster through technologies such as AWS VPC peering, AWS VPN, or AWS Direct Connect.
|
||||
|
||||
@@ -41,7 +41,7 @@ Fine-grained network access control rules can be configured by customers, on a p
|
||||
|
||||
[id="rosa-policy-penetration-testing_{context}"]
|
||||
== Penetration testing
|
||||
Red Hat performs periodic penetration tests against ROSA. Tests are performed by an independent internal team by using industry standard tools and best practices.
|
||||
Red{nbsp}Hat performs periodic penetration tests against ROSA. Tests are performed by an independent internal team by using industry standard tools and best practices.
|
||||
|
||||
Any issues that may be discovered are prioritized based on severity. Any issues found belonging to open source projects are shared with the community for resolution.
|
||||
|
||||
|
||||
@@ -5,4 +5,4 @@
|
||||
[id="rosa-policy-shared-responsibility_{context}"]
|
||||
= Tasks for shared responsibilities by area
|
||||
|
||||
Red Hat, AWS, and the customer all share responsibility for the monitoring, maintenance, and overall health of a {product-title} (ROSA) cluster. This documentation illustrates the delineation of responsibilities for each of the listed resources as shown in the tables below.
|
||||
Red{nbsp}Hat, AWS, and the customer all share responsibility for the monitoring, maintenance, and overall health of a {product-title} (ROSA) cluster. This documentation illustrates the delineation of responsibilities for each of the listed resources as shown in the tables below.
|
||||
@@ -5,8 +5,8 @@
|
||||
:_mod-docs-content-type: REFERENCE
|
||||
|
||||
[id="rosa-policy-rh-access_{context}"]
|
||||
= Red Hat support access
|
||||
Members of the Red Hat Customer Experience and Engagement (CEE) team typically have read-only access to parts of the cluster. Specifically, CEE has limited access to the core and product namespaces and does not have access to the customer namespaces.
|
||||
= Red{nbsp}Hat support access
|
||||
Members of the Red{nbsp}Hat Customer Experience and Engagement (CEE) team typically have read-only access to parts of the cluster. Specifically, CEE has limited access to the core and product namespaces and does not have access to the customer namespaces.
|
||||
|
||||
[cols= "2a,4a,4a,4a,4a",options="header"]
|
||||
|
||||
@@ -97,7 +97,7 @@ Write: None
|
||||
|===
|
||||
--
|
||||
1. Limited to addressing common use cases such as failing deployments, upgrading a cluster, and replacing bad worker nodes.
|
||||
2. Red Hat associates have no access to customer data by default.
|
||||
2. Red{nbsp}Hat associates have no access to customer data by default.
|
||||
3. SRE access to the AWS account is an emergency procedure for exceptional troubleshooting during a documented incident.
|
||||
4. Limited to what is granted through RBAC by the Customer Administrator and namespaces created by the user.
|
||||
--
|
||||
@@ -3,6 +3,6 @@
|
||||
// * adding_service_cluster/rosa-available-services.adoc
|
||||
:_mod-docs-content-type: CONCEPT
|
||||
[id="rosa-rhods_{context}"]
|
||||
= Red Hat OpenShift Data Science
|
||||
= Red{nbsp}Hat OpenShift Data Science
|
||||
|
||||
{rhods} (RHODS) enables users to integrate data and AI and machine learning software to run end-to-end machine learning workflows. It provides a collection of notebook images with the tools and libraries required to develop and deploy data models. This allows data scientists to easily develop data models, integrate models into applications, and deploy applications using Red Hat OpenShift. RHODS is available as an add-on to Red Hat managed environments such as {osd} and {product-title} (ROSA).
|
||||
{rhods} (RHODS) enables users to integrate data and AI and machine learning software to run end-to-end machine learning workflows. It provides a collection of notebook images with the tools and libraries required to develop and deploy data models. This allows data scientists to easily develop data models, integrate models into applications, and deploy applications using Red{nbsp}Hat OpenShift. RHODS is available as an add-on to Red{nbsp}Hat managed environments such as {osd} and {product-title} (ROSA).
|
||||
|
||||
@@ -16,7 +16,7 @@ You must scale each machine pool separately.
|
||||
|
||||
ifdef::openshift-rosa[]
|
||||
* You installed and configured the latest {product-title} (ROSA) CLI, `rosa`, on your workstation.
|
||||
* You logged in to your Red Hat account using the ROSA CLI (`rosa`).
|
||||
* You logged in to your Red{nbsp}Hat account using the ROSA CLI (`rosa`).
|
||||
* You created a {product-title} (ROSA) cluster.
|
||||
endif::openshift-rosa[]
|
||||
ifndef::openshift-rosa[]
|
||||
|
||||
@@ -6,6 +6,6 @@
|
||||
[id="rosa-sdpolicy-billing_{context}"]
|
||||
= Billing
|
||||
|
||||
{product-title} is billed through Amazon Web Services (AWS) based on the usage of AWS components used by the service, such as load balancers, storage, EC2 instances, other components, and Red Hat subscriptions for the OpenShift service.
|
||||
{product-title} is billed through Amazon Web Services (AWS) based on the usage of AWS components used by the service, such as load balancers, storage, EC2 instances, other components, and Red{nbsp}Hat subscriptions for the OpenShift service.
|
||||
|
||||
Any additional Red Hat software must be purchased separately.
|
||||
Any additional Red{nbsp}Hat software must be purchased separately.
|
||||
@@ -22,7 +22,7 @@ Multiple availability zone clusters require a minimum of 3 control plane nodes,
|
||||
|
||||
All {product-title} clusters support a maximum of 180 worker nodes.
|
||||
|
||||
Control plane and infrastructure nodes are deployed and managed by Red Hat. Shutting down the underlying infrastructure through the cloud provider console is unsupported and can lead to data loss. There are at least 3 control plane nodes that handle etcd- and API-related workloads. There are at least 2 infrastructure nodes that handle metrics, routing, the web console, and other workloads. You must not run any workloads on the control and infrastructure nodes. Any workloads you intend to run must be deployed on worker nodes. See the Red Hat Operator support section below for more information about Red Hat workloads that must be deployed on worker nodes.
|
||||
Control plane and infrastructure nodes are deployed and managed by Red{nbsp}Hat. Shutting down the underlying infrastructure through the cloud provider console is unsupported and can lead to data loss. There are at least 3 control plane nodes that handle etcd- and API-related workloads. There are at least 2 infrastructure nodes that handle metrics, routing, the web console, and other workloads. You must not run any workloads on the control and infrastructure nodes. Any workloads you intend to run must be deployed on worker nodes. See the Red{nbsp}Hat Operator support section below for more information about Red{nbsp}Hat workloads that must be deployed on worker nodes.
|
||||
endif::rosa-with-hcp[]
|
||||
|
||||
[NOTE]
|
||||
|
||||
@@ -12,17 +12,17 @@ endif::[]
|
||||
[id="rosa-limited-support_{context}"]
|
||||
= Limited support status
|
||||
|
||||
When a cluster transitions to a _Limited Support_ status, Red Hat no longer proactively monitors the cluster, the SLA is no longer applicable, and credits requested against the SLA are denied. It does not mean that you no longer have product support. In some cases, the cluster can return to a fully-supported status if you remediate the violating factors. However, in other cases, you might have to delete and recreate the cluster.
|
||||
When a cluster transitions to a _Limited Support_ status, Red{nbsp}Hat no longer proactively monitors the cluster, the SLA is no longer applicable, and credits requested against the SLA are denied. It does not mean that you no longer have product support. In some cases, the cluster can return to a fully-supported status if you remediate the violating factors. However, in other cases, you might have to delete and recreate the cluster.
|
||||
|
||||
A cluster might move to a Limited Support status for many reasons, including the following scenarios:
|
||||
|
||||
ifndef::rosa-with-hcp[]
|
||||
If you do not upgrade a cluster to a supported version before the end-of-life date:: Red Hat does not make any runtime or SLA guarantees for versions after their end-of-life date. To receive continued support, upgrade the cluster to a supported version prior to the end-of-life date. If you do not upgrade the cluster prior to the end-of-life date, the cluster transitions to a Limited Support status until it is upgraded to a supported version.
|
||||
If you do not upgrade a cluster to a supported version before the end-of-life date:: Red{nbsp}Hat does not make any runtime or SLA guarantees for versions after their end-of-life date. To receive continued support, upgrade the cluster to a supported version prior to the end-of-life date. If you do not upgrade the cluster prior to the end-of-life date, the cluster transitions to a Limited Support status until it is upgraded to a supported version.
|
||||
+
|
||||
Red Hat provides commercially reasonable support to upgrade from an unsupported version to a supported version. However, if a supported upgrade path is no longer available, you might have to create a new cluster and migrate your workloads.
|
||||
Red{nbsp}Hat provides commercially reasonable support to upgrade from an unsupported version to a supported version. However, if a supported upgrade path is no longer available, you might have to create a new cluster and migrate your workloads.
|
||||
|
||||
endif::rosa-with-hcp[]
|
||||
If you remove or replace any native {product-title} components or any other component that is installed and managed by Red Hat:: If cluster administrator permissions were used, Red Hat is not responsible for any of your or your authorized users’ actions, including those that affect infrastructure services, service availability, or data loss. If Red Hat detects any such actions, the cluster might transition to a Limited Support status. Red Hat notifies you of the status change and you should either revert the action or create a support case to explore remediation steps that might require you to delete and recreate the cluster.
|
||||
If you remove or replace any native {product-title} components or any other component that is installed and managed by Red{nbsp}Hat:: If cluster administrator permissions were used, Red{nbsp}Hat is not responsible for any of your or your authorized users’ actions, including those that affect infrastructure services, service availability, or data loss. If Red{nbsp}Hat detects any such actions, the cluster might transition to a Limited Support status. Red{nbsp}Hat notifies you of the status change and you should either revert the action or create a support case to explore remediation steps that might require you to delete and recreate the cluster.
|
||||
|
||||
If you have questions about a specific action that might cause a cluster to move to a Limited Support status or need further assistance, open a support ticket.
|
||||
ifeval::["{context}" == "rosa-hcp-service-definition"]
|
||||
|
||||
@@ -17,7 +17,7 @@ ifdef::rosa-with-hcp[]
|
||||
for {hcp-title}.
|
||||
endif::rosa-with-hcp[]
|
||||
ifndef::rosa-with-hcp[]
|
||||
for Red Hat OpenShift 4 and are supported for {product-title}.
|
||||
for Red{nbsp}Hat OpenShift 4 and are supported for {product-title}.
|
||||
endif::rosa-with-hcp[]
|
||||
|
||||
[NOTE]
|
||||
@@ -27,7 +27,7 @@ Regions in China are not supported, regardless of their support on OpenShift 4.
|
||||
|
||||
[NOTE]
|
||||
====
|
||||
For GovCloud (US) regions, you must submit an link:https://console.redhat.com/openshift/create/rosa/govcloud[Access request for Red Hat OpenShift Service on AWS (ROSA) FedRAMP].
|
||||
For GovCloud (US) regions, you must submit an link:https://console.redhat.com/openshift/create/rosa/govcloud[Access request for Red{nbsp}Hat OpenShift Service on AWS (ROSA) FedRAMP].
|
||||
|
||||
GovCloud (US) regions are only supported on ROSA Classic clusters.
|
||||
====
|
||||
|
||||
@@ -7,4 +7,4 @@
|
||||
= Service Level Agreement (SLA)
|
||||
|
||||
//Note for writers: Do not link directly to the appendix 4 PDF, as each PDF is dated at generation and will not be kept up to date.
|
||||
Any SLAs for the service itself are defined in Appendix 4 of the link:https://www.redhat.com/en/about/appendices[Red Hat Enterprise Agreement Appendix 4 (Online Subscription Services)].
|
||||
Any SLAs for the service itself are defined in Appendix 4 of the link:https://www.redhat.com/en/about/appendices[Red{nbsp}Hat Enterprise Agreement Appendix 4 (Online Subscription Services)].
|
||||
@@ -6,7 +6,7 @@
|
||||
[id="rosa-sdpolicy-support_{context}"]
|
||||
= Support
|
||||
|
||||
{product-title} includes Red Hat Premium Support, which can be accessed by using the link:https://access.redhat.com/support?extIdCarryOver=true&sc_cid=701f2000001Css5AAC[Red Hat Customer Portal].
|
||||
{product-title} includes Red{nbsp}Hat Premium Support, which can be accessed by using the link:https://access.redhat.com/support?extIdCarryOver=true&sc_cid=701f2000001Css5AAC[Red{nbsp}Hat Customer Portal].
|
||||
|
||||
See {product-title} link:https://access.redhat.com/support/offerings/openshift/sla?extIdCarryOver=true&sc_cid=701f2000001Css5AAC[SLAs] for support response times.
|
||||
|
||||
|
||||
@@ -40,8 +40,8 @@ ifndef::rosa-with-hcp[]
|
||||
{product-title} uses up to five different load balancers:
|
||||
|
||||
- An internal control plane load balancer that is internal to the cluster and used to balance traffic for internal cluster communications.
|
||||
- An external control plane load balancer that is used for accessing the OpenShift and Kubernetes APIs. This load balancer can be disabled in {cluster-manager}. If this load balancer is disabled, Red Hat reconfigures the API DNS to point to the internal control plane load balancer.
|
||||
- An external control plane load balancer for Red Hat that is reserved for cluster management by Red Hat. Access is strictly controlled, and communication is only possible from whitelisted bastion hosts.
|
||||
- An external control plane load balancer that is used for accessing the OpenShift and Kubernetes APIs. This load balancer can be disabled in {cluster-manager}. If this load balancer is disabled, Red{nbsp}Hat reconfigures the API DNS to point to the internal control plane load balancer.
|
||||
- An external control plane load balancer for Red{nbsp}Hat that is reserved for cluster management by Red{nbsp}Hat. Access is strictly controlled, and communication is only possible from whitelisted bastion hosts.
|
||||
- A default external router/ingress load balancer that is the default application load balancer, denoted by `apps` in the URL. The default load balancer can be configured in {cluster-manager} to be either publicly accessible over the Internet or only privately accessible over a pre-existing private connection. All application routes on the cluster are exposed on this default router load balancer, including cluster services such as the logging UI, metrics API, and registry.
|
||||
- Optional: A secondary router/ingress load balancer that is a secondary application load balancer, denoted by `apps2` in the URL. The secondary load balancer can be configured in {cluster-manager} to be either publicly accessible over the Internet or only privately accessible over a pre-existing private connection. If a `Label match` is configured for this router load balancer, then only application routes matching this label are exposed on this router load balancer; otherwise, all application routes are also exposed on this router load balancer.
|
||||
- Optional: Load balancers for services. Enable non-HTTP/SNI traffic and non-standard ports for services. These load balancers can be mapped to a service running on {product-title} to enable advanced ingress features, such as non-HTTP/SNI traffic or the use of non-standard ports. Each AWS account has a quota which link:https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-limits.html[limits the number of Classic Load Balancers] that can be used within each cluster.
|
||||
@@ -87,7 +87,7 @@ endif::rosa-with-hcp[]
|
||||
|
||||
[IMPORTANT]
|
||||
====
|
||||
Red Hat site reliability engineers (SREs) do not monitor private network connections. Monitoring these connections is the responsibility of the customer.
|
||||
Red{nbsp}Hat site reliability engineers (SREs) do not monitor private network connections. Monitoring these connections is the responsibility of the customer.
|
||||
====
|
||||
|
||||
[id="rosa-sdpolicy-dns-forwarding_{context}"]
|
||||
|
||||
@@ -11,7 +11,7 @@ endif::[]
|
||||
:_mod-docs-content-type: ASSEMBLY
|
||||
[id="rosa-sdpolicy-platform_{context}"]
|
||||
= Platform
|
||||
:productwinc: Red Hat OpenShift support for Windows Containers
|
||||
:productwinc: Red{nbsp}Hat OpenShift support for Windows Containers
|
||||
|
||||
This section provides information about the service definition for the
|
||||
ifdef::rosa-with-hcp[]
|
||||
@@ -26,7 +26,7 @@ endif::rosa-with-hcp[]
|
||||
|
||||
[IMPORTANT]
|
||||
====
|
||||
Red Hat does not provide a backup method for ROSA clusters with STS, which is the default. It is critical that customers have a backup plan for their applications and application data.
|
||||
Red{nbsp}Hat does not provide a backup method for ROSA clusters with STS, which is the default. It is critical that customers have a backup plan for their applications and application data.
|
||||
ifndef::rosa-with-hcp[]
|
||||
The table below only applies to clusters created with IAM user credentials.
|
||||
endif::rosa-with-hcp[]
|
||||
@@ -116,7 +116,7 @@ endif::rosa-with-hcp[]
|
||||
|
||||
[id="rosa-sdpolicy-node-labels_{context}"]
|
||||
== Node labels
|
||||
Custom node labels are created by Red Hat during node creation and cannot be changed on
|
||||
Custom node labels are created by Red{nbsp}Hat during node creation and cannot be changed on
|
||||
ifdef::rosa-with-hcp[]
|
||||
{hcp-title-first}
|
||||
endif::rosa-with-hcp[]
|
||||
@@ -163,15 +163,15 @@ endif::rosa-with-hcp[]
|
||||
ifndef::rosa-with-hcp[]
|
||||
{product-title}
|
||||
endif::rosa-with-hcp[]
|
||||
runs on OpenShift 4 and uses Red Hat CoreOS as the operating system for all control plane and worker nodes.
|
||||
runs on OpenShift 4 and uses Red{nbsp}Hat CoreOS as the operating system for all control plane and worker nodes.
|
||||
|
||||
[id="rosa-sdpolicy-red-hat-operator_{context}"]
|
||||
== Red Hat Operator support
|
||||
Red Hat workloads typically refer to Red Hat-provided Operators made available through Operator Hub. Red Hat workloads are not managed by the Red Hat SRE team, and must be deployed on worker nodes. These Operators may require additional Red Hat subscriptions, and may incur additional cloud infrastructure costs. Examples of these Red Hat-provided Operators are:
|
||||
== Red{nbsp}Hat Operator support
|
||||
Red{nbsp}Hat workloads typically refer to Red{nbsp}Hat-provided Operators made available through Operator Hub. Red{nbsp}Hat workloads are not managed by the Red{nbsp}Hat SRE team, and must be deployed on worker nodes. These Operators may require additional Red{nbsp}Hat subscriptions, and may incur additional cloud infrastructure costs. Examples of these Red{nbsp}Hat-provided Operators are:
|
||||
|
||||
* {rhq-short}
|
||||
* Red Hat Advanced Cluster Management
|
||||
* Red Hat Advanced Cluster Security
|
||||
* Red{nbsp}Hat Advanced Cluster Management
|
||||
* Red{nbsp}Hat Advanced Cluster Security
|
||||
* {SMProductName}
|
||||
* {ServerlessProductName}
|
||||
* {logging-sd}
|
||||
@@ -179,7 +179,7 @@ Red Hat workloads typically refer to Red Hat-provided Operators made available t
|
||||
|
||||
[id="rosa-sdpolicy-kubernetes-operator_{context}"]
|
||||
== Kubernetes Operator support
|
||||
All Operators listed in the OperatorHub marketplace should be available for installation. These Operators are considered customer workloads, and are not monitored by Red Hat SRE.
|
||||
All Operators listed in the OperatorHub marketplace should be available for installation. These Operators are considered customer workloads, and are not monitored by Red{nbsp}Hat SRE.
|
||||
|
||||
ifeval::["{context}" == "rosa-hcp-service-definition"]
|
||||
:!rosa-with-hcp:
|
||||
|
||||
@@ -32,7 +32,7 @@ Authentication for the cluster can be configured using either {cluster-manager-u
|
||||
|
||||
[id="rosa-sdpolicy-privileged-containers_{context}"]
|
||||
== Privileged containers
|
||||
Privileged containers are available for users with the `cluster-admin` role. Usage of privileged containers as `cluster-admin` is subject to the responsibilities and exclusion notes in the link:https://www.redhat.com/en/about/agreements[Red Hat Enterprise Agreement Appendix 4] (Online Subscription Services).
|
||||
Privileged containers are available for users with the `cluster-admin` role. Usage of privileged containers as `cluster-admin` is subject to the responsibilities and exclusion notes in the link:https://www.redhat.com/en/about/agreements[Red{nbsp}Hat Enterprise Agreement Appendix 4] (Online Subscription Services).
|
||||
|
||||
[id="rosa-sdpolicy-customer-admin-user_{context}"]
|
||||
== Customer administrator user
|
||||
@@ -125,7 +125,7 @@ The etcd encryption feature is not enabled by default and it can be enabled only
|
||||
|
||||
[IMPORTANT]
|
||||
====
|
||||
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.
|
||||
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{nbsp}Hat recommends that you enable etcd encryption only if you specifically require it for your use case.
|
||||
====
|
||||
endif::rosa-with-hcp[]
|
||||
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user