mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-05 12:46:18 +01:00
ROSA Intro HCP Migration
This commit is contained in:
mletalie
committed by
openshift-cherrypick-robot
openshift-cherrypick-robot
parent
73c2ed6f8a
commit
8685655a0f
@@ -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
|
||||
|
||||
@@ -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.
|
||||
|
||||
@@ -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.
|
||||
|
||||
|
||||
@@ -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"]
|
||||
|
||||
@@ -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:
|
||||
|
||||
@@ -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.
|
||||
|
||||
@@ -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:
|
||||
|
||||
|
||||
@@ -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 ocm-feedback@redhat.com 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 ocm-feedback@redhat.com 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]
|
||||
|
||||
@@ -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.
|
||||
|
||||
|
||||
@@ -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]
|
||||
|
||||
@@ -5,9 +5,9 @@
|
||||
[id="rosa-hcp-architecture_{context}"]
|
||||
= ROSA with HCP architecture
|
||||
|
||||
In {hcp-title-first}, the ROSA service hosts a highly-available, single-tenant OpenShift control plane. The hosted control plane is deployed across 3 availability zones with 2 API server instances and 3 etcd instances.
|
||||
In {hcp-title-first}, the ROSA service hosts a highly-available, single-tenant OpenShift control plane. The hosted control plane is deployed across 3 availability zones with 2 API server instances and 3 etcd instances.
|
||||
|
||||
You can create a ROSA with HCP cluster with or without an internet-facing API server. Private API servers are only accessible from your VPC subnets. You access the hosted control plane through an AWS PrivateLink endpoint.
|
||||
You can create a ROSA with HCP cluster with or without an internet-facing API server, with the latter considered a “private” cluster and the former considered a “public” cluster. Private API servers are only accessible from your VPC subnets. You access the hosted control plane through an AWS PrivateLink endpoint regardless of API privacy.
|
||||
|
||||
The worker nodes are deployed in your AWS account and run on your VPC private subnets. You can add additional private subnets from one or more availability zones to ensure high availability. Worker nodes are shared by OpenShift components and applications. OpenShift components such as the ingress controller, image registry, and monitoring are deployed on the worker nodes hosted on your VPC.
|
||||
|
||||
|
||||
@@ -48,9 +48,9 @@ Red{nbsp}Hat site reliability engineering (SRE) manages the infrastructure, code
|
||||
|
||||
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.
|
||||
|
||||
An authorized SRE reviewer must approve advancement to each step. The reviewer cannot be the same individual who proposed the change. All changes and approvals are fully auditable as part of the GitOps workflow.
|
||||
An authorized Red{nbsp}Hat SRE reviewer must approve advancement to each step. The reviewer cannot be the same individual who proposed the change. All changes and approvals are fully auditable as part of the GitOps workflow.
|
||||
|
||||
Some changes are released to production incrementally, using feature flags to control availability of new features to specified clusters or customers.
|
||||
Some changes are released to production incrementally, using feature flags to control availability of new features to specified clusters or customers, such as private or public previews.
|
||||
|
||||
[id="rosa-policy-patch-management_{context}"]
|
||||
== Patch management
|
||||
@@ -64,7 +64,7 @@ Red{nbsp}Hat does not automatically upgrade your clusters. You can schedule to u
|
||||
|
||||
[NOTE]
|
||||
====
|
||||
Because the required permissions can change between y-stream releases, the policies might have to be updated before an upgrade can be performed. Therefore, you cannot schedule a recurring upgrade on ROSA clusters with STS.
|
||||
Because the required permissions can change between y-stream releases, the AWS managed policies are automatically updated before an upgrade can be performed.
|
||||
====
|
||||
|
||||
You can review the history of all cluster upgrade events in the {cluster-manager} web console. For more information about releases, see the link:https://access.redhat.com/support/policy/updates/openshift/dedicated[Life Cycle policy].
|
||||
@@ -72,7 +72,7 @@ You can review the history of all cluster upgrade events in the {cluster-manager
|
||||
[id="rosa-policy-resource-responsibilities_{context}"]
|
||||
== Service and Customer resource responsibilities
|
||||
|
||||
The following table defines the responsibilities for cluster resources.
|
||||
The following table defines the responsibilities for cluster resources.
|
||||
|
||||
[cols="2a,3a,3a",options="header"]
|
||||
|===
|
||||
@@ -102,7 +102,7 @@ The following table defines the responsibilities for cluster resources.
|
||||
|
||||
- Set up native OpenShift router service. Provide the ability to set the router as private and add up to one additional router shard.
|
||||
|
||||
- Install, configure, and maintain OpenShift SDN components for default internal pod traffic (for clusters created prior to version 4.11).
|
||||
- Install, configure, and maintain OVN-Kubernetes components for default internal pod traffic.
|
||||
|
||||
- Provide the ability for the customer to manage `NetworkPolicy` and `EgressNetworkPolicy` (firewall) objects.
|
||||
|
||||
@@ -117,7 +117,8 @@ The following table defines the responsibilities for cluster resources.
|
||||
|
||||
- Set up cluster management components, such as public or private service endpoints and necessary integration with Amazon VPC components.
|
||||
|
||||
- Set up internal networking components required for internal cluster communication between worker, infrastructure, and control plane nodes.
|
||||
- Set up internal networking components required for internal cluster communication between worker
|
||||
clusters and control planes.
|
||||
|
||||
|- Configure your firewall to grant access to the required OpenShift and AWS domains and ports before the cluster is provisioned. For more information, see "AWS firewall prerequisites".
|
||||
- Provide optional non-default IP address ranges for machine CIDR, service CIDR, and pod CIDR if needed through {cluster-manager} when the cluster is provisioned.
|
||||
@@ -165,9 +166,11 @@ machine pool using the OpenShift Cluster Manager or the ROSA CLI (`rosa`).
|
||||
|Capacity management
|
||||
|**Red{nbsp}Hat**
|
||||
|
||||
- Monitor the use of the control plane. Control planes include control plane nodes and infrastructure nodes.
|
||||
|
||||
- Scale and resize control plane nodes to maintain quality of service.
|
||||
- Monitor the use of the control plane.
|
||||
ifndef::openshift-rosa-hcp[]
|
||||
Control planes include control plane nodes and infrastructure nodes.
|
||||
endif::openshift-rosa-hcp[]
|
||||
- Scale and resize control plane to maintain quality of service.
|
||||
|
||||
| - 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.
|
||||
@@ -190,12 +193,11 @@ EFS CSI driver to provision persistent volumes on the cluster.
|
||||
|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, used for ROSA relevant resources.
|
||||
|
||||
**Storage:** Provide Amazon EBS, used by ROSA to provision local node storage and persistent volume storage for the cluster.
|
||||
|
||||
**Storage:** Provide Amazon S3, used for the ROSA service's
|
||||
**Storage:** Provide Amazon S3, used for the ROSA
|
||||
built-in image registry.
|
||||
|
||||
**Networking:**
|
||||
@@ -206,6 +208,7 @@ infrastructure needs:
|
||||
** Amazon VPC
|
||||
** Elastic Load Balancing
|
||||
** AWS IAM
|
||||
** AWS STS
|
||||
|
||||
**Networking:**
|
||||
Provide the following AWS services, which customers can optionally integrate with ROSA:
|
||||
|
||||
@@ -6,13 +6,13 @@
|
||||
= Disaster recovery
|
||||
Disaster recovery includes data and configuration backup, replicating data and configuration to the disaster recovery environment, and failover on disaster events.
|
||||
|
||||
{product-title} (ROSA) provides disaster recovery for failures that occur at the pod, worker node, infrastructure node, control plane node, and availability zone levels.
|
||||
{product-title} (ROSA) provides disaster recovery for failures that occur at the pod, node, and availability zone levels.
|
||||
|
||||
All disaster recovery requires that the customer use best practices for deploying highly available applications, storage, and cluster architecture, such as single-zone deployment or multi-zone deployment, to account for the level of desired availability.
|
||||
All disaster recovery requires that the customer use best practices for deploying highly available applications, storage, and cluster architecture, such as multiple machine pools across multiple availability zones, to account for the level of desired availability.
|
||||
|
||||
One single-zone cluster will not provide disaster avoidance or recovery in the event of an availability zone or region outage. Multiple single-zone clusters with customer-maintained failover can account for outages at the zone or at the regional level.
|
||||
One cluster with a single machine pool will not provide disaster avoidance or recovery in the event of an availability zone or region outage. Multiple clusters with single machine pools with customer-maintained failover can account for outages at the zone or at the regional level.
|
||||
|
||||
One multi-zone cluster will not provide disaster avoidance or recovery in the event of a full region outage. Multiple multi-zone clusters with customer-maintained failover can account for outages at the regional level.
|
||||
One cluster with multiple machine pools across multiple availability zones will not provide disaster avoidance or recovery in the event of a full region outage. Multiple clusters in several regions with multiple machine pools in more than one availability-zone with customer-maintained failover can account for outages at the regional level.
|
||||
|
||||
[cols="2a,3a,3a" ,options="header"]
|
||||
|===
|
||||
@@ -23,23 +23,23 @@ One multi-zone cluster will not provide disaster avoidance or recovery in the ev
|
||||
|Virtual networking management
|
||||
|**Red{nbsp}Hat**
|
||||
|
||||
- Restore or recreate affected virtual network components that are necessary for the platform to function.
|
||||
- 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.
|
||||
|
||||
//waiting to hear back from Will G. if RH responsibilities below should have just been conditionalized out per the migration review for hcp or Classic as well.
|
||||
|Virtual Storage management
|
||||
|**Red{nbsp}Hat**
|
||||
|
||||
ifdef::openshift-rosa[]
|
||||
- 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).
|
||||
|
||||
endif::openshift-rosa[]
|
||||
|
||||
|- Back up customer applications and application data.
|
||||
|
||||
|Virtual compute management
|
||||
|**Red{nbsp}Hat**
|
||||
|
||||
ifdef::openshift-rosa[]
|
||||
- Monitor the cluster and replace failed Amazon EC2 control plane or infrastructure nodes.
|
||||
|
||||
endif::openshift-rosa[]
|
||||
- Provide the ability for the customer to manually or automatically replace failed worker nodes.
|
||||
|
||||
|- Replace failed Amazon EC2 worker nodes by editing the
|
||||
@@ -58,11 +58,7 @@ and customers to back up the Amazon EBS volume on the cluster through Amazon EBS
|
||||
**Networking:** For information about Amazon VPC features that support data resiliency, see link:https://docs.aws.amazon.com/vpc/latest/userguide/disaster-recovery-resiliency.html[Resilience in Amazon Virtual Private
|
||||
Cloud] in the Amazon VPC User Guide.
|
||||
|
||||
|- Configure ROSA
|
||||
multi-AZ clusters to
|
||||
improve fault
|
||||
tolerance and cluster
|
||||
availability.
|
||||
|- Configure ROSA clusters with multiple machine pools across multiple availability zones to improve fault tolerance and cluster availability.
|
||||
|
||||
- Provision persistent
|
||||
volumes using the
|
||||
@@ -75,12 +71,19 @@ EBS persistent volumes.
|
||||
|Hardware/AWS global infrastructure
|
||||
|**AWS**
|
||||
|
||||
- Provide AWS global infrastructure that allows ROSA to scale control plane, infrastructure, and worker nodes across
|
||||
- Provide AWS global infrastructure that allows ROSA to scale
|
||||
ifdef::openshift-rosa[]
|
||||
control plane, infrastructure, and worker nodes
|
||||
endif::openshift-rosa[]
|
||||
ifdef::openshift-rosa-hcp[]
|
||||
nodes
|
||||
endif::openshift-rosa-hcp[]
|
||||
across
|
||||
Availability Zones. This functionality enables ROSA to orchestrate automatic failover between zones without interruption.
|
||||
|
||||
- For more information about disaster recovery best practices, see link:https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-options-in-the-cloud.html[Disaster recovery options in the cloud] in the AWS
|
||||
Well-Architected Framework.
|
||||
|
||||
|- Configure ROSA multi-AZ clusters to improve fault tolerance and cluster availability.
|
||||
|- Configure ROSA clusters with multiple machine pools across multiple availability zones to improve fault tolerance and cluster availability.
|
||||
|
||||
|===
|
||||
@@ -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{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.
|
||||
ROSA can help further protect you against many common Kubernetes issues given Red{nbsp}Hat site reliability engineering (SRE) support and the option to deploy machine pools into more than one availability zone, 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.
|
||||
|
||||
ifdef::openshift-rosa,openshift-rosa-hcp[]
|
||||
include::snippets/rosa-node-lifecycle.adoc[]
|
||||
@@ -30,7 +30,7 @@ To avoid disruption to your applications during planned maintenance, such as upg
|
||||
|
||||
[id="rosa-policy-worker-node-failure_{context}"]
|
||||
== Worker node failure
|
||||
Worker nodes are the virtual machines that contain your application pods. By default, a ROSA cluster has a minimum of two worker nodes for a single availability-zone cluster. In the event of a worker node failure, pods are relocated to functioning worker nodes, as long as there is enough capacity, until any issue with an existing node is resolved or the node is replaced. More worker nodes means more protection against single-node outages, and ensures proper cluster capacity for rescheduled pods in the event of a node failure.
|
||||
Worker nodes are the virtual machines (VMs) that contain your application pods. By default, a ROSA cluster has a minimum of two worker nodes for a cluster. In the event of a worker node failure, pods are relocated to functioning worker nodes, as long as there is enough capacity, until any issue with an existing node is resolved or the node is replaced. More worker nodes means more protection against single-node outages, and ensures proper cluster capacity for rescheduled pods in the event of a node failure.
|
||||
|
||||
[NOTE]
|
||||
====
|
||||
@@ -51,7 +51,7 @@ endif::openshift-rosa-hcp[]
|
||||
|
||||
[id="rosa-policy-container-zone-failure_{context}"]
|
||||
== Zone failure
|
||||
A zone failure from AWS affects all virtual components, such as worker nodes, block or shared storage, and load balancers that are specific to a single availability zone. To protect against a zone failure, ROSA provides the option for clusters that are distributed across three availability zones, known as multiple availability zone clusters. Existing stateless workloads are redistributed to unaffected zones in the event of an outage, as long as there is enough capacity.
|
||||
A zone failure from AWS affects all virtual components, such as worker nodes, block or shared storage, and load balancers that are specific to a single availability zone. To protect against a zone failure, ROSA provides the option for machine pools that are deployed across three availability zones. Existing stateless workloads are then redistributed to unaffected zones in the event of an outage, as long as there is enough capacity.
|
||||
|
||||
[id="rosa-policy-container-storage-failure_{context}"]
|
||||
== Storage failure
|
||||
|
||||
@@ -24,7 +24,7 @@ service, and respond to alerts.
|
||||
- Report outages to Red{nbsp}Hat and AWS.
|
||||
|
||||
|Cluster networking
|
||||
|**Red Hat**
|
||||
|**Red{nbsp}Hat**
|
||||
|
||||
- Monitor, alert, and address incidents related to cluster DNS, network plugin connectivity between cluster components, and the default Ingress Controller.
|
||||
|- Monitor and address incidents related to optional Ingress Controllers, additional Operators installed through the OperatorHub, and network plugins replacing the default OpenShift CNI plugins.
|
||||
@@ -98,7 +98,7 @@ resilience and continuity of service] in the AWS white paper.
|
||||
|
||||
[id="rosa-policy-platform-monitoring_{context}"]
|
||||
== Platform monitoring
|
||||
Platform audit logs are securely forwarded to a centralized security information and event monitoring (SIEM) system, where they may trigger configured alerts to the SRE team and are also subject to manual review. Audit logs are retained in the SIEM system for one year. Audit logs for a given cluster are not deleted at the time the cluster is deleted.
|
||||
Platform audit logs are securely forwarded to a centralized security information and event monitoring (SIEM) system, where they may trigger configured alerts to the Red{nbsp}Hat SRE team and are also subject to manual review. Audit logs are retained in the SIEM system for one year. Audit logs for a given cluster are not deleted at the time the cluster is deleted.
|
||||
|
||||
[id="rosa-policy-incident-management_{context}"]
|
||||
== Incident management
|
||||
@@ -132,7 +132,7 @@ Red{nbsp}Hat can assist with activities including but not limited to:
|
||||
//== Backup and recovery
|
||||
//All Red Hat OpenShift Service on AWS cluster metadata from OpenShift Cluster Manager is securely backed up by Red Hat. The following table outlines backup and recovery strategies:
|
||||
|
||||
//Verify if the corresponding tables in rosa-sdpolicy-platform.adoc and policy-incident.adoc also need to be updated.
|
||||
//Verify if the corresponding tables in rosa-sdpolicy-platform.adoc and policy-incident.adoc also need to be updated.
|
||||
|
||||
//[cols= "3a,2a,2a,3a",options="header"]
|
||||
|
||||
|
||||
@@ -69,14 +69,35 @@ potential issues and security threats.
|
||||
|AWS software (public AWS services)
|
||||
|**AWS**
|
||||
|
||||
**Compute:** Secure Amazon EC2, used for ROSA control plane, infrastructure, and worker nodes. For more information, see link:https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/infrastructure-security.html[
|
||||
**Compute:** Secure Amazon EC2, used for ROSA
|
||||
used for ROSA
|
||||
ifdef::openshift-rosa[]
|
||||
control plane, infrastructure, and worker nodes.
|
||||
endif::openshift-rosa[]
|
||||
ifdef::openshift-rosa-hcp[]
|
||||
control plane and worker nodes.
|
||||
endif::openshift-rosa-hcp[]
|
||||
For more information, see link:https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/infrastructure-security.html[
|
||||
Infrastructure security in Amazon EC2] in the Amazon EC2 User Guide.
|
||||
|
||||
**Storage:** Secure Amazon Elastic Block Store (EBS),
|
||||
used for ROSA control plane, infrastructure, and worker node volumes, as well as Kubernetes persistent volumes. For more information, see link:https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/data-protection.html[Data protection in Amazon EC2] in the Amazon EC2 User Guide.
|
||||
used for ROSA
|
||||
ifdef::openshift-rosa[]
|
||||
control plane, infrastructure, and worker node volumes,
|
||||
endif::openshift-rosa[]
|
||||
ifdef::openshift-rosa-hcp[]
|
||||
control plane and worker node volumes,
|
||||
endif::openshift-rosa-hcp[]
|
||||
as well as Kubernetes persistent volumes. For more information, see link:https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/data-protection.html[Data protection in Amazon EC2] in the Amazon EC2 User Guide.
|
||||
|
||||
**Storage:** Provide AWS KMS, which ROSA uses to
|
||||
encrypt control plane, infrastructure, and worker node volumes and persistent volumes. For more information, see https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html[Amazon EBS encryption] in the Amazon EC2 User Guide.
|
||||
ifdef::openshift-rosa[]
|
||||
encrypt control plane, infrastructure, worker node volumes and persistent volumes.
|
||||
endif::openshift-rosa[]
|
||||
ifdef::openshift-rosa-hcp[]
|
||||
encrypt control plane, worker node volumes and persistent volumes.
|
||||
endif::openshift-rosa-hcp[]
|
||||
For more information, see https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html[Amazon EBS encryption] in the Amazon EC2 User Guide.
|
||||
|
||||
**Storage:** Secure Amazon S3, used for the ROSA service’s built-in container image registry. For more information, see link:https://docs.aws.amazon.com/AmazonS3/latest/userguide/security.html[Amazon S3 security] in the S3 User Guide.
|
||||
|
||||
|
||||
@@ -37,7 +37,14 @@ AWS customers can configure a private network connection to their ROSA cluster t
|
||||
|
||||
[id="rosa-policy-cluster-network-access_{context}"]
|
||||
=== Cluster network access controls
|
||||
Fine-grained network access control rules can be configured by customers, on a per-project basis, using `NetworkPolicy` objects and the OpenShift SDN.
|
||||
Fine-grained network access control rules can be configured by customers, on a per-project basis, using `NetworkPolicy` objects and the
|
||||
ifdef::openshift-rosa-hcp[]
|
||||
OVN-Kubernetes CNI.
|
||||
endif::openshift-rosa-hcp[]
|
||||
ifndef::openshift-rosa-hcp[]
|
||||
OpenShift SDN.
|
||||
endif::openshift-rosa-hcp[]
|
||||
|
||||
|
||||
[id="rosa-policy-penetration-testing_{context}"]
|
||||
== Penetration testing
|
||||
@@ -49,7 +56,39 @@ Any issues that may be discovered are prioritized based on severity. Any issues
|
||||
== Compliance
|
||||
{product-title} follows common industry best practices for security and controls. The certifications are outlined in the following table.
|
||||
|
||||
ifdef::openshift-rosa-hcp[]
|
||||
.Security and control certifications for {product-title}
|
||||
[cols= "3,3",options="header"]
|
||||
|===
|
||||
| Compliance | {hcp-title-first}
|
||||
|
||||
| HIPAA Qualified^[1]^ | Yes
|
||||
|
||||
| ISO 27001 | Yes
|
||||
|
||||
| ISO 27017 | Yes
|
||||
|
||||
| ISO 27018 | Yes
|
||||
|
||||
| PCI DSS 4.0 | Yes
|
||||
|
||||
| SOC 1 Type 2 | Yes
|
||||
|
||||
| SOC 2 Type 2 | Yes
|
||||
|
||||
| SOC 3 | Yes
|
||||
|
||||
| FedRAMP High^[2]^ | No
|
||||
|
||||
|===
|
||||
1. For more information about Red Hat's HIPAA Qualified ROSA offerings, see the link:https://access.redhat.com/articles/compliance_activities_and_gov_standards#hipaa-overview-13[HIPAA Overview].
|
||||
2. For more information about ROSA on GovCloud, see the link:https://marketplace.fedramp.gov/products/FR2102031769[FedRAMP Marketplace ROSA Agency] and link:https://marketplace.fedramp.gov/products/FR2102031769A[ROSA JAB listings].
|
||||
|
||||
endif::openshift-rosa-hcp[]
|
||||
|
||||
|
||||
|
||||
ifndef::openshift-rosa-hcp[]
|
||||
.Security and control certifications for {product-title}
|
||||
[cols= "3,3,3",options="header"]
|
||||
|===
|
||||
@@ -75,4 +114,6 @@ Any issues that may be discovered are prioritized based on severity. Any issues
|
||||
|
||||
|===
|
||||
1. For more information about Red Hat's HIPAA Qualified ROSA offerings, see the link:https://access.redhat.com/articles/compliance_activities_and_gov_standards#hipaa-overview-13[HIPAA Overview].
|
||||
2. For more information about ROSA on GovCloud, see the link:https://marketplace.fedramp.gov/products/FR2102031769[FedRAMP Marketplace ROSA Agency] and link:https://marketplace.fedramp.gov/products/FR2102031769A[ROSA JAB listings].
|
||||
2. For more information about ROSA on GovCloud, see the link:https://marketplace.fedramp.gov/products/FR2102031769[FedRAMP Marketplace ROSA Agency] and link:https://marketplace.fedramp.gov/products/FR2102031769A[ROSA JAB listings].
|
||||
|
||||
endif::openshift-rosa-hcp[]
|
||||
@@ -16,12 +16,12 @@ When a cluster transitions to a _Limited Support_ status, Red{nbsp}Hat no longer
|
||||
|
||||
A cluster might move 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 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{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.
|
||||
|
||||
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.
|
||||
|
||||
@@ -13,12 +13,12 @@ endif::[]
|
||||
[id="rosa-sdpolicy-am-local-zones_{context}"]
|
||||
= Local Zones
|
||||
|
||||
ifdef::rosa-with-hcp[]
|
||||
ifdef::openshift-rosa-hcp[]
|
||||
{hcp-title-first} does not support the use of AWS Local Zones.
|
||||
endif::rosa-with-hcp[]
|
||||
ifndef::rosa-with-hcp[]
|
||||
endif::openshift-rosa-hcp[]
|
||||
ifndef::openshift-rosa-hcp[]
|
||||
{product-title} supports the use of AWS Local Zones, which are metropolis-centralized availability zones where customers can place latency-sensitive application workloads. Local Zones are extensions of AWS Regions that have their own internet connection. For more information about AWS Local Zones, see the AWS documentation link:https://docs.aws.amazon.com/local-zones/latest/ug/how-local-zones-work.html[How Local Zones work].
|
||||
endif::rosa-with-hcp[]
|
||||
endif::openshift-rosa-hcp[]
|
||||
|
||||
ifeval::["{context}" == "rosa-hcp-service-definition"]
|
||||
:!rosa-with-hcp:
|
||||
|
||||
@@ -13,23 +13,22 @@ endif::[]
|
||||
= Regions and availability zones
|
||||
|
||||
The following AWS regions are currently available
|
||||
ifdef::rosa-with-hcp[]
|
||||
ifdef::openshift-rosa-hcp[]
|
||||
for {hcp-title}.
|
||||
endif::rosa-with-hcp[]
|
||||
ifndef::rosa-with-hcp[]
|
||||
endif::openshift-rosa-hcp[]
|
||||
ifndef::openshift-rosa-hcp[]
|
||||
for Red{nbsp}Hat OpenShift 4 and are supported for {product-title}.
|
||||
endif::rosa-with-hcp[]
|
||||
endif::openshift-rosa-hcp[]
|
||||
|
||||
[NOTE]
|
||||
====
|
||||
Regions in China are not supported, regardless of their support on OpenShift 4.
|
||||
Regions in China are not supported, regardless of their support on OpenShift Container Platform.
|
||||
====
|
||||
|
||||
[NOTE]
|
||||
====
|
||||
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.
|
||||
====
|
||||
|
||||
.AWS regions
|
||||
@@ -50,12 +49,12 @@ GovCloud (US) regions are only supported on ROSA Classic clusters.
|
||||
|4.14
|
||||
|No
|
||||
|
||||
ifndef::rosa-with-hcp[]
|
||||
ifndef::openshift-rosa-hcp[]
|
||||
|us-west-1
|
||||
|N. California
|
||||
|4.14
|
||||
|No
|
||||
endif::rosa-with-hcp[]
|
||||
endif::openshift-rosa-hcp[]
|
||||
|
||||
|us-west-2
|
||||
|Oregon
|
||||
@@ -87,12 +86,12 @@ endif::rosa-with-hcp[]
|
||||
|4.14
|
||||
|Yes
|
||||
|
||||
ifdef::rosa-with-hcp[]
|
||||
ifdef::openshift-rosa-hcp[]
|
||||
|ap-southeast-5
|
||||
|Malaysia
|
||||
|4.16.34; 4.17.15
|
||||
|Yes
|
||||
endif::rosa-with-hcp[]
|
||||
endif::openshift-rosa-hcp[]
|
||||
|
||||
|ap-south-1
|
||||
|Mumbai
|
||||
@@ -194,7 +193,7 @@ endif::rosa-with-hcp[]
|
||||
|4.14
|
||||
|Yes
|
||||
|
||||
ifndef::rosa-with-hcp[]
|
||||
ifndef::openshift-rosa-hcp[]
|
||||
|us-gov-east-1
|
||||
|AWS GovCloud - US-East
|
||||
|4.14
|
||||
@@ -204,40 +203,40 @@ ifndef::rosa-with-hcp[]
|
||||
|AWS GovCloud - US-West
|
||||
|4.14
|
||||
|No
|
||||
endif::rosa-with-hcp[]
|
||||
endif::openshift-rosa-hcp[]
|
||||
|===
|
||||
|
||||
Multiple availability zone clusters can only be deployed in regions with at least 3 availability zones. For more information, see the link:https://aws.amazon.com/about-aws/global-infrastructure/regions_az/[Regions and Availability Zones] section in the AWS documentation.
|
||||
Clusters can only be deployed in regions with at least 3 availability zones. For more information, see the link:https://aws.amazon.com/about-aws/global-infrastructure/regions_az/[Regions and Availability Zones] section in the AWS documentation.
|
||||
|
||||
Each new
|
||||
ifndef::rosa-with-hcp[]
|
||||
ifndef::openshift-rosa-hcp[]
|
||||
{product-title}
|
||||
endif::rosa-with-hcp[]
|
||||
ifdef::rosa-with-hcp[]
|
||||
endif::openshift-rosa-hcp[]
|
||||
ifdef::openshift-rosa-hcp[]
|
||||
{hcp-title}
|
||||
endif::rosa-with-hcp[]
|
||||
endif::openshift-rosa-hcp[]
|
||||
cluster is installed within
|
||||
ifdef::rosa-with-hcp[]
|
||||
ifdef::openshift-rosa-hcp[]
|
||||
a
|
||||
endif::rosa-with-hcp[]
|
||||
ifndef::rosa-with-hcp[]
|
||||
endif::openshift-rosa-hcp[]
|
||||
ifndef::openshift-rosa-hcp[]
|
||||
an installer-created or
|
||||
endif::rosa-with-hcp[]
|
||||
endif::openshift-rosa-hcp[]
|
||||
preexisting Virtual Private Cloud (VPC) in a single region, with the option to deploy
|
||||
ifndef::rosa-with-hcp[]
|
||||
ifndef::openshift-rosa-hcp[]
|
||||
into a single availability zone (Single-AZ) or across multiple availability zones (Multi-AZ).
|
||||
endif::rosa-with-hcp[]
|
||||
ifdef::rosa-with-hcp[]
|
||||
endif::openshift-rosa-hcp[]
|
||||
ifdef::openshift-rosa-hcp[]
|
||||
up to the total number of availability zones for the given region.
|
||||
endif::rosa-with-hcp[]
|
||||
endif::openshift-rosa-hcp[]
|
||||
This provides cluster-level network and resource isolation, and enables cloud-provider VPC settings, such as VPN connections and VPC Peering. Persistent volumes (PVs) are backed by Amazon Elastic Block Storage (Amazon EBS), and are specific to the availability zone in which they are provisioned. Persistent volume claims (PVCs) do not bind to a volume until the associated pod resource is assigned into a specific availability zone to prevent unschedulable pods. Availability zone-specific resources are only usable by resources in the same availability zone.
|
||||
|
||||
[WARNING]
|
||||
====
|
||||
The region
|
||||
ifndef::rosa-with-hcp[]
|
||||
ifndef::openshift-rosa-hcp[]
|
||||
and the choice of single or multiple availability zone
|
||||
endif::rosa-with-hcp[]
|
||||
endif::openshift-rosa-hcp[]
|
||||
cannot be changed after a cluster has been deployed.
|
||||
====
|
||||
|
||||
|
||||
@@ -12,10 +12,10 @@ endif::[]
|
||||
[id="rosa-sdpolicy-instance-types_{context}"]
|
||||
= Instance types
|
||||
|
||||
ifdef::rosa-with-hcp[]
|
||||
All {hcp-title} clusters require a minimum of 2 worker nodes. Shutting down the underlying infrastructure through the cloud provider console is unsupported and can lead to data loss.
|
||||
endif::rosa-with-hcp[]
|
||||
ifndef::rosa-with-hcp[]
|
||||
ifdef::openshift-rosa-hcp[]
|
||||
All {hcp-title} clusters require a minimum of 2 worker nodes. Shutting down the underlying (EC2 instance) infrastructure through the cloud provider console is unsupported and can lead to data loss and other risks.
|
||||
endif::openshift-rosa-hcp[]
|
||||
ifndef::openshift-rosa-hcp[]
|
||||
Single availability zone clusters require a minimum of 3 control plane nodes, 2 infrastructure nodes, and 2 worker nodes deployed to a single availability zone.
|
||||
|
||||
Multiple availability zone clusters require a minimum of 3 control plane nodes, 3 infrastructure nodes, and 3 worker nodes.
|
||||
@@ -36,13 +36,13 @@ Shutting down the underlying infrastructure through the cloud provider console i
|
||||
====
|
||||
|
||||
See the following Red{nbsp}Hat Operator support section for more information about Red{nbsp}Hat workloads that must be deployed on worker nodes.
|
||||
endif::rosa-with-hcp[]
|
||||
endif::openshift-rosa-hcp[]
|
||||
|
||||
[NOTE]
|
||||
====
|
||||
Approximately one vCPU core and 1 GiB of memory are reserved on each worker node and removed from allocatable resources. This reservation of resources is necessary to run processes required by the underlying platform. These processes include system daemons such as udev, kubelet, and container runtime among others. The reserved resources also account for kernel reservations.
|
||||
|
||||
{OCP} core systems such as audit log aggregation, metrics collection, DNS, image registry, SDN, and others might consume additional allocatable resources to maintain the stability and maintainability of the cluster. The additional resources consumed might vary based on usage.
|
||||
OpenShift/ROSA core systems such as audit log aggregation, metrics collection, DNS, image registry, CNI/OVN-Kubernetes, and others might consume additional allocatable resources to maintain the stability and maintainability of the cluster. The additional resources consumed might vary based on usage.
|
||||
|
||||
For additional information, see the link:https://kubernetes.io/docs/tasks/administer-cluster/reserve-compute-resources/#system-reserved[Kubernetes documentation].
|
||||
====
|
||||
|
||||
@@ -13,7 +13,7 @@ This section provides information about the service definition for {product-titl
|
||||
== Cluster metrics
|
||||
|
||||
|
||||
{product-title} clusters come with an integrated Prometheus stack for cluster monitoring including CPU, memory, and network-based metrics. This is accessible through the web console. These metrics also allow for horizontal pod autoscaling based on CPU or memory metrics provided by an {product-title} user.
|
||||
{product-title} clusters come with an integrated Prometheus stack for cluster monitoring including CPU, memory, and network-based metrics. This is accessible through the web console. These metrics also allow for horizontal pod autoscaling based on CPU or memory metrics provided by a ROSA user.
|
||||
|
||||
[id="rosa-sdpolicy-cluster-status-notifications_{context}"]
|
||||
== Cluster notifications
|
||||
|
||||
@@ -11,32 +11,32 @@ endif::[]
|
||||
[id="rosa-sdpolicy-networking_{context}"]
|
||||
= Networking
|
||||
|
||||
This section provides information about the service definition for {product-title} networking.
|
||||
This section provides information about the service definition for ROSA networking.
|
||||
|
||||
[id="rosa-sdpolicy-custom-domains_{context}"]
|
||||
== Custom domains for applications
|
||||
|
||||
[WARNING]
|
||||
====
|
||||
Starting with {product-title} 4.14, the Custom Domain Operator is deprecated. To manage Ingress in {product-title} 4.14 or later, use the Ingress Operator. The functionality is unchanged for {product-title} 4.13 and earlier versions.
|
||||
Starting with {product-title} 4.14, the Custom Domain Operator is deprecated. To manage Ingress in ROSA 4.14 or later, use the Ingress Operator.
|
||||
====
|
||||
To use a custom hostname for a route, you must update your DNS provider by creating a canonical name (CNAME) record. Your CNAME record should map the OpenShift canonical router hostname to your custom domain. The OpenShift canonical router hostname is shown on the _Route Details_ page after a route is created. Alternatively, a wildcard CNAME record can be created once to route all subdomains for a given hostname to the cluster's router.
|
||||
|
||||
[id="rosa-sdpolicy-validated-certificates_{context}"]
|
||||
== Domain validated certificates
|
||||
{product-title} includes TLS security certificates needed for both internal and external services on the cluster. For external routes, there are two separate TLS wildcard certificates that are provided and installed on each cluster: one is for the web console and route default hostnames, and the other is for the API endpoint. Let’s Encrypt is the certificate authority used for certificates. Routes within the cluster, such as the internal link:https://kubernetes.io/docs/tasks/access-application-cluster/access-cluster/#accessing-the-api-from-a-pod[API endpoint], use TLS certificates signed by the cluster's built-in certificate authority and require the CA bundle available in every pod for trusting the TLS certificate.
|
||||
ROSA includes TLS security certificates needed for both internal and external services on the cluster. For external routes, there are two separate TLS wildcard certificates that are provided and installed on each cluster: one is for the web console and route default hostnames, and the other is for the API endpoint. Let’s Encrypt is the certificate authority used for certificates. Routes within the cluster, such as the internal link:https://kubernetes.io/docs/tasks/access-application-cluster/access-cluster/#accessing-the-api-from-a-pod[API endpoint], use TLS certificates signed by the cluster's built-in certificate authority and require the CA bundle available in every pod for trusting the TLS certificate.
|
||||
|
||||
[id="rosa-sdpolicy-custom-certificates_{context}"]
|
||||
== Custom certificate authorities for builds
|
||||
{product-title} supports the use of custom certificate authorities to be trusted by builds when pulling images from an image registry.
|
||||
ROSA supports the use of custom certificate authorities to be trusted by builds when pulling images from an image registry.
|
||||
|
||||
[id="rosa-sdpolicy-load-balancers_{context}"]
|
||||
== Load balancers
|
||||
|
||||
ifdef::rosa-with-hcp[]
|
||||
{hcp-title-first} only deploys load balancers from the default ingress controller. All other load balancers can be optionally deployed by a customer for secondary ingress controllers or Service load balancers.
|
||||
endif::rosa-with-hcp[]
|
||||
ifndef::rosa-with-hcp[]
|
||||
ifdef::openshift-rosa-hcp[]
|
||||
{hcp-title-first} only deploys load balancers from the default ingress controller. All other load balancers can be optionally deployed by a customer for secondary ingress controllers or service load balancers.
|
||||
endif::openshift-rosa-hcp[]
|
||||
ifndef::openshift-rosa-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.
|
||||
@@ -45,7 +45,7 @@ ifndef::rosa-with-hcp[]
|
||||
- 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.
|
||||
endif::rosa-with-hcp[]
|
||||
endif::openshift-rosa-hcp[]
|
||||
|
||||
|
||||
[id="rosa-sdpolicy-cluster-ingress_{context}"]
|
||||
@@ -59,10 +59,10 @@ All cluster ingress traffic will go through the defined load balancers. Direct a
|
||||
[id="rosa-sdpolicy-cluster-egress_{context}"]
|
||||
== Cluster egress
|
||||
Pod egress traffic control through `EgressNetworkPolicy` objects can be used to prevent or limit outbound traffic in
|
||||
ifdef::rosa-with-hcp[]
|
||||
{hcp-title-first}.
|
||||
endif::rosa-with-hcp[]
|
||||
ifndef::rosa-with-hcp[]
|
||||
ifdef::openshift-rosa-hcp[]
|
||||
ROSA with hosted control planes (HCP).
|
||||
endif::openshift-rosa-hcp[]
|
||||
ifndef::openshift-rosa-hcp[]
|
||||
{product-title}.
|
||||
|
||||
Public outbound traffic from the control plane and infrastructure nodes is required and necessary to maintain cluster image security and cluster monitoring. This requires that the `0.0.0.0/0` route belongs only to the Internet gateway; it is not possible to route this range over private connections.
|
||||
@@ -74,7 +74,7 @@ Customers can determine their public static IP addresses by running a pod on the
|
||||
----
|
||||
$ oc run ip-lookup --image=busybox -i -t --restart=Never --rm -- /bin/sh -c "/bin/nslookup -type=a myip.opendns.com resolver1.opendns.com | grep -E 'Address: [0-9.]+'"
|
||||
----
|
||||
endif::rosa-with-hcp[]
|
||||
endif::openshift-rosa-hcp[]
|
||||
|
||||
[id="rosa-sdpolicy-cloud-network-config_{context}"]
|
||||
== Cloud network configuration
|
||||
@@ -87,17 +87,17 @@ endif::rosa-with-hcp[]
|
||||
|
||||
[IMPORTANT]
|
||||
====
|
||||
Red{nbsp}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 of these connections is the responsibility of the customer.
|
||||
====
|
||||
|
||||
[id="rosa-sdpolicy-dns-forwarding_{context}"]
|
||||
== DNS forwarding
|
||||
For {product-title} clusters that have a private cloud network configuration, a customer can specify internal DNS servers available on that private connection, that should be queried for explicitly provided domains.
|
||||
For ROSA clusters that have a private cloud network configuration, a customer can specify internal DNS servers available on that private connection that should be queried for explicitly provided domains.
|
||||
|
||||
[id="rosa-sdpolicy-network-verification_{context}"]
|
||||
== Network verification
|
||||
|
||||
Network verification checks run automatically when you deploy a {product-title} cluster into an existing Virtual Private Cloud (VPC) or create an additional machine pool with a subnet that is new to your cluster. The checks validate your network configuration and highlight errors, enabling you to resolve configuration issues prior to deployment.
|
||||
Network verification checks run automatically when you deploy a ROSA cluster into an existing Virtual Private Cloud (VPC) or create an additional machine pool with a subnet that is new to your cluster. The checks validate your network configuration and highlight errors, enabling you to resolve configuration issues prior to deployment.
|
||||
|
||||
You can also run the network verification checks manually to validate the configuration for an existing cluster.
|
||||
|
||||
|
||||
@@ -28,17 +28,12 @@ ifndef::openshift-rosa-hcp[]
|
||||
endif::openshift-rosa-hcp[]
|
||||
You can configure the autoscaler option to automatically scale the number of machines in a cluster.
|
||||
|
||||
ifdef::openshift-rosa[]
|
||||
[id="rosa-sdpolicy-daemonsets_{context}"]
|
||||
== Daemonsets
|
||||
|
||||
Customers can create and run daemonsets on
|
||||
ifdef::openshift-rosa-hcp[]
|
||||
{hcp-title}.
|
||||
endif::openshift-rosa-hcp[]
|
||||
ifndef::openshift-rosa-hcp[]
|
||||
{product-title}.
|
||||
endif::openshift-rosa-hcp[]
|
||||
To restrict daemonsets to only running on worker nodes, use the following `nodeSelector`:
|
||||
Customers can create and run daemonsets on{product-title}.
|
||||
To restrict daemonsets to only running on worker nodes, use the following `nodeSelector`:
|
||||
|
||||
[source,yaml]
|
||||
----
|
||||
@@ -46,7 +41,7 @@ spec:
|
||||
nodeSelector:
|
||||
role: worker
|
||||
----
|
||||
|
||||
endif::openshift-rosa[]
|
||||
[id="rosa-sdpolicy-multiple-availability-zone_{context}"]
|
||||
== Multiple availability zone
|
||||
|
||||
@@ -109,7 +104,14 @@ endif::openshift-rosa-hcp[]
|
||||
ifndef::openshift-rosa-hcp[]
|
||||
{product-title}
|
||||
endif::openshift-rosa-hcp[]
|
||||
is run as a service and is kept up to date with the latest OpenShift Container Platform version. Upgrade scheduling to the latest version is available.
|
||||
ifdef::openshift-rosa-hcp[]
|
||||
is run as a service. Red{nbsp}Hat SRE team will force upgrade when end of life (EOL) is reached.
|
||||
endif::openshift-rosa-hcp[]
|
||||
ifdef::openshift-rosa[]
|
||||
is run as a service and is kept up to date with
|
||||
the latest OpenShift Container Platform version.
|
||||
endif::openshift-rosa[]
|
||||
Upgrade scheduling to the latest version is available.
|
||||
|
||||
[id="rosa-sdpolicy-upgrades_{context}"]
|
||||
== Upgrades
|
||||
@@ -120,6 +122,9 @@ See the link:https://docs.openshift.com/rosa/rosa_policy/rosa-life-cycle.html[{p
|
||||
[id="rosa-sdpolicy-window-containers_{context}"]
|
||||
== Windows Containers
|
||||
{productwinc} is not available on {product-title} at this time.
|
||||
ifdef::openshift-rosa-hcp[]
|
||||
Alternatively, it is supported to run Windows based virtual machines on OpenShift Virtualization running on a ROSA cluster.
|
||||
endif::openshift-rosa-hcp[]
|
||||
|
||||
[id="rosa-sdpolicy-container-engine_{context}"]
|
||||
== Container engine
|
||||
@@ -129,8 +134,10 @@ endif::openshift-rosa-hcp[]
|
||||
ifndef::openshift-rosa-hcp[]
|
||||
{product-title}
|
||||
endif::openshift-rosa-hcp[]
|
||||
runs on OpenShift 4 and uses link:https://www.redhat.com/en/blog/red-hat-openshift-container-platform-4-now-defaults-cri-o-underlying-container-engine[CRI-O] as the only available container engine.
|
||||
|
||||
runs on OpenShift 4 and uses link:https://www.redhat.com/en/blog/red-hat-openshift-container-platform-4-now-defaults-cri-o-underlying-container-engine[CRI-O] as the only available container engine
|
||||
ifdef::openshift-rosa-hcp[]
|
||||
(container runtime interface).
|
||||
endif::openshift-rosa-hcp[]
|
||||
[id="rosa-sdpolicy-operating-system_{context}"]
|
||||
== Operating system
|
||||
ifdef::openshift-rosa-hcp[]
|
||||
@@ -139,7 +146,7 @@ endif::openshift-rosa-hcp[]
|
||||
ifndef::openshift-rosa-hcp[]
|
||||
{product-title}
|
||||
endif::openshift-rosa-hcp[]
|
||||
runs on OpenShift 4 and uses Red{nbsp}Hat CoreOS as the operating system for all control plane and worker nodes.
|
||||
runs on OpenShift 4 and uses Red{nbsp}Hat CoreOS (RHCOS) as the operating system for all cluster nodes.
|
||||
|
||||
[id="rosa-sdpolicy-red-hat-operator_{context}"]
|
||||
== Red{nbsp}Hat Operator support
|
||||
@@ -152,7 +159,8 @@ Red{nbsp}Hat workloads typically refer to Red{nbsp}Hat-provided Operators made a
|
||||
* {ServerlessProductName}
|
||||
* {logging-sd}
|
||||
* {pipelines-title}
|
||||
* {VirtProductName}
|
||||
|
||||
[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{nbsp}Hat SRE.
|
||||
All Operators listed in the OperatorHub marketplace should be available for installation. These Operators are considered customer workloads, and are not monitored nor managed by by Red{nbsp}Hat SRE. Operators authored by Red{nbsp}Hat are supported by Red{nbsp}Hat.
|
||||
|
||||
@@ -11,12 +11,12 @@ endif::[]
|
||||
= Security
|
||||
|
||||
This section provides information about the service definition for
|
||||
ifdef::rosa-with-hcp[]
|
||||
ifdef::openshift-rosa-hcp[]
|
||||
{hcp-title-first}
|
||||
endif::rosa-with-hcp[]
|
||||
ifndef::rosa-with-hcp[]
|
||||
endif::openshift-rosa-hcp[]
|
||||
ifndef::openshift-rosa-hcp[]
|
||||
{product-title}
|
||||
endif::rosa-with-hcp[]
|
||||
endif::openshift-rosa-hcp[]
|
||||
security.
|
||||
|
||||
[id="rosa-sdpolicy-auth-provider_{context}"]
|
||||
@@ -37,19 +37,19 @@ Privileged containers are available for users with the `cluster-admin` role. Usa
|
||||
[id="rosa-sdpolicy-customer-admin-user_{context}"]
|
||||
== Customer administrator user
|
||||
In addition to normal users,
|
||||
ifdef::rosa-with-hcp[]
|
||||
ifdef::openshift-rosa-hcp[]
|
||||
{hcp-title-first}
|
||||
endif::rosa-with-hcp[]
|
||||
ifndef::rosa-with-hcp[]
|
||||
endif::openshift-rosa-hcp[]
|
||||
ifndef::openshift-rosa-hcp[]
|
||||
{product-title}
|
||||
endif::rosa-with-hcp[]
|
||||
provides access to an
|
||||
ifdef::rosa-with-hcp[]
|
||||
endif::openshift-rosa-hcp[]
|
||||
provides access to a
|
||||
ifdef::openshift-rosa-hcp[]
|
||||
{hcp-title}-specific
|
||||
endif::rosa-with-hcp[]
|
||||
ifndef::rosa-with-hcp[]
|
||||
endif::openshift-rosa-hcp[]
|
||||
ifndef::openshift-rosa-hcp[]
|
||||
ROSA-specific
|
||||
endif::rosa-with-hcp[]
|
||||
endif::openshift-rosa-hcp[]
|
||||
group called `dedicated-admin`. Any users on the cluster that are members of the `dedicated-admin` group:
|
||||
|
||||
- Have administrator access to all customer-created projects on the cluster.
|
||||
@@ -62,12 +62,12 @@ group called `dedicated-admin`. Any users on the cluster that are members of the
|
||||
[id="rosa-sdpolicy-cluster-admin-role_{context}"]
|
||||
== Cluster administration role
|
||||
The administrator of
|
||||
ifdef::rosa-with-hcp[]
|
||||
ifdef::openshift-rosa-hcp[]
|
||||
{hcp-title-first}
|
||||
endif::rosa-with-hcp[]
|
||||
ifndef::rosa-with-hcp[]
|
||||
endif::openshift-rosa-hcp[]
|
||||
ifndef::openshift-rosa-hcp[]
|
||||
{product-title}
|
||||
endif::rosa-with-hcp[]
|
||||
endif::openshift-rosa-hcp[]
|
||||
has default access to the `cluster-admin` role for your organization's cluster. While logged into an account with the `cluster-admin` role, users have increased permissions to run privileged security contexts.
|
||||
|
||||
[id="rosa-sdpolicy-project-self-service_{context}"]
|
||||
@@ -91,28 +91,28 @@ See the _Compliance_ table in _Understanding process and security for ROSA_ for
|
||||
|
||||
[id="rosa-sdpolicy-network-security_{context}"]
|
||||
== Network security
|
||||
With {product-title}, AWS provides a standard DDoS protection on all load balancers, called AWS Shield. This provides 95% protection against most commonly used level 3 and 4 attacks on all the public facing load balancers used for {product-title}. A 10-second timeout is added for HTTP requests coming to the `haproxy` router to receive a response or the connection is closed to provide additional protection.
|
||||
With {product-title}, AWS provides a standard DDoS protection on all load balancers, called AWS Shield. This provides 95% protection against most commonly used level 3 and 4 attacks on all the public facing load balancers used for ROSA. A 10-second timeout is added for HTTP requests coming to the `haproxy` router to receive a response or the connection is closed to provide additional protection.
|
||||
|
||||
[id="rosa-sdpolicy-etcd-encryption_{context}"]
|
||||
== etcd encryption
|
||||
|
||||
In
|
||||
ifdef::rosa-with-hcp[]
|
||||
ifdef::openshift-rosa-hcp[]
|
||||
{hcp-title-first},
|
||||
endif::rosa-with-hcp[]
|
||||
ifndef::rosa-with-hcp[]
|
||||
endif::openshift-rosa-hcp[]
|
||||
ifndef::openshift-rosa-hcp[]
|
||||
{product-title},
|
||||
endif::rosa-with-hcp[]
|
||||
endif::openshift-rosa-hcp[]
|
||||
the control plane storage is encrypted at rest by default and this includes encryption of the etcd volumes. This storage-level encryption is provided through the storage layer of the cloud provider.
|
||||
|
||||
ifdef::rosa-with-hcp[]
|
||||
ifdef::openshift-rosa-hcp[]
|
||||
The etcd database is always encrypted by default. Customers might opt to provide their own custom AWS KMS keys for the purpose of encrypting the etcd database.
|
||||
|
||||
Etcd encryption will encrypt the following Kubernetes API server and OpenShift API server resources:
|
||||
endif::rosa-with-hcp[]
|
||||
ifndef::rosa-with-hcp[]
|
||||
endif::openshift-rosa-hcp[]
|
||||
ifndef::openshift-rosa-hcp[]
|
||||
You can also enable etcd encryption, which encrypts the key values in etcd, but not the keys. If you enable etcd encryption, the following Kubernetes API server and OpenShift API server resources are encrypted:
|
||||
endif::rosa-with-hcp[]
|
||||
endif::openshift-rosa-hcp[]
|
||||
|
||||
* Secrets
|
||||
* Config maps
|
||||
@@ -120,14 +120,14 @@ endif::rosa-with-hcp[]
|
||||
* OAuth access tokens
|
||||
* OAuth authorize tokens
|
||||
|
||||
ifndef::rosa-with-hcp[]
|
||||
ifndef::openshift-rosa-hcp[]
|
||||
The etcd encryption feature is not enabled by default and it can be enabled only at cluster installation time. Even with etcd encryption enabled, the etcd key values are accessible to anyone with access to the control plane nodes or `cluster-admin` privileges.
|
||||
|
||||
[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{nbsp}Hat recommends that you enable etcd encryption only if you specifically require it for your use case.
|
||||
====
|
||||
endif::rosa-with-hcp[]
|
||||
endif::openshift-rosa-hcp[]
|
||||
|
||||
ifeval::["{context}" == "rosa-hcp-service-definition"]
|
||||
:!rosa-with-hcp:
|
||||
|
||||
@@ -12,23 +12,23 @@ endif::[]
|
||||
= Storage
|
||||
|
||||
This section provides information about the service definition for
|
||||
ifdef::rosa-with-hcp[]
|
||||
ifdef::openshift-rosa-hcp[]
|
||||
{hcp-title-first}
|
||||
endif::rosa-with-hcp[]
|
||||
ifndef::rosa-with-hcp[]
|
||||
endif::openshift-rosa-hcp[]
|
||||
ifndef::openshift-rosa-hcp[]
|
||||
{product-title}
|
||||
endif::rosa-with-hcp[]
|
||||
endif::openshift-rosa-hcp[]
|
||||
storage.
|
||||
|
||||
[id="rosa-sdpolicy-encrytpted-at-rest-storage_{context}"]
|
||||
== Encrypted-at-rest OS and node storage
|
||||
|
||||
ifdef::rosa-with-hcp[]
|
||||
ifdef::openshift-rosa-hcp[]
|
||||
Worker
|
||||
endif::rosa-with-hcp[]
|
||||
ifndef::rosa-with-hcp[]
|
||||
endif::openshift-rosa-hcp[]
|
||||
ifndef::openshift-rosa-hcp[]
|
||||
Control plane, infrastructure, and worker
|
||||
endif::rosa-with-hcp[]
|
||||
endif::openshift-rosa-hcp[]
|
||||
nodes use encrypted-at-rest Amazon Elastic Block Store (Amazon EBS) storage.
|
||||
|
||||
[id="rosa-sdpolicy-encrytpted-at-rest-pv_{context}"]
|
||||
@@ -46,13 +46,13 @@ Each cloud provider has its own limits for how many PVs can be attached to a sin
|
||||
== Shared Storage (RWX)
|
||||
|
||||
The AWS CSI Driver can be used to provide RWX support for
|
||||
ifdef::rosa-with-hcp[]
|
||||
ifdef::openshift-rosa-hcp[]
|
||||
{hcp-title-first}.
|
||||
endif::rosa-with-hcp[]
|
||||
ifndef::rosa-with-hcp[]
|
||||
endif::openshift-rosa-hcp[]
|
||||
ifndef::openshift-rosa-hcp[]
|
||||
{product-title}.
|
||||
endif::rosa-with-hcp[]
|
||||
A community Operator is provided to simplify setup. See link:https://access.redhat.com/articles/5025181[Amazon Elastic File Storage Setup for OpenShift Dedicated and Red{nbsp}Hat OpenShift Service on AWS] for details.
|
||||
endif::openshift-rosa-hcp[]
|
||||
A community Operator is provided to simplify setup. See link:https://access.redhat.com/articles/5025181[Amazon Elastic File Storage Setup for Red Hat OpenShift Service on AWS] for details.
|
||||
|
||||
ifeval::["{context}" == "rosa-hcp-service-definition"]
|
||||
:!rosa-with-hcp:
|
||||
|
||||
@@ -6,13 +6,20 @@
|
||||
[id="rosa-sts-about-operator-role-prefixes_{context}"]
|
||||
= About custom Operator IAM role prefixes
|
||||
|
||||
Each {product-title} (ROSA) cluster that uses the AWS Security Token Service (STS) requires cluster-specific Operator IAM roles.
|
||||
Each {product-title} (ROSA) cluster
|
||||
ifdef::openshift-rosa-hcp[]
|
||||
requires cluster-specific Operator IAM roles.
|
||||
endif::[]
|
||||
ifndef::openshift-rosa-hcp[]
|
||||
that uses the AWS Security Token Service (STS) requires cluster-specific Operator IAM roles.
|
||||
endif::openshift-rosa-hcp[]
|
||||
|
||||
By default, the Operator role names are prefixed with the cluster name and a random 4-digit hash. For example, the Cloud Credential Operator IAM role for a cluster named `mycluster` has the default name `mycluster-<hash>-openshift-cloud-credential-operator-cloud-credentials`, where `<hash>` is a random 4-digit string.
|
||||
|
||||
By default, the Operator role names are prefixed with the cluster name and a random 4-digit hash. For example, the Ingress Cloud Credentials Operator IAM role for a cluster named `mycluster` has the default name `mycluster-<hash>-openshift-ingress-operator-cloud-credentials`, where `<hash>` is a random 4-digit string.
|
||||
|
||||
This default naming convention enables you to easily identify the Operator IAM roles for a cluster in your AWS account.
|
||||
|
||||
When you create the Operator roles for a cluster, you can optionally specify a custom prefix to use instead of `<cluster_name>-<hash>`. By using a custom prefix, you can prepend logical identifiers to your Operator role names to meet the requirements of your environment. For example, you might prefix the cluster name and the environment type, such as `mycluster-dev`. In that example, the Cloud Credential Operator role name with the custom prefix is `mycluster-dev-openshift-cloud-credential-operator-cloud-credenti`.
|
||||
When you create the Operator roles for a cluster, you can optionally specify a custom prefix to use instead of `<cluster_name>-<hash>`. By using a custom prefix, you can prepend logical identifiers to your Operator role names to meet the requirements of your environment. For example, you might prefix the cluster name and the environment type, such as `mycluster-dev`. In that example, the Ingress Cloud Credentials Operator role name with the custom prefix is `mycluster-dev-openshift-ingress-operator-cloud-credenti`.
|
||||
|
||||
[NOTE]
|
||||
====
|
||||
|
||||
@@ -28,11 +28,14 @@ If you created an `ocm-role` resource with administrative permissions, you can u
|
||||
|
||||
If you use the ROSA guided installation on {cluster-manager}, you must have created an `ocm-role` resource with administrative permissions in the first step of the guided cluster installation. Without this role, you cannot use the automatic Operator role and policy creation option, but you can still create the cluster and its roles and policies with the manual process.
|
||||
|
||||
ifndef::openshift-rosa-hcp[]
|
||||
|
||||
[NOTE]
|
||||
====
|
||||
The account number present in the `sts_installer_trust_policy.json` and `sts_support_trust_policy.json` samples represents the Red{nbsp}Hat account that is allowed to assume the required roles.
|
||||
====
|
||||
|
||||
|
||||
.ROSA installer role, policy, and policy files
|
||||
[cols="1,2",options="header"]
|
||||
|===
|
||||
@@ -338,3 +341,312 @@ include::https://raw.githubusercontent.com/openshift/managed-cluster-config/refs
|
||||
include::https://raw.githubusercontent.com/openshift/managed-cluster-config/refs/heads/master/resources/sts/4.19/openshift_image_registry_installer_cloud_credentials_policy.json[]
|
||||
----
|
||||
====
|
||||
endif::openshift-rosa-hcp[]
|
||||
|
||||
ifdef::openshift-rosa-hcp[]
|
||||
|
||||
.ROSA Manage Subscription policy and policy file
|
||||
[cols="1,2",options="header"]
|
||||
|===
|
||||
|
||||
|Resource|Description
|
||||
|
||||
|link:https://docs.aws.amazon.com/aws-managed-policy/latest/reference/ROSAManageSubscription.html[`ROSAManageSubscription`]
|
||||
|This policy streamlines permission setup by packaging necessary access rights, giving entities appropriate control over the ROSA subscription while preventing excessive permissions.
|
||||
|
||||
|===
|
||||
|
||||
.ROSA installer role, policy, and policy files
|
||||
[cols="1,2",options="header"]
|
||||
|===
|
||||
|
||||
|Resource|Description
|
||||
|
||||
|`HCP-ROSA-Installer-Role`
|
||||
|An IAM role used by the ROSA installer.
|
||||
|
||||
|link:https://docs.aws.amazon.com/aws-managed-policy/latest/reference/ROSAInstallerPolicy.html[ROSAInstallerPolicy]
|
||||
|An IAM policy that provides the ROSA installer with the permissions required to complete cluster installation tasks.
|
||||
|
||||
|`HCP-ROSA-Installer-Role` trust policy
|
||||
|Grants the Red{nbsp} Hat installer temporary permission to act within your AWS account for the sole purpose of setting up a {product-title} cluster.
|
||||
|
||||
|===
|
||||
.`sts_hcp_installer_permission_policy.json`
|
||||
[%collapsible]
|
||||
====
|
||||
[source,json]
|
||||
----
|
||||
include::https://raw.githubusercontent.com/openshift/managed-cluster-config/refs/heads/master/resources/sts/hypershift/sts_hcp_installer_permission_policy.json[]
|
||||
----
|
||||
====
|
||||
|
||||
.`sts_hcp_installer_trust_policy.json`
|
||||
[%collapsible]
|
||||
====
|
||||
[source,json]
|
||||
----
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [
|
||||
{
|
||||
"Effect": "Allow",
|
||||
"Principal": {
|
||||
"AWS": "arn:aws:iam::710019948333:role/RH-Managed-OpenShift-Installer"
|
||||
},
|
||||
"Action": "sts:AssumeRole"
|
||||
}
|
||||
]
|
||||
}
|
||||
----
|
||||
====
|
||||
|
||||
|
||||
.ROSA worker node role, policy, and policy files
|
||||
[cols="1,2",options="header"]
|
||||
|===
|
||||
|
||||
|Resource|Description
|
||||
|
||||
|`HCP-ROSA-Worker-Role`
|
||||
|An IAM role used by the compute instances.
|
||||
|
||||
|link:https://docs.aws.amazon.com/aws-managed-policy/latest/reference/ROSAWorkerInstancePolicy.html[ROSAWorkerInstancePolicy]
|
||||
|An IAM policy that provides the ROSA compute instances with the permissions required to manage their components.
|
||||
|
||||
|`HCP-ROSA-Worker-Role` trust policy
|
||||
|Allows essential software on your worker nodes to securely connect and talk to the cluster's control plane, which is managed remotely by Red{nbsp}Hat.
|
||||
|===
|
||||
|
||||
.`sts_hcp_worker_instance_permission_policy.json`
|
||||
[%collapsible]
|
||||
====
|
||||
[source,json]
|
||||
----
|
||||
include::https://raw.githubusercontent.com/openshift/managed-cluster-config/refs/heads/master/resources/sts/hypershift/sts_hcp_worker_instance_permission_policy.json[]
|
||||
----
|
||||
====
|
||||
|
||||
.`sts_hcp_worker_instance_trust_policy.json`
|
||||
[%collapsible]
|
||||
====
|
||||
[source,json]
|
||||
----
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [
|
||||
{
|
||||
"Effect": "Allow",
|
||||
"Principal": {
|
||||
"Service": "ec2.amazonaws.com"
|
||||
},
|
||||
"Action": "sts:AssumeRole"
|
||||
}
|
||||
]
|
||||
}
|
||||
----
|
||||
====
|
||||
|
||||
|
||||
.ROSA support role, policy, and policy files
|
||||
[cols="1,2",options="header"]
|
||||
|===
|
||||
|
||||
|Resource|Description
|
||||
|
||||
|`HCP-ROSA-Support-Role`
|
||||
|An IAM role used by the Red Hat Site Reliability Engineering (SRE) support team.
|
||||
|
||||
|link:https://docs.aws.amazon.com/aws-managed-policy/latest/reference/ROSASRESupportPolicy.html[ROSASRESupportPolicy]
|
||||
|An IAM policy that provides the Red Hat SRE support team with the permissions required to support ROSA clusters.
|
||||
|
||||
|`HCP-ROSA-Support-Role` trust policy
|
||||
|Provides a secure mechanism for authorized Red Hat Site Reliability Engineers (SREs) to perform diagnostic and support functions on the cluster.
|
||||
|
||||
|===
|
||||
.`sts_hcp_support_permission_policy.json`
|
||||
[%collapsible]
|
||||
====
|
||||
[source,json]
|
||||
----
|
||||
include::https://raw.githubusercontent.com/openshift/managed-cluster-config/refs/heads/master/resources/sts/hypershift/sts_hcp_support_permission_policy.json[]
|
||||
----
|
||||
====
|
||||
|
||||
.`sts_hcp_support_trust_policy.json`
|
||||
[%collapsible]
|
||||
====
|
||||
[source,json]
|
||||
----
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [
|
||||
{
|
||||
"Effect": "Allow",
|
||||
"Principal": {
|
||||
"AWS": "arn:aws:iam::710019948333:role/RH-Technical-Support-15234082"
|
||||
},
|
||||
"Action": "sts:AssumeRole"
|
||||
}
|
||||
]
|
||||
}
|
||||
----
|
||||
====
|
||||
|
||||
.ROSA Kube Controller Operator policy and policy file
|
||||
[cols="1,2",options="header"]
|
||||
|===
|
||||
|
||||
|Resource|Description
|
||||
|
||||
|`openshift-hcp-kube-controller-manager-credentials`
|
||||
|An IAM policy that grants permissions to the kube controller to manage Amazon EC2, Elastic Load Balancing, and AWS KMS resources.
|
||||
|
||||
|
||||
|===
|
||||
.`openshift-hcp_kube-controller-manager-credentials-policy.json`
|
||||
[%collapsible]
|
||||
====
|
||||
[source,json]
|
||||
----
|
||||
include::https://raw.githubusercontent.com/openshift/managed-cluster-config/refs/heads/master/resources/sts/hypershift/openshift_hcp_kube_controller_manager_credentials_policy.json[]
|
||||
----
|
||||
====
|
||||
|
||||
.ROSA Control Plane Operator policy and policy file
|
||||
[cols="1,2",options="header"]
|
||||
|===
|
||||
|
||||
|Resource|Description
|
||||
|
||||
|`openshift-hcp-control-plane-operator-credentials-policy`
|
||||
|An IAM policy that grants required permissions to the Control Plane Operator to manage Amazon EC2 and Route 53 resources.
|
||||
|
||||
|
||||
|===
|
||||
.`openshift_hcp_control_plane_operator_credentials_policy.json`
|
||||
[%collapsible]
|
||||
====
|
||||
[source,json]
|
||||
----
|
||||
include::https://raw.githubusercontent.com/openshift/managed-cluster-config/refs/heads/master/resources/sts/hypershift/openshift_hcp_control_plane_operator_credentials_policy.json[]
|
||||
----
|
||||
====
|
||||
|
||||
.ROSA Node Pool Management Operator policy and policy file
|
||||
[cols="1,2",options="header"]
|
||||
|===
|
||||
|
||||
|Resource|Description
|
||||
|
||||
|`openshift-hcp-capa-controller-manager-credentials-policy`
|
||||
|An IAM policy that grants required permissions to the NodePool controller to describe, run, and terminate Amazon EC2 instances managed as worker nodes. This policy also grants permissions to allow for disk encryption of the worker node root volume using AWS KMS keys, and to tag the elastic network interface that is attached to the worker node.
|
||||
|
||||
|===
|
||||
.`openshift_hcp_capa_controller_manager_credentials_policy.json`
|
||||
[%collapsible]
|
||||
====
|
||||
[source,json]
|
||||
----
|
||||
include::https://raw.githubusercontent.com/openshift/managed-cluster-config/refs/heads/master/resources/sts/hypershift/openshift_hcp_capa_controller_manager_credentials_policy.json[]
|
||||
----
|
||||
====
|
||||
|
||||
.ROSA Image Registry Operator policy and policy file
|
||||
[cols="1,2",options="header"]
|
||||
|===
|
||||
|
||||
|Resource|Description
|
||||
|
||||
|`openshift-hcp-image-registry-operator-permission-policy`
|
||||
|An IAM policy that grants required permissions to the Image Registry Operator to provision and manage resources for the ROSA in-cluster image registry and dependent services, including S3. This is required so that the operator can install and maintain the internal registry of a ROSA cluster.
|
||||
|
||||
|===
|
||||
.`openshift_hcp_image_registry_operator_permission_policy.json`
|
||||
[%collapsible]
|
||||
====
|
||||
[source,json]
|
||||
----
|
||||
include::https://raw.githubusercontent.com/openshift/managed-cluster-config/refs/heads/master/resources/sts/hypershift/openshift_hcp_image_registry_operator_permission_policy.json[]
|
||||
----
|
||||
====
|
||||
|
||||
.ROSA Amazon EBSCI Driver Operator policy and policy file
|
||||
[cols="1,2",options="header"]
|
||||
|===
|
||||
|
||||
|Resource|Description
|
||||
|
||||
|`openshift-hcp-cluster-csi-driver-ebs-operator-cloud-credentials-policy`
|
||||
|An IAM policy that grants necessary permissions to the Amazon EBS CSI Driver Operator to install and maintain the Amazon EBS CSI driver on a ROSA cluster.
|
||||
|
||||
|===
|
||||
.`openshift_hcp_cluster_csi_driver_ebs_operator_cloud_credentials_policy.json`
|
||||
[%collapsible]
|
||||
====
|
||||
[source,json]
|
||||
----
|
||||
include::https://raw.githubusercontent.com/openshift/managed-cluster-config/refs/heads/master/resources/sts/hypershift/openshift_hcp_cluster_csi_driver_ebs_operator_cloud_credentials_policy.json[]
|
||||
----
|
||||
====
|
||||
.ROSA Cloud Network Config Operator policy and policy file
|
||||
[cols="1,2",options="header"]
|
||||
|===
|
||||
|
||||
|Resource|Description
|
||||
|
||||
|`openshift-hcp-cloud-network-config-cloud-credentials-permission-policy`
|
||||
|An IAM policy that grants necessary permissions to the Amazon EBS CSI Driver Operator to install and maintain the Amazon EBS CSI driver on a ROSA cluster.
|
||||
|
||||
|===
|
||||
.`openshift_hcp_cloud_network_config_cloud_credentials_permission_policy.json`
|
||||
[%collapsible]
|
||||
====
|
||||
[source,json]
|
||||
----
|
||||
include::https://raw.githubusercontent.com/openshift/managed-cluster-config/refs/heads/master/resources/sts/hypershift/openshift_hcp_cloud_network_config_cloud_credentials_permission_policy.json[]
|
||||
----
|
||||
====
|
||||
|
||||
|
||||
.ROSA Ingress Operator policy and policy file
|
||||
[cols="1,2",options="header"]
|
||||
|===
|
||||
|
||||
|Resource|Description
|
||||
|
||||
|`openshift-hcp-cluster-ingress-operator-cloud-credentials-policy`
|
||||
|An IAM policy that provides the ROSA Ingress Operator with the permissions required to manage external access to a cluster.
|
||||
|
||||
|===
|
||||
.`openshift_hcp_cluster_ingress_operator_cloud_credentials_policy.json`
|
||||
[%collapsible]
|
||||
====
|
||||
[source,json]
|
||||
----
|
||||
include::https://raw.githubusercontent.com/openshift/managed-cluster-config/refs/heads/master/resources/sts/hypershift/openshift_hcp_cluster_ingress_operator_cloud_credentials_policy.json[]
|
||||
|
||||
----
|
||||
====
|
||||
|
||||
|
||||
.ROSA KMS Provider Operator policy and policy file
|
||||
[cols="1,2",options="header"]
|
||||
|===
|
||||
|
||||
|Resource|Description
|
||||
|
||||
|`openshift-hcp-kms-provider-credential-policy.`
|
||||
|An IAM policy grants required permissions to the built-in AWS Encryption Provider to manage AWS KMS keys that support etcd data encryption. This policy allows Amazon EC2 to use KMS keys that the AWS Encryption Provider provides to encrypt and decrypt etcd data.
|
||||
|
||||
|===
|
||||
.`openshift_hcp_kms_provider_credential_policy.json`
|
||||
[%collapsible]
|
||||
====
|
||||
[source,json]
|
||||
----
|
||||
include::https://raw.githubusercontent.com/openshift/managed-cluster-config/refs/heads/master/resources/sts/hypershift/openshift_hcp_kms_provider_credential_policy.json[]
|
||||
----
|
||||
====
|
||||
|
||||
endif::openshift-rosa-hcp[]
|
||||
@@ -8,17 +8,17 @@
|
||||
[id="sre-cluster-access_{context}"]
|
||||
= SRE cluster access
|
||||
|
||||
SRE access to {product-title}
|
||||
Red{nbsp}Hat SRE access to {product-title}
|
||||
ifdef::openshift-rosa[]
|
||||
(ROSA)
|
||||
endif::openshift-rosa[]
|
||||
clusters is controlled through several layers of required authentication, all of which are managed by strict company policy. All authentication attempts to access a cluster and changes made within a cluster are recorded within audit logs, along with the specific account identity of the SRE responsible for those actions. These audit logs help ensure that all changes made by SREs to a customer's cluster adhere to the strict policies and procedures that make up Red Hat's managed services guidelines.
|
||||
clusters is controlled through several layers of required authentication, all of which are managed by strict company policy. All authentication attempts to access a cluster and changes made within a cluster are recorded within audit logs, along with the specific account identity of the SRE responsible for those actions. These audit logs help ensure that all changes made by SREs to a customer's cluster adhere to the strict policies and procedures that make up Red{nbsp}Hat's managed services guidelines.
|
||||
|
||||
The information presented below is an overview of the process an SRE must perform to access a customer's cluster.
|
||||
|
||||
** SRE requests a refreshed ID token from the Red Hat SSO (Cloud Services). This request is authenticated. The token is valid for fifteen minutes. After the token expires, you can refresh the token again and receive a new token. The ability to refresh to a new token is indefinite; however, the ability to refresh to a new token is revoked after 30 days of inactivity.
|
||||
** Red{nbsp}Hat SRE requests a refreshed ID token from the Red{nbsp}Hat SSO (Cloud Services). This request is authenticated. The token is valid for fifteen minutes. After the token expires, you can refresh the token again and receive a new token. The ability to refresh to a new token is indefinite; however, the ability to refresh to a new token is revoked after 30 days of inactivity.
|
||||
|
||||
** SRE connects to the Red Hat VPN. The authentication to the VPN is completed by the Red Hat Corporate Identity and Access Management system (RH IAM). With RH IAM, SREs are multifactor and can be managed internally per organization by groups and existing onboarding and offboarding processes. After an SRE is authenticated and connected, the SRE can access the cloud services fleet management plane. Changes to the cloud services fleet management plane require many layers of approval and are maintained by strict company policy.
|
||||
** Red{nbsp}Hat SRE connects to the Red{nbsp}Hat VPN. The authentication to the VPN is completed by the Red{nbsp}Hat Corporate Identity and Access Management system (RH IAM). With RH IAM, SREs are multifactor and can be managed internally per organization by groups and existing onboarding and offboarding processes. After an SRE is authenticated and connected, the SRE can access the cloud services fleet management plane. Changes to the cloud services fleet management plane require many layers of approval and are maintained by strict company policy.
|
||||
|
||||
** After authorization is complete, the SRE logs into the fleet management plane and receives a service account token that the fleet management plane created. The token is valid for 15 minutes. After the token is no longer valid, it is deleted.
|
||||
|
||||
@@ -26,16 +26,16 @@ The information presented below is an overview of the process an SRE must perfor
|
||||
|
||||
*** Accessing a private or public cluster: Request is sent through a specific Network Load Balancer (NLB) by using an encrypted HTTP connection on port 6443.
|
||||
|
||||
*** Accessing a PrivateLink cluster: Request is sent to the Red Hat Transit Gateway, which then connects to a Red Hat VPC per region. The VPC that receives the request will be dependent on the target private cluster's region. Within the VPC, there is a private subnet that contains the PrivateLink endpoint to the customer's PrivateLink cluster.
|
||||
*** Accessing a PrivateLink cluster: Request is sent to the Red{nbsp}Hat Transit Gateway, which then connects to a Red{nbsp}Hat VPC per region. The VPC that receives the request will be dependent on the target private cluster's region. Within the VPC, there is a private subnet that contains the PrivateLink endpoint to the customer's PrivateLink cluster.
|
||||
|
||||
ifdef::openshift-dedicated[]
|
||||
*** Accessing a Private Service Connect (PSC) cluster: Request is sent to Red Hat's internal backend infrastructure, which routes the traffic through a secured, trusted network to Red Hat's Management project in GCP. The Red Hat Management project includes VPC, which is configured with subnets in multiple regions, each containing a PSC endpoint that provides private access to the customer's cluster in the respective region. The traffic is routed through the appropriate regional subnet, ensuring secure and private access to the cluster without traversing the public internet.
|
||||
*** Accessing a Private Service Connect (PSC) cluster: Request is sent to Red{nbsp}Hat's internal backend infrastructure, which routes the traffic through a secured, trusted network to Red{nbsp}Hat's Management project in GCP. The Red{nbsp}Hat Management project includes VPC, which is configured with subnets in multiple regions, each containing a PSC endpoint that provides private access to the customer's cluster in the respective region. The traffic is routed through the appropriate regional subnet, ensuring secure and private access to the cluster without traversing the public internet.
|
||||
endif::openshift-dedicated[]
|
||||
|
||||
ifdef::openshift-rosa[]
|
||||
SREs access ROSA clusters through the web console or command-line interface (CLI) tools. Authentication requires multi-factor authentication (MFA) with industry-standard requirements for password complexity and account lockouts. SREs must authenticate as individuals to ensure auditability. All authentication attempts are logged to a Security Information and Event Management (SIEM) system.
|
||||
|
||||
SREs access private clusters using an encrypted HTTP connection. Connections are permitted only from a secured Red Hat network using either an IP allowlist or a private cloud provider link.
|
||||
SREs access private clusters using an encrypted HTTP connection. Connections are permitted only from a secured Red{nbsp}Hat network using either an IP allowlist or a private cloud provider link.
|
||||
|
||||
.SRE access to ROSA clusters
|
||||
image::267_OpenShift_on_AWS_Access_Networking_1222.png[]
|
||||
@@ -44,9 +44,9 @@ image::267_OpenShift_on_AWS_Access_Networking_1222.png[]
|
||||
== Privileged access controls in ROSA
|
||||
SRE adheres to the principle of least privilege when accessing ROSA and AWS components. There are four basic categories of manual SRE access:
|
||||
|
||||
- SRE admin access through the Red Hat Portal with normal two-factor authentication and no privileged elevation.
|
||||
- SRE admin access through the Red Hat corporate SSO with normal two-factor authentication and no privileged elevation.
|
||||
- OpenShift elevation, which is a manual elevation using Red Hat SSO. Access is limited to 2 hours, is fully audited, and requires management approval.
|
||||
- SRE admin access through the Red{nbsp}Hat Portal with normal two-factor authentication and no privileged elevation.
|
||||
- SRE admin access through the Red{nbsp}Hat corporate SSO with normal two-factor authentication and no privileged elevation.
|
||||
- OpenShift elevation, which is a manual elevation using Red{nbsp}Hat SSO. Access is limited to 2 hours, is fully audited, and requires management approval.
|
||||
- AWS access or elevation, which is a manual elevation for AWS console or CLI access. Access is limited to 60 minutes and is fully audited.
|
||||
|
||||
Each of these access types have different levels of access to components:
|
||||
@@ -55,7 +55,7 @@ Each of these access types have different levels of access to components:
|
||||
|
||||
|===
|
||||
|
||||
| Component | Typical SRE admin access (Red Hat Portal) | Typical SRE admin access (Red Hat SSO) |OpenShift elevation | Cloud provider access or elevation
|
||||
| Component | Typical SRE admin access (Red{nbsp}Hat Portal) | Typical SRE admin access (Red{nbsp}Hat SSO) |OpenShift elevation | Cloud provider access or elevation
|
||||
|
||||
| {cluster-manager} | R/W | No access | No access | No access
|
||||
| OpenShift console | No access | R/W | R/W | No access
|
||||
@@ -66,21 +66,21 @@ Each of these access types have different levels of access to components:
|
||||
|
||||
[id="rosa-policy-sre-aws-infra-access_{context}"]
|
||||
== SRE access to AWS accounts
|
||||
Red Hat personnel do not access AWS accounts in the course of routine {product-title} operations. For emergency troubleshooting purposes, the SREs have well-defined and auditable procedures to access cloud infrastructure accounts.
|
||||
Red{nbsp}Hat personnel do not access AWS accounts in the course of routine {product-title} operations. For emergency troubleshooting purposes, the SREs have well-defined and auditable procedures to access cloud infrastructure accounts.
|
||||
|
||||
In the isolated backplane flow, SREs request access to a customer's support role. This request is just-in-time (JIT) processed by the backplane API which dynamically updates the organization role's permissions to a specific SRE personnel's account. This SRE's account is given access to a specific Red Hat customer's environment. SRE access to a Red Hat customer's environment is a temporary, short-lived access that is only established at the time of the access request.
|
||||
In the isolated backplane flow, SREs request access to a customer's support role. This request is just-in-time (JIT) processed by the backplane API which dynamically updates the organization role's permissions to a specific SRE personnel's account. This SRE's account is given access to a specific Red{nbsp}Hat customer's environment. SRE access to a Red{nbsp}Hat customer's environment is a temporary, short-lived access that is only established at the time of the access request.
|
||||
|
||||
Access to the STS token is audit-logged and traceable back to individual users. Both STS and non-STS clusters use the AWS STS service for SRE access. Access control uses the unified backplane flow when the `ManagedOpenShift-Technical-Support-Role` has the `ManagedOpenShift-Support-Access` policy attached, and this role is used for administration. Access control uses the isolated backplane flow when the `ManagedOpenShift-Support-Role` has the `ManagedOpenShift-Technical-Support-<org_id>` policy attached. See the KCS article link:https://access.redhat.com/solutions/7045629[Updating Trust Policies for ROSA clusters] for more information.
|
||||
|
||||
[id="rosa-sre-sts-view-aws-account_{context}"]
|
||||
== SRE STS view of AWS accounts
|
||||
|
||||
When SREs are on a VPN through two-factor authentication, they and Red Hat Support can assume the `ManagedOpenShift-Support-Role` in your AWS account. The `ManagedOpenShift-Support-Role` has all the permissions necessary for SREs to directly troubleshoot and manage AWS resources. Upon assumption of the `ManagedOpenShift-Support-Role`, SREs use a AWS Security Token Service (STS) to generate a unique, time-expiring URL to the customer's AWS web UI for their account. SREs can then perform multiple troubleshooting actions, which include:
|
||||
When SREs are on a VPN through two-factor authentication, they and Red{nbsp}Hat Support can assume the `ManagedOpenShift-Support-Role` in your AWS account. The `ManagedOpenShift-Support-Role` has all the permissions necessary for SREs to directly troubleshoot and manage AWS resources. Upon assumption of the `ManagedOpenShift-Support-Role`, SREs use a AWS Security Token Service (STS) to generate a unique, time-expiring URL to the customer's AWS web UI for their account. SREs can then perform multiple troubleshooting actions, which include:
|
||||
|
||||
* Viewing CloudTrail logs
|
||||
* Shutting down a faulty EC2 Instance
|
||||
|
||||
All activities performed by SREs arrive from Red Hat IP addresses and are logged to CloudTrail to allow you to audit and review all activity. This role is only used in cases where access to AWS services is required to assist you. The majority of permissions are read-only. However, a select few permissions have more access, including the ability to reboot an instance or spin up a new instance. SRE access is limited to the policy permissions attached to the `ManagedOpenShift-Support-Role`.
|
||||
All activities performed by SREs arrive from Red{nbsp}Hat IP addresses and are logged to CloudTrail to allow you to audit and review all activity. This role is only used in cases where access to AWS services is required to assist you. The majority of permissions are read-only. However, a select few permissions have more access, including the ability to reboot an instance or spin up a new instance. SRE access is limited to the policy permissions attached to the `ManagedOpenShift-Support-Role`.
|
||||
|
||||
For a full list of permissions, see `sts_support_permission_policy.json` in the link:https://docs.openshift.com/rosa/rosa_architecture/rosa-sts-about-iam-resources.html[About IAM resources] user guide.
|
||||
|
||||
@@ -89,9 +89,9 @@ For a full list of permissions, see `sts_support_permission_policy.json` in the
|
||||
|
||||
PrivateLink VPC endpoint service is created as part of the ROSA cluster creation.
|
||||
|
||||
When you have a PrivateLink ROSA cluster, its Kubernetes API Server is exposed through a load balancer that can only be accessed from within the VPC by default. Red Hat site reliability engineering (SRE) can connect to this load balancer through a VPC Endpoint Service that has an associated VPC Endpoint in a Red Hat-owned AWS account. This endpoint service contains the name of the cluster, which is also in the ARN.
|
||||
When you have a PrivateLink ROSA cluster, its Kubernetes API Server is exposed through a load balancer that can only be accessed from within the VPC by default. Red{nbsp}Hat site reliability engineering (SRE) can connect to this load balancer through a VPC Endpoint Service that has an associated VPC Endpoint in a Red{nbsp}Hat-owned AWS account. This endpoint service contains the name of the cluster, which is also in the ARN.
|
||||
|
||||
Under the *Allow principals* tab, a Red Hat-owned AWS account is listed. This specific user ensures that other entities cannot create VPC Endpoint connections to the PrivateLink cluster's Kubernetes API Server.
|
||||
Under the *Allow principals* tab, a Red{nbsp}Hat-owned AWS account is listed. This specific user ensures that other entities cannot create VPC Endpoint connections to the PrivateLink cluster's Kubernetes API Server.
|
||||
|
||||
When Red Hat SREs access the API, this fleet management plane can connect to the internal API through the VPC endpoint service.
|
||||
When Red{nbsp}Hat SREs access the API, this fleet management plane can connect to the internal API through the VPC endpoint service.
|
||||
endif::openshift-rosa[]
|
||||
@@ -10,21 +10,21 @@ include::_attributes/attributes-openshift-dedicated.adoc[]
|
||||
|
||||
toc::[]
|
||||
|
||||
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 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, AI and other services to further accelerate the building and delivering of differentiating experiences to your customers.
|
||||
|
||||
{hcp-title-first} offers a reduced-cost solution to create a managed ROSA cluster with a focus on efficiency. You can quickly create a new cluster and deploy applications in minutes.
|
||||
{hcp-title-first} offers a reduced-cost solution to create a managed ROSA cluster with a focus on efficiency and security. You can quickly create a new cluster and deploy applications in minutes.
|
||||
|
||||
You subscribe to the service directly from your AWS account. After you create clusters, you can operate your clusters with the OpenShift web console, the ROSA CLI, or through {cluster-manager-first}.
|
||||
|
||||
You receive OpenShift updates with new feature releases and a shared, common source for alignment with OpenShift Container Platform. ROSA supports the same versions of OpenShift as Red{nbsp}Hat OpenShift Dedicated and OpenShift Container Platform to achieve version consistency.
|
||||
You receive OpenShift updates with new feature releases and a shared, common source for alignment with OpenShift Container Platform. ROSA supports the same versions of OpenShift as Red{nbsp}Hat OpenShift Container Platform to achieve version consistency.
|
||||
|
||||
image::291_OpenShift_on_AWS_Intro_1122_docs.png[{product-title}]
|
||||
|
||||
ROSA uses 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 more detailed explanation, see xref:../rosa_architecture/cloud-experts-rosa-hcp-sts-explained.adoc#cloud-experts-rosa-hcp-sts-explained[AWS STS and ROSA with HCP explained].
|
||||
ROSA uses AWS Security Token Service (STS) with AWS IAM to obtain credentials to manage infrastructure in your AWS account. AWS STS is a global web service that creates temporary credentials for IAM users/roles or federated users/roles. 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 more detailed explanation, see xref:../rosa_architecture/cloud-experts-rosa-hcp-sts-explained.adoc#cloud-experts-rosa-hcp-sts-explained[AWS STS and ROSA with HCP explained].
|
||||
|
||||
== Key features of {hcp-title}
|
||||
|
||||
* *Cluster node scaling:* {hcp-title} requires a minimum of only two nodes, making it ideal for smaller projects while still being able to scale to support larger projects and enterprises. Easily add or remove compute nodes to match resource demand. Autoscaling allows you to automatically adjust the size of the cluster based on the current workload. See
|
||||
* *Cluster node scaling:* {hcp-title} requires a minimum of only two nodes, making it ideal for smaller projects while still being able to scale to support larger projects and enterprises. Easily add or remove compute nodes to match resource demand. Autoscaling allows you to automatically adjust the size of the cluster based on the current workload. See
|
||||
ifdef::openshift-rosa-hcp[]
|
||||
link:https://docs.openshift.com/rosa/rosa_cluster_admin/rosa_nodes/rosa-nodes-about-autoscaling-nodes.html#rosa-nodes-about-autoscaling-nodes[About autoscaling nodes on a cluster] for more details.
|
||||
endif::openshift-rosa-hcp[]
|
||||
@@ -33,20 +33,20 @@ xref:../rosa_cluster_admin/rosa_nodes/rosa-nodes-about-autoscaling-nodes.adoc#ro
|
||||
endif::openshift-rosa[]
|
||||
* *Fully managed underlying control plane infrastructure:* Control plane components, such as the API server and etcd database, are hosted in a Red{nbsp}Hat-owned AWS account.
|
||||
* *Rapid provisioning time:* Provisioning time is approximately 10 minutes.
|
||||
* *Continued cluster operation during upgrades:* Customers can upgrade the control plane and machine pools separately, which means they do not have to shut down the entire cluster during upgrades.
|
||||
* *Continued cluster operation during upgrades:* Customers can upgrade the control plane and machine pools separately, ensuring the cluster remains operational during the upgrade process.
|
||||
* *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{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). See the
|
||||
* *Fully integrated support experience:* 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). See the
|
||||
ifdef::openshift-rosa-hcp[]
|
||||
link:https://docs.openshift.com/rosa/support/getting-support.html#getting-support[ROSA support documentation] for more details.
|
||||
endif::openshift-rosa-hcp[]
|
||||
ifdef::openshift-rosa[]
|
||||
xref:../support/getting-support.adoc#getting-support[ROSA support documentation] for more details.
|
||||
endif::openshift-rosa[]
|
||||
* *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.
|
||||
* *AWS service integration:* AWS has a robust portfolio of cloud services, such as compute, storage, networking, database, analytics, Virtualization and AI. 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.
|
||||
* *Optimized clusters:* Choose from memory-optimized, compute-optimized, or general purpose EC2 instance types with clusters sized to meet your needs.
|
||||
* *Optimized clusters:* Choose from memory-optimized, compute-optimized, general purpose, or accelerated EC2 instance types with clusters to meet your needs.
|
||||
* *Global availability:* Refer to the xref:../rosa_architecture/rosa_policy_service_definition/rosa-hcp-service-definition.adoc#rosa-sdpolicy-regions-az_rosa-hcp-service-definition[product regional availability page] to see where ROSA is available globally.
|
||||
|
||||
include::modules/rosa-sdpolicy-am-billing.adoc[leveloffset=+1]
|
||||
@@ -61,41 +61,41 @@ Use the following sections to find content to help you learn about and use {hcp-
|
||||
|===
|
||||
| Learn about {hcp-title} |Plan {hcp-title} deployment |Additional resources
|
||||
|
||||
|
|
||||
|
|
||||
ifdef::openshift-rosa-hcp[]
|
||||
link:https://docs.openshift.com/rosa/architecture/index.html#architecture-overview[Architecture overview]
|
||||
endif::openshift-rosa-hcp[]
|
||||
ifndef::openshift-rosa-hcp[]
|
||||
xref:../architecture/index.adoc#architecture-overview[Architecture overview]
|
||||
endif::openshift-rosa-hcp[]
|
||||
|
|
||||
|
|
||||
ifdef::openshift-rosa-hcp[]
|
||||
link:https://docs.openshift.com/rosa/rosa_backing_up_and_restoring_applications/backing-up-applications.html#rosa-backing-up-applications[Back up and restore]
|
||||
endif::openshift-rosa-hcp[]
|
||||
ifndef::openshift-rosa-hcp[]
|
||||
xref:../backup_and_restore/application_backup_and_restore/oadp-intro.adoc#oadp-api[Back up and restore]
|
||||
endif::openshift-rosa-hcp[]
|
||||
|
|
||||
|
|
||||
xref:../rosa_architecture/rosa_policy_service_definition/rosa-hcp-life-cycle.adoc#rosa-hcp-life-cycle[{hcp-title} life cycle]
|
||||
|
|
||||
|
|
||||
ifdef::openshift-rosa-hcp[]
|
||||
link:https://docs.openshift.com/rosa/architecture/rosa-architecture-models.html#rosa-architecture-models[{hcp-title} architecture]
|
||||
endif::openshift-rosa-hcp[]
|
||||
ifndef::openshift-rosa-hcp[]
|
||||
xref:../architecture/rosa-architecture-models.adoc#rosa-architecture-models[{hcp-title} architecture]
|
||||
endif::openshift-rosa-hcp[]
|
||||
|
|
||||
|
|
||||
ifdef::openshift-rosa-hcp[]
|
||||
link:https://docs.openshift.com/rosa/rosa_architecture/rosa_policy_service_definition/rosa-policy-process-security.html#rosa-policy-process-security[Understanding process and security]
|
||||
endif::openshift-rosa-hcp[]
|
||||
ifndef::openshift-rosa-hcp[]
|
||||
xref:../../rosa_architecture/rosa_policy_service_definition/rosa-policy-process-security.adoc#rosa-policy-process-security[Understanding process and security]
|
||||
endif::openshift-rosa-hcp[]
|
||||
|
|
||||
|
|
||||
xref:../rosa_architecture/rosa_policy_service_definition/rosa-hcp-service-definition.adoc#rosa-hcp-service-definition[{hcp-title} service definition]
|
||||
|
|
||||
xref:../rosa_architecture/rosa_policy_service_definition/rosa-hcp-life-cycle.adoc#rosa-hcp-life-cycle[Updates lifecycle]
|
||||
|
|
||||
|
|
||||
// Removed as part of OSDOCS-13310, until figures are verified.
|
||||
// ifdef::openshift-rosa-hcp[]
|
||||
// link:https://docs.openshift.com/rosa/rosa_planning/rosa-limits-scalability.html#rosa-limits-scalability[Limits and scalability]
|
||||
@@ -103,7 +103,7 @@ xref:../rosa_architecture/rosa_policy_service_definition/rosa-hcp-life-cycle.ado
|
||||
// ifndef::openshift-rosa-hcp[]
|
||||
// xref:../../rosa_planning/rosa-limits-scalability.adoc#rosa-limits-scalability[Limits and scalability]
|
||||
// endif::openshift-rosa-hcp[]
|
||||
|
|
||||
|
|
||||
ifdef::openshift-rosa-hcp[]
|
||||
link:https://docs.openshift.com/rosa/support/index.html#support-overview[Getting support]
|
||||
endif::openshift-rosa-hcp[]
|
||||
@@ -120,23 +120,23 @@ endif::openshift-rosa-hcp[]
|
||||
[options="header",cols="4*"]
|
||||
|===
|
||||
|Learn about {hcp-title} |Deploy {hcp-title} |Manage {hcp-title} |Additional resources
|
||||
|
|
||||
|
|
||||
ifdef::openshift-rosa-hcp[]
|
||||
link:https://docs.openshift.com/rosa/architecture/rosa-architecture-models.html#rosa-architecture-models[{hcp-title} architecture]
|
||||
endif::openshift-rosa-hcp[]
|
||||
ifndef::openshift-rosa-hcp[]
|
||||
xref:../architecture/rosa-architecture-models.adoc#rosa-architecture-models[{hcp-title} architecture]
|
||||
endif::openshift-rosa-hcp[]
|
||||
|
|
||||
|
|
||||
xref:../rosa_hcp/rosa-hcp-sts-creating-a-cluster-quickly.adoc#rosa-hcp-sts-creating-a-cluster-quickly[Installing {hcp-title}]
|
||||
|
|
||||
|
|
||||
ifdef::openshift-rosa-hcp[]
|
||||
link:https://docs.openshift.com/rosa/observability/logging/cluster-logging.html#cluster-logging[Logging]
|
||||
endif::openshift-rosa-hcp[]
|
||||
ifndef::openshift-rosa-hcp[]
|
||||
xref:../observability/logging/cluster-logging.adoc#cluster-logging[Logging]
|
||||
endif::openshift-rosa-hcp[]
|
||||
|
|
||||
|
|
||||
ifdef::openshift-rosa-hcp[]
|
||||
link:https://docs.openshift.com/rosa/support/index.html#support-overview[Getting Support]
|
||||
endif::openshift-rosa-hcp[]
|
||||
@@ -147,16 +147,16 @@ endif::openshift-rosa-hcp[]
|
||||
|
||||
|
||||
| link:https://learn.openshift.com/?extIdCarryOver=true&sc_cid=701f2000001Css5AAC[OpenShift Interactive Learning Portal]
|
||||
|
|
||||
|
|
||||
xref:../storage/index.adoc#storage-overview[Storage]
|
||||
|
|
||||
|
|
||||
ifdef::openshift-rosa-hcp[]
|
||||
link:https://docs.openshift.com/rosa/observability/monitoring/about-openshift-container-platform-monitoring.html#about-ocp-monitoring[About {product-title} monitoring]
|
||||
endif::openshift-rosa-hcp[]
|
||||
ifndef::openshift-rosa-hcp[]
|
||||
xref:../observability/monitoring/about-ocp-monitoring/about-ocp-monitoring.adoc#about-ocp-monitoring[About {product-title} monitoring]
|
||||
endif::openshift-rosa-hcp[]
|
||||
|
|
||||
|
|
||||
xref:../rosa_architecture/rosa_policy_service_definition/rosa-hcp-life-cycle.adoc#rosa-hcp-life-cycle[{hcp-title} life cycle]
|
||||
|
|
||||
ifdef::openshift-rosa-hcp[]
|
||||
@@ -181,14 +181,14 @@ xref:../rosa_architecture/rosa-sts-about-iam-resources.adoc#rosa-sts-about-iam-r
|
||||
endif::openshift-rosa-hcp[]
|
||||
| link:https://red.ht/rosa-roadmap[ROSA roadmap]
|
||||
|
||||
|
|
||||
|
|
||||
ifdef::openshift-rosa-hcp[]
|
||||
link:https://docs.openshift.com/rosa/rosa_architecture/rosa_policy_service_definition/rosa-policy-understand-availability.html#rosa-policy-understand-availability[About availability]
|
||||
endif::openshift-rosa-hcp[]
|
||||
ifndef::openshift-rosa-hcp[]
|
||||
xref:../../rosa_architecture/rosa_policy_service_definition/rosa-policy-understand-availability.adoc#rosa-policy-understand-availability[About availability]
|
||||
endif::openshift-rosa-hcp[]
|
||||
|
|
||||
|
|
||||
xref:../upgrading/rosa-hcp-upgrading.adoc#rosa-hcp-upgrading[Upgrading]
|
||||
|
|
||||
|
|
||||
@@ -203,14 +203,14 @@ xref:../upgrading/rosa-hcp-upgrading.adoc#rosa-hcp-upgrading[Upgrading]
|
||||
|Learn about application development in {hcp-title} |Deploy applications |Additional resources
|
||||
|
||||
| link:https://developers.redhat.com/[Red{nbsp}Hat Developers site]
|
||||
|
|
||||
|
|
||||
ifdef::openshift-rosa-hcp[]
|
||||
link:https://docs.openshift.com/rosa/applications/index.html#building-applications-overview[Building applications overview]
|
||||
endif::openshift-rosa-hcp[]
|
||||
ifndef::openshift-rosa-hcp[]
|
||||
xref:../applications/index.adoc#building-applications-overview[Building applications overview]
|
||||
endif::openshift-rosa-hcp[]
|
||||
|
|
||||
|
|
||||
ifdef::openshift-rosa-hcp[]
|
||||
link:https://docs.openshift.com/rosa/support/index.html#support-overview[Getting support]
|
||||
endif::openshift-rosa-hcp[]
|
||||
@@ -218,7 +218,7 @@ ifndef::openshift-rosa-hcp[]
|
||||
xref:../support/index.adoc#support-overview[Getting support]
|
||||
endif::openshift-rosa-hcp[]
|
||||
| link:https://developers.redhat.com/products/openshift-dev-spaces/overview[{openshift-dev-spaces-productname} (formerly Red{nbsp}Hat CodeReady Workspaces)]
|
||||
|
|
||||
|
|
||||
ifdef::openshift-rosa-hcp[]
|
||||
link:https://docs.openshift.com/rosa/operators/index.html#operators-overview[Operators overview]
|
||||
endif::openshift-rosa-hcp[]
|
||||
@@ -228,7 +228,7 @@ endif::openshift-rosa-hcp[]
|
||||
| link:https://red.ht/rosa-roadmap[ROSA roadmap]
|
||||
|
||||
|
|
||||
|
|
||||
|
|
||||
ifdef::openshift-rosa-hcp[]
|
||||
link:https://docs.openshift.com/rosa/openshift_images/index.html#overview-of-images[Images]
|
||||
endif::openshift-rosa-hcp[]
|
||||
@@ -238,7 +238,7 @@ endif::openshift-rosa-hcp[]
|
||||
|
|
||||
|
||||
|
|
||||
|
|
||||
|
|
||||
ifdef::openshift-rosa-hcp[]
|
||||
link:https://docs.openshift.com/rosa/cli_reference/odo-important-update.html#odo-important_update[Developer-focused CLI]
|
||||
endif::openshift-rosa-hcp[]
|
||||
@@ -251,9 +251,10 @@ endif::openshift-rosa-hcp[]
|
||||
|
||||
=== Before creating your first ROSA cluster
|
||||
|
||||
Watch a link:https://youtu.be/KbzUbXWs6Ck[demo] of the cluster deployment process.
|
||||
//Per PM review, commented out until we get a valid ROSA HCP demo.
|
||||
// Watch a link:https://youtu.be/KbzUbXWs6Ck[demo] of the cluster deployment process.
|
||||
|
||||
For additional information about ROSA installation, see link:https://www.redhat.com/en/products/interactive-walkthrough/install-rosa[Installing Red{nbsp}Hat OpenShift Service on AWS (ROSA) interactive walkthrough].
|
||||
For additional information about ROSA installation, see a qucik introdcution to the process in link:https://www.redhat.com/en/products/interactive-walkthrough/install-rosa[Installing Red{nbsp}Hat OpenShift Service on AWS (ROSA) interactive walkthrough].
|
||||
|
||||
[role="_additional-resources"]
|
||||
== Additional resources
|
||||
|
||||
@@ -16,11 +16,12 @@ toc::[]
|
||||
[id="credential-methods-rosa-hcp"]
|
||||
== AWS STS credential method
|
||||
As part of {hcp-title}, Red{nbsp}Hat must be granted the necessary permissions to manage infrastructure resources in your AWS account.
|
||||
{hcp-title} grants the cluster's automation software limited, short-term access to resources in your AWS account.
|
||||
{hcp-title} IAM STS policies grants the cluster's automation software limited, short-term access to resources in your AWS account.
|
||||
|
||||
The STS method uses predefined roles and policies to grant temporary, least-privilege permissions to IAM roles. The credentials typically expire an hour after being requested. Once expired, they are no longer recognized by AWS and no longer have account access from API requests made with them. For more information, see the link:https://docs.aws.amazon.com/STS/latest/APIReference/welcome.html[AWS documentation].
|
||||
The STS method uses predefined roles and policies to grant temporary, least-privilege permissions to IAM roles. The credentials typically expire an hour after being requested. Once expired, they are no longer recognized by AWS and no longer have account access to make API requests with them. For more information, see the link:https://docs.aws.amazon.com/STS/latest/APIReference/welcome.html[AWS documentation].
|
||||
|
||||
AWS IAM STS roles must be created for each ROSA cluster. The ROSA command-line interface (CLI) (`rosa`) manages the STS roles and helps you attach the ROSA-specific, AWS managed policies to each role. The CLI provides the commands and files to create the roles, attach the AWS-managed policies, and an option to allow the CLI to automatically create the roles and attach the policies. Alternatively, the ROSA CLI can also provide you with the content to prepare the roles and attach the ROSA-specific AWS managed policies.
|
||||
|
||||
AWS IAM STS roles must be created for each {hcp-title} cluster. The ROSA command-line interface (CLI) (`rosa`) manages the STS roles and helps you attach the ROSA-specific, AWS-managed policies to each role. The CLI provides the commands and files to create the roles, attach the AWS-managed policies, and an option to allow the CLI to automatically create the roles and attach the policies.
|
||||
//See [insert new xref when we have one for HCP] for more information about the different `--mode` options.
|
||||
|
||||
[id="hcp-sts-security"]
|
||||
@@ -32,8 +33,9 @@ Security features for AWS STS include:
|
||||
* The service cannot do anything outside of those permissions.
|
||||
* There is no need to rotate or revoke credentials. Whenever the service needs to perform an action, it obtains credentials that expire in one hour or less.
|
||||
* Credential expiration reduces the risks of credentials leaking and being reused.
|
||||
* The ROSA-specific AWS managed policies are tightly scoped to only allow actions on ROSA-specific AWS resources in your account, within the limits of the AWS API.
|
||||
|
||||
{hcp-title} grants cluster software components least-privilege permissions with short-term security credentials to specific and segregated IAM roles. The credentials are associated with IAM roles specific to each component and cluster that makes AWS API calls. This method aligns with principles of least-privilege and secure practices in cloud service resource management.
|
||||
ROSA policies grant cluster software components with least-privilege permissions with short-term security credentials to specific and segregated IAM roles. The credentials are associated with IAM roles specific to each component and cluster that makes AWS API calls. This method aligns with principles of least-privilege and secure practices in cloud service resource management.
|
||||
|
||||
[id="components-specific-to-rosa-hcp-with-sts"]
|
||||
== Components of {hcp-title}
|
||||
@@ -94,11 +96,11 @@ Certain policies are used by the cluster Operator roles, listed below. The Opera
|
||||
[id="deploying-rosa-hcp-with-sts-cluster"]
|
||||
== Deploying a {hcp-title} cluster
|
||||
|
||||
Deploying a {hcp-title} cluster follows the following steps:
|
||||
Deploying a {hcp-title} cluster follows the following general steps:
|
||||
|
||||
. You create the account-wide roles.
|
||||
. You create the Operator roles.
|
||||
. Red{nbsp}Hat uses AWS STS to send the required permissions to AWS that allow AWS to create and attach the corresponding AWS-managed Operator policies.
|
||||
. Red{nbsp}Hat uses AWS IAM STS to send the required permissions to AWS that allow AWS to create and attach the corresponding AWS-managed Operator policies.
|
||||
. You create the OIDC provider.
|
||||
. You create the cluster.
|
||||
|
||||
@@ -110,9 +112,7 @@ The ROSA CLI can automatically create the roles for you, or you can manually cre
|
||||
== {hcp-title} workflow
|
||||
The user creates the required account-wide roles. 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. AWS assigns 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 user creates the Operator roles 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.
|
||||
|
||||
Once the user assigns the roles to the corresponding policy permissions, the final step is creating the OIDC provider.
|
||||
After both the account-wide operator roles and policies are created, the user can create a cluster. These operator roles are 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 in-cluster 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.
|
||||
|
||||
image::cloud-experts-sts-explained_creation_flow_hcp.png[]
|
||||
|
||||
|
||||
@@ -22,11 +22,16 @@ ifndef::openshift-rosa-hcp[]
|
||||
endif::openshift-rosa-hcp[]
|
||||
|
||||
include::modules/rosa-hcp-architecture.adoc[leveloffset=+1]
|
||||
include::modules/rosa-architecture.adoc[leveloffset=+1]
|
||||
include::modules/osd-aws-privatelink-architecture.adoc[leveloffset=+2]
|
||||
include::modules/rosa-architecture-local-zones.adoc[leveloffset=+2]
|
||||
|
||||
ifndef::openshift-rosa-hcp[]
|
||||
include::modules/rosa-architecture.adoc[leveloffset=+1]
|
||||
include::modules/osd-aws-privatelink-architecture.adoc[leveloffset=+2]
|
||||
//removing local zones module for now. May be applicable in the future per PM review.
|
||||
include::modules/rosa-architecture-local-zones.adoc[leveloffset=+2]
|
||||
endif::openshift-rosa-hcp[]
|
||||
|
||||
ifndef::openshift-rosa-hcp[]
|
||||
|
||||
.Additional resources
|
||||
|
||||
* xref:../rosa_cluster_admin/rosa_nodes/rosa-nodes-machinepools-configuring.html[Configuring machine pools in Local Zones]
|
||||
|
||||
@@ -114,7 +114,10 @@ ifdef::openshift-rosa-hcp[]
|
||||
endif::openshift-rosa-hcp[]
|
||||
|
||||
include::modules/rosa-sts-account-wide-role-and-policy-commands.adoc[leveloffset=+2]
|
||||
|
||||
ifndef::openshift-rosa-hcp[]
|
||||
include::modules/rosa-sts-aws-requirements-attaching-boundary-policy.adoc[leveloffset=+1]
|
||||
endif::openshift-rosa-hcp[]
|
||||
|
||||
[role="_additional-resources"]
|
||||
.Additional resources
|
||||
|
||||
@@ -46,6 +46,7 @@ include::modules/rosa-policy-change-management.adoc[leveloffset=+1]
|
||||
.Additional resources
|
||||
ifdef::openshift-rosa-hcp[]
|
||||
* xref:../../rosa_planning/rosa-hcp-aws-prereqs.adoc#rosa-hcp-firewall-prerequisites_rosa-hcp-aws-prereqs[Firewall prerequisites for {hcp-title}]
|
||||
// * xref:../../rosa_planning/rosa-sts-aws-prereqs.adoc#rosa-hcp-firewall-prerequisites_rosa-hcp-prereqs[Firewall prerequisites for {hcp-title}]
|
||||
endif::openshift-rosa-hcp[]
|
||||
ifdef::openshift-rosa[]
|
||||
* xref:../../rosa_planning/rosa-classic-aws-prereqs.adoc#rosa-classic-firewall-prerequisites_rosa-classic-aws-prereqs[Firewall prerequisites for ROSA (classic architecture) clusters using STS]
|
||||
@@ -63,8 +64,10 @@ endif::openshift-dedicated[]
|
||||
|
||||
include::modules/rosa-policy-security-and-compliance.adoc[leveloffset=+1]
|
||||
include::modules/rosa-policy-disaster-recovery.adoc[leveloffset=+1]
|
||||
include::modules/managed-resources.adoc[leveloffset=+1]
|
||||
|
||||
ifndef::openshift-rosa-hcp[]
|
||||
include::modules/managed-resources.adoc[leveloffset=+1]
|
||||
endif::openshift-rosa-hcp[]
|
||||
[role="_additional-resources"]
|
||||
.Additional resources
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
Cluster notifications are messages about the status, health, or performance of your cluster.
|
||||
Cluster notifications (sometimes referred to as service logs) are messages about the status, health, or performance of your cluster.
|
||||
|
||||
Cluster notifications are the primary way that Red Hat Site Reliability Engineering (SRE) communicates with you about the health of your managed cluster. SRE may also use cluster notifications to prompt you to perform an action in order to resolve or prevent an issue with your cluster.
|
||||
Cluster notifications are the primary way that Red Hat Site Reliability Engineering (SRE) communicates with you about the health of your managed cluster. Red Hat SRE may also use cluster notifications to prompt you to perform an action in order to resolve or prevent an issue with your cluster.
|
||||
//OSDOCS-8938: Omitted until an SME confirms this is true
|
||||
//For incident management purposes, notifications are also sent to your Red Hat account team, including your Technical Account Manager, if applicable.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user