Merge pull request #96509 from mletalie/OSDOCS-14103

[OSDOCS-14103]: Review-Introduction to ROSA

Author: mletalie

_topic_maps/_topic_map_rosa_hcp.yml

@@ -440,8 +440,9 @@ Topics:
     File: rosa-troubleshooting-iam-resources
   - Name: Troubleshooting cluster deployments
     File: rosa-troubleshooting-deployments
-  - Name: Red Hat managed resources
-    File: sd-managed-resources
+ # Removed from HCP Topic Map until managed resources are correct for HCP.
+ # - Name: Red Hat managed resources
+ # File: sd-managed-resources
 ---
 Name: Cluster administration
 Dir: rosa_cluster_admin

modules/how-service-accounts-assume-aws-iam-roles-in-sre-owned-projects.adoc

@@ -7,22 +7,29 @@
 [id="how-service-accounts-assume-aws-iam-roles-in-sre-owned-projects_{context}"]
 = How service accounts assume AWS IAM roles in SRE owned projects
 
-When you install a {product-title} cluster that uses the AWS Security Token Service (STS), cluster-specific Operator AWS Identity and Access Management (IAM) roles are created. These IAM roles permit the {product-title} cluster Operators to run core OpenShift functionality.
+When you install a {product-title}
+ifdef::openshift-rosa-hcp[]
+cluster,
+endif::openshift-rosa-hcp[]
+ifndef::openshift-rosa-hcp[]
+that uses the AWS Security Token Service (STS),
+endif::openshift-rosa-hcp[]
+cluster-specific Operator AWS Identity and Access Management (IAM) roles are created. These IAM roles permit the ROSA cluster Operators to run core OpenShift functionality.
 
-Cluster Operators use service accounts to assume IAM roles. When a service account assumes an IAM role, temporary STS credentials are provided for the service account to use in the cluster Operator's pod. If the assumed role has the necessary AWS privileges, the service account can run AWS SDK operations in the pod.
+Cluster Operators use service accounts to assume IAM roles. When a service account assumes an IAM role, temporary AWS STS credentials are provided for the service account to use in the cluster Operator's pod. If the assumed role has the necessary AWS privileges, the service account can run AWS SDK operations in the pod.
 
 [discrete]
 [id="workflow-for-assuming-aws-iam-roles-in-sre-owned-projects_{context}"]
-== Workflow for assuming AWS IAM roles in SRE owned projects
+== Workflow for assuming AWS IAM roles in Red{nbsp}Hat SRE owned projects
 
 The following diagram illustrates the workflow for assuming AWS IAM roles in SRE owned projects:
 
 .Workflow for assuming AWS IAM roles in SRE owned projects
-image::workflow-assuming-aws-iam-roles-sre-owned-projects.png[Workflow for assuming AWS IAM roles in SRE owned projects]
+image::workflow-assuming-aws-iam-roles-sre-owned-projects.png[Workflow for assuming AWS IAM roles in Red{nbsp}Hat SRE owned projects]
 
 The workflow has the following stages:
 
-. Within each project that a cluster Operator runs, the Operator's deployment spec has a volume mount for the projected service account token, and a secret containing AWS credential configuration for the pod. The token is audience-bound and time-bound. Every hour, {product-title} generates a new token, and the AWS SDK reads the mounted secret containing the AWS credential configuration. This configuration has a path to the mounted token and the AWS IAM Role ARN. The secret's credential configuration includes the following:
+. Within each project that a cluster Operator runs, the Operator's deployment spec has a volume mount for the projected service account token, and a secret containing AWS credential configuration for the pod. The token is audience-bound and time-bound. Every hour, ROSA generates a new token, and the AWS SDK reads the mounted secret containing the AWS credential configuration. This configuration has a path to the mounted token and the AWS IAM Role ARN. The secret's credential configuration includes the following:
 
 ** An `$AWS_ARN_ROLE` variable that has the ARN for the IAM role that has the permissions required to run AWS SDK operations.
 
@@ -38,7 +45,7 @@ The workflow has the following stages:
 +
 [NOTE]
 ====
-In {product-title} with STS clusters, the OIDC provider is created during install and set as the service account issuer by default. The `sts.amazonaws.com` audience is set by default in the OIDC provider.
+In ROSA with STS clusters, the OIDC provider is created during install and set as the service account issuer by default. The `sts.amazonaws.com` audience is set by default in the OIDC provider.
 ====
 
 ** The OIDC token has not expired.

modules/life-cycle-limited-support.adoc

@@ -15,11 +15,11 @@ When a cluster transitions to a _Limited Support_ status, Red{nbsp}Hat no longer
 
 A cluster might transition to a Limited Support status for many reasons, including the following scenarios:
 
-ifndef::rosa-with-hcp[]
+ifndef::openshift-rosa-hcp[]
 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{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[]
+endif::openshift-rosa-hcp[]
 
 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.
 

modules/life-cycle-mandatory-upgrades.adoc

@@ -14,12 +14,12 @@ endif::[]
 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{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[]
+ifdef::openshift-rosa-hcp[]
 cluster's control plane
-endif::rosa-with-hcp[]
-ifndef::rosa-with-hcp[]
+endif::openshift-rosa-hcp[]
+ifndef::openshift-rosa-hcp[]
 cluster
-endif::rosa-with-hcp[]
+endif::openshift-rosa-hcp[]
 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"]

modules/life-cycle-minor-versions.adoc

@@ -13,23 +13,23 @@ endif::[]
 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[]
+ifdef::openshift-rosa-hcp[]
 Red{nbsp}Hat will automatically upgrade the control plane to the next supported minor version.
-endif::rosa-with-hcp[]
-ifndef::rosa-with-hcp[]
+endif::openshift-rosa-hcp[]
+ifndef::openshift-rosa-hcp[]
 the cluster will enter a "Limited Support" status.
-endif::rosa-with-hcp[]
+endif::openshift-rosa-hcp[]
 
 .Example
 . A customer's cluster is currently running on 4.13.8. The 4.13 minor version became generally available on May 17, 2023.
 . On July 19, August 16, and September 2, 2024, the customer is notified that their cluster will enter "Limited Support" status on September 17, 2024 if the cluster has not already been upgraded to a supported minor version.
 . The cluster must be upgraded to 4.14 or later by September 17, 2024.
-ifdef::rosa-with-hcp[]
+ifdef::openshift-rosa-hcp[]
 . If the upgrade has not been performed, the cluster's control plane will be automatically upgraded to 4.14.26, and there will be no automatic upgrades to the cluster's worker nodes.
-endif::rosa-with-hcp[]
-ifndef::rosa-with-hcp[]
+endif::openshift-rosa-hcp[]
+ifndef::openshift-rosa-hcp[]
 . If the upgrade has not been performed, the cluster will be flagged as being in a "Limited Support" status.
-endif::rosa-with-hcp[]
+endif::openshift-rosa-hcp[]
 
 ifeval::["{context}" == "rosa-hcp-life-cycle"]
 :!rosa-with-hcp:

modules/life-cycle-overview.adoc

@@ -9,4 +9,4 @@
 
 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{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.
+{product-title} is a managed deployment 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.

modules/managed-cluster-notification-policy.adoc

@@ -13,7 +13,7 @@ Most cluster notifications are generated and sent automatically to ensure that y
 
 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.
+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 Red{nbsp}Hat SRE.
 
 Red{nbsp}Hat services automatically send notifications when:
 

modules/managed-resources.adoc

@@ -15,9 +15,10 @@ The following covers all {product-title} resources that are managed or protected
 [id="sd-managed-resources-all_{context}"]
 == Managed resources
 
-The following list displays the {product-title} resources managed by OpenShift Hive, the centralized fleet configuration management system. These resources are in addition to the OpenShift Container Platform resources created during installation. OpenShift Hive continually attempts to maintain consistency across all {product-title} clusters. Changes to {product-title} resources should be made through {cluster-manager} so that {cluster-manager} and Hive are synchronized. Contact [email protected] if {cluster-manager} does not support modifying the resources in question.
+The following list displays the {product-title} resources managed by OpenShift Hive, the centralized fleet configuration management system. These resources are in addition to the OpenShift/ROSA platform resources created during installation. OpenShift Hive continually reconciles consistency across all {product-title} clusters. Changes to {product-title} resources should be made through {cluster-manager} so that {cluster-manager} and Hive are synchronized. Contact [email protected] if {cluster-manager} does not support modifying the resources in question.
 
 .List of Red{nbsp}Hat managed resources
+(Note that the following may not be visible in your ROSA cluster)
 [%collapsible]
 ====
 [source,yaml]
@@ -32,6 +33,8 @@ include::https://raw.githubusercontent.com/openshift/managed-cluster-config/mast
 {product-title} core namespaces are installed by default during cluster installation.
 
 .List of core namespaces
+(Note that the following may not be visible in your ROSA cluster)
+
 [%collapsible]
 ====
 [source,yaml]

modules/rosa-access-approval-review.adoc

@@ -6,7 +6,7 @@
 
 [id="rosa-policy-access-approval_{context}"]
 = Access approval and review
-New SRE user access requires management approval. Separated or transferred SRE accounts are removed as authorized users through an automated process. Additionally, the SRE performs periodic access review, including management sign-off of authorized user lists.
+New Red{nbsp}Hat SRE user access requires management approval. Separated or transferred SRE accounts are removed as authorized users through an automated process. Additionally, the SRE performs periodic access review, including management sign-off of authorized user lists.
 
 The access and identity authorization table includes responsibilities for managing authorized access to clusters, applications, and infrastructure resources. This includes tasks such as providing access control mechanisms, authentication, authorization, and managing access to resources.
 
@@ -73,7 +73,14 @@ Red{nbsp}Hat OpenShift Cluster Manager.
 |AWS software (public AWS services)
 |**AWS**
 
-**Compute:** Provide the Amazon EC2 service, used for ROSA control plane, infrastructure, and worker nodes.
+**Compute:**
+Provide the Amazon EC2 service,
+ifdef::openshift-rosa-hcp[]
+used for ROSA control plane and worker nodes.
+endif::openshift-rosa-hcp[]
+ifndef::openshift-rosa-hcp[]
+used for ROSA control plane, infrastructure, and worker nodes.
+endif::openshift-rosa-hcp[]
 
 **Storage:** Provide Amazon EBS, used to allow ROSA to provision local node storage and persistent volume storage for the cluster.
 

modules/rosa-aws-customer-managed-policies.adoc

@@ -17,5 +17,5 @@ Attaching permission boundary policies to IAM roles that restrict ROSA-specific
 [role="_additional-resources"]
 .Additional resources
 
-* xref:../rosa_architecture/rosa-sts-about-iam-resources.adoc#rosa-sts-aws-requirements-attaching-boundary-policy_rosa-sts-about-iam-resources[Permission boundaries for the installer role]
+// * xref:../rosa_architecture/rosa-sts-about-iam-resources.adoc#rosa-sts-aws-requirements-attaching-boundary-policy_rosa-sts-about-iam-resources[Permission boundaries for the installer role]
 * link:https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html[Permissions boundaries for IAM entities]