mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-05 12:46:18 +01:00
[OSDOCS-5528]: Incorporate ccoctl upgrade steps for AliCloud
This commit is contained in:
Jeana Routh
@@ -569,7 +569,7 @@ Topics:
|
||||
- Name: Configuring additional devices in an IBM zSystems or IBM LinuxONE environment
|
||||
File: ibmz-post-install
|
||||
- Name: Regions and zones for a VMware vCenter
|
||||
File: post-install-vsphere-zones-regions-configuration
|
||||
File: post-install-vsphere-zones-regions-configuration
|
||||
- Name: Red Hat Enterprise Linux CoreOS image layering
|
||||
File: coreos-layering
|
||||
Distros: openshift-enterprise
|
||||
@@ -597,6 +597,8 @@ Topics:
|
||||
Distros: openshift-origin
|
||||
- Name: Preparing to perform an EUS-to-EUS update
|
||||
File: preparing-eus-eus-upgrade
|
||||
- Name: Preparing to update a cluster with manually maintained credentials
|
||||
File: preparing-manual-creds-update
|
||||
- Name: Updating a cluster using the web console
|
||||
File: updating-cluster-within-minor
|
||||
- Name: Updating a cluster using the CLI
|
||||
@@ -3874,7 +3876,7 @@ Topics:
|
||||
- Name: Resolving image tags to digests
|
||||
File: resolving-image-tags-to-digests
|
||||
- Name: Configuring TLS authentication
|
||||
File: serverless-config-tls
|
||||
File: serverless-config-tls
|
||||
- Name: Restrictive network policies
|
||||
File: restrictive-network-policies
|
||||
- Name: Traffic splitting
|
||||
|
||||
@@ -10,17 +10,12 @@ The Cloud Credential Operator (CCO) manages cloud provider credentials as custo
|
||||
|
||||
By setting different values for the `credentialsMode` parameter in the `install-config.yaml` file, the CCO can be configured to operate in several different modes. If no mode is specified, or the `credentialsMode` parameter is set to an empty string (`""`), the CCO operates in its default mode.
|
||||
|
||||
[id="about-cloud-credential-operator-modes"]
|
||||
[id="about-cloud-credential-operator-modes_{context}"]
|
||||
== Modes
|
||||
|
||||
By setting different values for the `credentialsMode` parameter in the `install-config.yaml` file, the CCO can be configured to operate in _mint_, _passthrough_, or _manual_ mode. These options provide transparency and flexibility in how the CCO uses cloud credentials to process `CredentialsRequest` CRs in the cluster, and allow the CCO to be configured to suit the security requirements of your organization. Not all CCO modes are supported for all cloud providers.
|
||||
|
||||
* **xref:../../authentication/managing_cloud_provider_credentials/cco-mode-mint.adoc#cco-mode-mint[Mint]**: In mint mode, the CCO uses the provided admin-level cloud credential to create new credentials for components in the cluster with only the specific permissions that are required.
|
||||
+
|
||||
[NOTE]
|
||||
====
|
||||
Mint mode is the default and recommended best practice setting for the CCO to use.
|
||||
====
|
||||
|
||||
* **xref:../../authentication/managing_cloud_provider_credentials/cco-mode-passthrough.adoc#cco-mode-passthrough[Passthrough]**: In passthrough mode, the CCO passes the provided cloud credential to the components that request cloud credentials.
|
||||
|
||||
@@ -82,7 +77,22 @@ Mint mode is the default and recommended best practice setting for the CCO to us
|
||||
1. Manual mode is the only supported CCO configuration for Microsoft Azure Stack Hub.
|
||||
--
|
||||
|
||||
[id="about-cloud-credential-operator-default"]
|
||||
[id="cco-determine-mode_{context}"]
|
||||
== Determining the Cloud Credential Operator mode
|
||||
|
||||
For platforms that support using the CCO in multiple modes, you can determine what mode the CCO is configured to use by using the web console or the CLI.
|
||||
|
||||
//To-do: add this in when available (gfx request #334)
|
||||
//.[PLACEHOLDER] Determining the CCO configuration
|
||||
//image::placeholder_CCO_decision_tree_about_cco.png[Decision tree showing how to determine the configured CCO credentials mode for your cluster.]
|
||||
|
||||
//Determining the Cloud Credential Operator mode by using the web console
|
||||
include::modules/cco-determine-mode-gui.adoc[leveloffset=+2]
|
||||
|
||||
//Determining the Cloud Credential Operator mode by using the CLI
|
||||
include::modules/cco-determine-mode-cli.adoc[leveloffset=+2]
|
||||
|
||||
[id="about-cloud-credential-operator-default_{context}"]
|
||||
== Default behavior
|
||||
For platforms on which multiple modes are supported (AWS, Azure, and GCP), when the CCO operates in its default mode, it checks the provided credentials dynamically to determine for which mode they are sufficient to process `CredentialsRequest` CRs.
|
||||
|
||||
@@ -95,7 +105,7 @@ If the credentials are changed after a successful installation and the CCO deter
|
||||
To resolve insufficient credentials issues, provide a credential with sufficient permissions. If an error occurred during installation, try installing again. For issues with new `CredentialsRequest` CRs, wait for the CCO to try to process the CR again. As an alternative, you can manually create IAM for xref:../../installing/installing_aws/manually-creating-iam.adoc#manually-creating-iam-aws[AWS], xref:../../installing/installing_azure/manually-creating-iam-azure.adoc#manually-creating-iam-azure[Azure], and xref:../../installing/installing_gcp/manually-creating-iam-gcp.adoc#manually-creating-iam-gcp[GCP].
|
||||
|
||||
[role="_additional-resources"]
|
||||
[id="additional-resources_about-cloud-credential-operator"]
|
||||
[id="additional-resources_about-cloud-credential-operator_{context}"]
|
||||
== Additional resources
|
||||
|
||||
* xref:../../operators/operator-reference.adoc#cloud-credential-operator_cluster-operators-ref[Cluster Operators reference page for the Cloud Credential Operator]
|
||||
|
||||
@@ -97,13 +97,15 @@ To install a cluster that is configured to use the Cloud Credential Operator (CC
|
||||
. xref:../../authentication/managing_cloud_provider_credentials/cco-mode-gcp-workload-identity.adoc#sts-mode-installing-manual-run-installer_cco-mode-gcp-workload-identity[Run the {product-title} installer].
|
||||
. xref:../../authentication/managing_cloud_provider_credentials/cco-mode-gcp-workload-identity.adoc#sts-mode-installing-verifying_cco-mode-gcp-workload-identity[Verify that the cluster is using short-lived credentials].
|
||||
|
||||
////
|
||||
// Remove until upgrade is supported.
|
||||
[NOTE]
|
||||
====
|
||||
Because the cluster is operating in manual mode when using GCP Workload Identity, it is not able to create new credentials for components with the permissions that they require. When upgrading to a different minor version of {product-title}, there are often new GCP permission requirements. Before upgrading a cluster that is using GCP Workload Identity, the cluster administrator must manually ensure that the GCP permissions are sufficient for existing components and available to any new components.
|
||||
====
|
||||
////
|
||||
|
||||
[role="_additional-resources"]
|
||||
.Additional resources
|
||||
|
||||
* xref:../../updating/preparing-manual-creds-update.adoc#cco-ccoctl-configuring_preparing-manual-creds-update[Configuring the Cloud Credential Operator utility for a cluster update]
|
||||
|
||||
//Task part 1: Configuring the Cloud Credential Operator utility
|
||||
include::modules/cco-ccoctl-configuring.adoc[leveloffset=+2]
|
||||
@@ -117,17 +119,8 @@ include::modules/sts-mode-installing-manual-run-installer.adoc[leveloffset=+2]
|
||||
//Task part 4: Verify that the cluster is using short-lived credentials
|
||||
include::modules/sts-mode-installing-verifying.adoc[leveloffset=+2]
|
||||
|
||||
[id="gcp-workload-identity-mode-upgrading"]
|
||||
== Upgrading an {product-title} cluster configured for manual mode with GCP Workload Identity
|
||||
[role="_additional-resources"]
|
||||
[id="additional-resources_{context}"]
|
||||
== Additional resources
|
||||
|
||||
The release image for the version of {product-title} that you are upgrading to contains a version of the `ccoctl` binary and list of `CredentialsRequest` objects specific to that release.
|
||||
|
||||
:context: wif-mode-upgrading
|
||||
|
||||
include::modules/cco-ccoctl-configuring.adoc[leveloffset=+2]
|
||||
|
||||
include::modules/cco-ccoctl-upgrading.adoc[leveloffset=+2]
|
||||
|
||||
include::modules/manually-maintained-credentials-upgrade.adoc[leveloffset=+2]
|
||||
|
||||
:context: cco-mode-gcp-workload-identity
|
||||
* xref:../../updating/preparing-manual-creds-update.adoc#preparing-manual-creds-update[Preparing to update a cluster with manually maintained credentials]
|
||||
|
||||
@@ -12,22 +12,37 @@ In manual mode, a user manages cloud credentials instead of the Cloud Credential
|
||||
|
||||
Using manual mode allows each cluster component to have only the permissions it requires, without storing an administrator-level credential in the cluster. This mode also does not require connectivity to the AWS public IAM endpoint. However, you must manually reconcile permissions with new release images for every upgrade.
|
||||
|
||||
For information about configuring your cloud provider to use manual mode, see _Manually creating RAM resources_ for xref:../../installing/installing_alibaba/installing-alibaba-default.adoc#installation-initializing_installing-alibaba-default[Alibaba Cloud], xref:../../installing/installing_aws/manually-creating-iam.adoc#manually-creating-iam-aws[AWS], xref:../../installing/installing_azure/manually-creating-iam-azure.adoc#manually-creating-iam-azure[Azure], xref:../../installing/installing_ibm_cloud_public/configuring-iam-ibm-cloud.adoc#configuring-iam-ibm-cloud[IBM Cloud], or xref:../../installing/installing_gcp/manually-creating-iam-gcp.adoc#manually-creating-iam-gcp[GCP].
|
||||
For information about configuring your cloud provider to use manual mode, see the manual credentials management options for your cloud provider:
|
||||
|
||||
* xref:../../installing/installing_alibaba/manually-creating-alibaba-ram.adoc#manually-creating-alibaba-ram[Manually creating RAM resources for Alibaba Cloud]
|
||||
* xref:../../installing/installing_aws/manually-creating-iam.adoc#manually-creating-iam-aws[Manually creating IAM for AWS]
|
||||
* xref:../../installing/installing_azure/manually-creating-iam-azure.adoc#manually-creating-iam-azure[Manually creating IAM for Azure]
|
||||
* xref:../../installing/installing_gcp/manually-creating-iam-gcp.adoc#manually-creating-iam-gcp[Manually creating IAM for GCP]
|
||||
* xref:../../installing/installing_ibm_cloud_public/configuring-iam-ibm-cloud.adoc#configuring-iam-ibm-cloud[Configuring IAM for IBM Cloud]
|
||||
* xref:../../installing/installing_nutanix/installing-nutanix-installer-provisioned.adoc#manually-create-iam-nutanix_installing-nutanix-installer-provisioned[Configuring IAM for Nutanix]
|
||||
|
||||
[id="manual-mode-sts-blurb"]
|
||||
== Manual mode with AWS STS
|
||||
== Manual mode with cloud credentials created and managed outside of the cluster
|
||||
|
||||
You can configure an AWS cluster in manual mode to use xref:../../authentication/managing_cloud_provider_credentials/cco-mode-sts.adoc#cco-mode-sts[Amazon Web Services Security Token Service (AWS STS)]. With this configuration, the CCO uses temporary credentials for different components.
|
||||
An AWS or GCP cluster that uses manual mode might be configured to create and manage cloud credentials from outside of the cluster using the AWS Security Token Service (STS) or GCP Workload Identity. With this configuration, the CCO uses temporary credentials for different components.
|
||||
|
||||
For more information, see xref:../../authentication/managing_cloud_provider_credentials/cco-mode-sts.adoc#cco-mode-sts[Using manual mode with Amazon Web Services Security Token Service] or xref:../../authentication/managing_cloud_provider_credentials/cco-mode-gcp-workload-identity.adoc#cco-mode-gcp-workload-identity[Using manual mode with GCP Workload Identity].
|
||||
|
||||
//Updating cloud provider resources with manually maintained credentials
|
||||
include::modules/manually-maintained-credentials-upgrade.adoc[leveloffset=+1]
|
||||
|
||||
//Indicating that the cluster is ready to upgrade
|
||||
include::modules/cco-manual-upgrade-annotation.adoc[leveloffset=+2]
|
||||
|
||||
[role="_additional-resources"]
|
||||
[id="additional-resources_cco-mode-manual"]
|
||||
== Additional resources
|
||||
|
||||
* xref:../../installing/installing_alibaba/manually-creating-alibaba-ram.adoc#manually-creating-alibaba-ram[Manually creating RAM resources for Alibaba Cloud]
|
||||
* xref:../../installing/installing_aws/manually-creating-iam.adoc#manually-creating-iam-aws[Manually creating IAM for AWS]
|
||||
* xref:../../authentication/managing_cloud_provider_credentials/cco-mode-sts.adoc#cco-mode-sts[Using manual mode with Amazon Web Services Security Token Service]
|
||||
* xref:../../installing/installing_azure/manually-creating-iam-azure.adoc#manually-creating-iam-azure[Manually creating IAM for Azure]
|
||||
* xref:../../installing/installing_gcp/manually-creating-iam-gcp.adoc#manually-creating-iam-gcp[Manually creating IAM for GCP]
|
||||
* xref:../../authentication/managing_cloud_provider_credentials/cco-mode-gcp-workload-identity.adoc#cco-mode-gcp-workload-identity[Using manual mode with GCP Workload Identity]
|
||||
* xref:../../installing/installing_ibm_cloud_public/configuring-iam-ibm-cloud.adoc#configuring-iam-ibm-cloud[Configuring IAM for IBM Cloud]
|
||||
* xref:../../authentication/managing_cloud_provider_credentials/cco-mode-sts.adoc#cco-mode-sts[Using manual mode with AWS STS]
|
||||
* xref:../../installing/installing_nutanix/installing-nutanix-installer-provisioned.adoc#manually-create-iam-nutanix_installing-nutanix-installer-provisioned[Configuring IAM for Nutanix]
|
||||
|
||||
@@ -13,7 +13,7 @@ Manual mode with STS is supported for Amazon Web Services (AWS).
|
||||
This credentials strategy is supported for only new {product-title} clusters and must be configured during installation. You cannot reconfigure an existing cluster that uses a different credentials strategy to use this feature.
|
||||
====
|
||||
|
||||
[id="sts-mode-about"]
|
||||
[id="sts-mode-about_{context}"]
|
||||
== About manual mode with AWS Security Token Service
|
||||
|
||||
In manual mode with STS, the individual {product-title} cluster components use AWS Security Token Service (STS) to assign components IAM roles that provide short-term, limited-privilege security credentials. These credentials are associated with IAM roles that are specific to each component that makes AWS API calls.
|
||||
@@ -66,7 +66,7 @@ stringData:
|
||||
<4> The path to the service account token inside the pod. By convention, this is `/var/run/secrets/openshift/serviceaccount/token` for {product-title} components.
|
||||
|
||||
//Supertask: Installing an OCP cluster configured for manual mode with STS
|
||||
[id="sts-mode-installing"]
|
||||
[id="sts-mode-installing_{context}"]
|
||||
== Installing an {product-title} cluster configured for manual mode with STS
|
||||
|
||||
To install a cluster that is configured to use the Cloud Credential Operator (CCO) in manual mode with STS:
|
||||
@@ -82,13 +82,18 @@ To install a cluster that is configured to use the Cloud Credential Operator (CC
|
||||
Because the cluster is operating in manual mode when using STS, it is not able to create new credentials for components with the permissions that they require. When upgrading to a different minor version of {product-title}, there are often new AWS permission requirements. Before upgrading a cluster that is using STS, the cluster administrator must manually ensure that the AWS permissions are sufficient for existing components and available to any new components.
|
||||
====
|
||||
|
||||
[role="_additional-resources"]
|
||||
.Additional resources
|
||||
|
||||
* xref:../../updating/preparing-manual-creds-update.adoc#cco-ccoctl-configuring_preparing-manual-creds-update[Configuring the Cloud Credential Operator utility for a cluster update]
|
||||
|
||||
//[pre-4.8]Task part 1: Creating AWS resources manually
|
||||
//include::modules/sts-mode-installing-manual-config.adoc[leveloffset=+2]
|
||||
|
||||
//Task part 1: Configuring the Cloud Credential Operator utility
|
||||
include::modules/cco-ccoctl-configuring.adoc[leveloffset=+2]
|
||||
|
||||
[id="sts-mode-create-aws-resources-ccoctl"]
|
||||
[id="sts-mode-create-aws-resources-ccoctl_{context}"]
|
||||
=== Creating AWS resources with the Cloud Credential Operator utility
|
||||
|
||||
You can use the CCO utility (`ccoctl`) to create the required AWS resources xref:../../authentication/managing_cloud_provider_credentials/cco-mode-sts.adoc#cco-ccoctl-creating-individually_cco-mode-sts[individually], or xref:../../authentication/managing_cloud_provider_credentials/cco-mode-sts.adoc#cco-ccoctl-creating-at-once_cco-mode-sts[with a single command].
|
||||
@@ -105,17 +110,8 @@ include::modules/sts-mode-installing-manual-run-installer.adoc[leveloffset=+2]
|
||||
//Task part 4: Verify that the cluster is using short-lived credentials
|
||||
include::modules/sts-mode-installing-verifying.adoc[leveloffset=+2]
|
||||
|
||||
[id="sts-mode-upgrading"]
|
||||
== Upgrading an {product-title} cluster configured for manual mode with STS
|
||||
[role="_additional-resources"]
|
||||
[id="additional-resources_{context}"]
|
||||
== Additional resources
|
||||
|
||||
The release image for the version of {product-title} that you are upgrading to contains a version of the `ccoctl` binary and list of `CredentialsRequest` objects specific to that release.
|
||||
|
||||
:context: sts-mode-upgrading
|
||||
|
||||
include::modules/cco-ccoctl-configuring.adoc[leveloffset=+2]
|
||||
|
||||
include::modules/cco-ccoctl-upgrading.adoc[leveloffset=+2]
|
||||
|
||||
include::modules/manually-maintained-credentials-upgrade.adoc[leveloffset=+2]
|
||||
|
||||
:context: cco-mode-sts
|
||||
* xref:../../updating/preparing-manual-creds-update.adoc#preparing-manual-creds-update[Preparing to update a cluster with manually maintained credentials]
|
||||
|
||||
@@ -16,6 +16,9 @@ include::modules/manually-creating-alibaba-ram-user.adoc[leveloffset=+1]
|
||||
|
||||
//Task part 2: Configuring the Cloud Credential Operator utility
|
||||
include::modules/cco-ccoctl-configuring.adoc[leveloffset=+1]
|
||||
[role="_additional-resources"]
|
||||
.Additional resources
|
||||
* xref:../../updating/preparing-manual-creds-update.adoc#preparing-manual-creds-update[Preparing to update a cluster with manually maintained credentials]
|
||||
|
||||
//Task part 3: Creating Alibaba resources with a single command
|
||||
// modules/cco-ccoctl-creating-at-once.adoc[leveloffset=+1]
|
||||
|
||||
@@ -39,8 +39,7 @@ include::modules/manually-create-identity-access-management.adoc[leveloffset=+1]
|
||||
[role="_additional-resources"]
|
||||
[id="additional-resources_installing-azure-stack-hub-default-cco"]
|
||||
.Additional resources
|
||||
* xref:../../updating/updating-cluster-within-minor.adoc#manually-maintained-credentials-upgrade_updating-cluster-within-minor[Updating a cluster using the web console]
|
||||
* xref:../../updating/updating-cluster-cli.adoc#manually-maintained-credentials-upgrade_updating-cluster-cli[Updating a cluster using the CLI]
|
||||
* xref:../../updating/preparing-manual-creds-update.adoc#manually-maintained-credentials-upgrade_preparing-manual-creds-update[Updating cloud provider resources with manually maintained credentials]
|
||||
|
||||
include::modules/azure-stack-hub-internal-ca.adoc[leveloffset=+1]
|
||||
|
||||
|
||||
@@ -22,6 +22,7 @@ include::modules/alternatives-to-storing-admin-secrets-in-kube-system.adoc[level
|
||||
|
||||
include::modules/manually-create-identity-access-management.adoc[leveloffset=+1]
|
||||
|
||||
// I was going to update this but I think the assembly is no longer used and will ask install team if I can get rid of it entirely.
|
||||
include::modules/manually-maintained-credentials-upgrade.adoc[leveloffset=+1]
|
||||
|
||||
[id="next-steps_manually-creating-iam-azure-stack-hub"]
|
||||
|
||||
@@ -16,8 +16,6 @@ include::modules/alternatives-to-storing-admin-secrets-in-kube-system.adoc[level
|
||||
* xref:../../authentication/managing_cloud_provider_credentials/about-cloud-credential-operator.adoc#about-cloud-credential-operator[About the Cloud Credential Operator]
|
||||
|
||||
include::modules/cco-ccoctl-configuring.adoc[leveloffset=+1]
|
||||
//include::modules/manually-maintained-credentials-upgrade.adoc[leveloffset=+1]
|
||||
// Will need to revisit upgrade scenario for IBM Cloud; not needed until OCP 4.11. Tentative instructions have been added for reference later.
|
||||
|
||||
[role="_additional-resources"]
|
||||
[id="additional-resources_configuring-iam-ibm-cloud-refreshing-ids"]
|
||||
@@ -27,3 +25,9 @@ include::modules/cco-ccoctl-configuring.adoc[leveloffset=+1]
|
||||
[id="next-steps_configuring-iam-ibm-cloud"]
|
||||
== Next steps
|
||||
* xref:../../installing/installing_ibm_cloud_public/installing-ibm-cloud-customizations.adoc#installing-ibm-cloud-customizations[Installing a cluster on IBM Cloud VPC with customizations]
|
||||
|
||||
[role="_additional-resources"]
|
||||
[id="additional-resources_{context}"]
|
||||
== Additional resources
|
||||
|
||||
* xref:../../updating/preparing-manual-creds-update.adoc#preparing-manual-creds-update[Preparing to update a cluster with manually maintained credentials]
|
||||
@@ -11,3 +11,6 @@ Before you install an {product-title} cluster, be sure that your Nutanix environ
|
||||
include::modules/installation-nutanix-infrastructure.adoc[leveloffset=+1]
|
||||
include::modules/installation-nutanix-installer-infra-reqs.adoc[leveloffset=+1]
|
||||
include::modules/cco-ccoctl-configuring.adoc[leveloffset=+1]
|
||||
[role="_additional-resources"]
|
||||
.Additional resources
|
||||
* xref:../../updating/preparing-manual-creds-update.adoc#preparing-manual-creds-update[Preparing to update a cluster with manually maintained credentials]
|
||||
58
modules/about-manually-maintained-credentials-upgrade.adoc
Normal file
58
modules/about-manually-maintained-credentials-upgrade.adoc
Normal file
@@ -0,0 +1,58 @@
|
||||
// Module included in the following assemblies:
|
||||
//
|
||||
// * updating/preparing-manual-creds-update.adoc
|
||||
// * authentication/managing_cloud_provider_credentials/about-cloud-credential-operator.adoc
|
||||
|
||||
:_content-type: CONCEPT
|
||||
|
||||
[id="about-manually-maintained-credentials-upgrade_{context}"]
|
||||
= Update requirements for clusters with manually maintained credentials
|
||||
|
||||
Before you update a cluster that uses manually maintained credentials with the Cloud Credential Operator (CCO), you must update the cloud provider resources for the new release.
|
||||
|
||||
If the cloud credential management for your cluster was configured using the CCO utility (`ccoctl`), use the `ccoctl` utility to update the resources. Clusters that were configured to use manual mode without the `ccoctl` utility require manual updates for the resources.
|
||||
|
||||
After updating the cloud provider resources, you must update the `upgradeable-to` annotation for the cluster to indicate that it is ready to update.
|
||||
|
||||
[NOTE]
|
||||
====
|
||||
The process to update the cloud provider resources and the `upgradeable-to` annotation can only be completed by using command line tools.
|
||||
====
|
||||
|
||||
[id="cco-platform-options_{context}"]
|
||||
== Cloud credential configuration options and update requirements by platform type
|
||||
|
||||
Some platforms only support using the CCO in one mode. For clusters that are installed on those platforms, the platform type determines the credentials update requirements.
|
||||
|
||||
For platforms that support using the CCO in multiple modes, you must determine which mode the cluster is configured to use and take the required actions for that configuration.
|
||||
|
||||
//To-do: add this in when available (gfx request #334)
|
||||
//.[PLACEHOLDER] Credentials update requirements by platform type
|
||||
//image::placeholder_CCO_decision_tree_update.png[Decision tree showing the possible update paths for your cluster depending on the configured CCO credentials mode.]
|
||||
|
||||
{rh-openstack-first}, {rh-virtualization-first}, and VMware vSphere::
|
||||
These platforms do not support using the CCO in manual mode. Clusters on these platforms handle changes in cloud provider resources automatically and do not require an update to the `upgradeable-to` annotation.
|
||||
+
|
||||
Administrators of clusters on these platforms should skip the manually maintained credentials section of the update process.
|
||||
|
||||
{alibaba}, IBM Cloud, and Nutanix::
|
||||
Clusters installed on these platforms are configured using the `ccoctl` utility.
|
||||
+
|
||||
Administrators of clusters on these platforms must take the following actions:
|
||||
+
|
||||
. Configure the `ccoctl` utility for the new release.
|
||||
. Use the `ccoctl` utility to update the cloud provider resources.
|
||||
. Indicate that the cluster is ready to update with the `upgradeable-to` annotation.
|
||||
|
||||
Microsoft Azure Stack Hub::
|
||||
These clusters use manual mode with long-lived credentials and do not use the `ccoctl` utility.
|
||||
+
|
||||
Administrators of clusters on these platforms must take the following actions:
|
||||
+
|
||||
. Manually update the cloud provider resources for the new release.
|
||||
. Indicate that the cluster is ready to update with the `upgradeable-to` annotation.
|
||||
|
||||
Amazon Web Services (AWS), global Microsoft Azure, and Google Cloud Platform (GCP)::
|
||||
Clusters installed on these platforms support multiple CCO modes.
|
||||
+
|
||||
The required update process depends on the mode that the cluster is configured to use. If you are not sure what mode the CCO is configured to use on your cluster, you can use the web console or the CLI to determine this information.
|
||||
@@ -4,12 +4,14 @@
|
||||
// * authentication/managing_cloud_provider_credentials/cco-mode-gcp-workload-identity.adoc
|
||||
// * installing/installing_ibm_cloud_public/configuring-iam-ibm-cloud.adoc
|
||||
// * installing/installing_alibaba/manually-creating-alibaba-ram.adoc
|
||||
// * installing/installing_nutanix/preparing-to-install-on-nutanix.adoc
|
||||
// * updating/preparing-manual-creds-update.adoc
|
||||
|
||||
ifeval::["{context}" == "cco-mode-sts"]
|
||||
:aws-sts:
|
||||
endif::[]
|
||||
ifeval::["{context}" == "sts-mode-upgrading"]
|
||||
:aws-sts:
|
||||
ifeval::["{context}" == "cco-mode-gcp-workload-identity"]
|
||||
:google-cloud-platform:
|
||||
endif::[]
|
||||
ifeval::["{context}" == "configuring-iam-ibm-cloud"]
|
||||
:ibm-cloud:
|
||||
@@ -17,44 +19,56 @@ endif::[]
|
||||
ifeval::["{context}" == "manually-creating-alibaba-ram"]
|
||||
:alibabacloud:
|
||||
endif::[]
|
||||
ifeval::["{context}" == "cco-mode-gcp-workload-identity"]
|
||||
:google-cloud-platform:
|
||||
endif::[]
|
||||
ifeval::["{context}" == "wif-mode-upgrading"]
|
||||
:google-cloud-platform:
|
||||
endif::[]
|
||||
ifeval::["{context}" == "preparing-to-install-on-nutanix"]
|
||||
:nutanix:
|
||||
endif::[]
|
||||
ifeval::["{context}" == "preparing-manual-creds-update"]
|
||||
:update:
|
||||
endif::[]
|
||||
|
||||
:_content-type: PROCEDURE
|
||||
[id="cco-ccoctl-configuring_{context}"]
|
||||
= Configuring the Cloud Credential Operator utility
|
||||
ifndef::update[= Configuring the Cloud Credential Operator utility]
|
||||
ifdef::update[= Configuring the Cloud Credential Operator utility for a cluster update]
|
||||
|
||||
//This applies only to Alibaba Cloud.
|
||||
ifdef::alibabacloud[]
|
||||
To assign RAM users and policies that provide long-lived RAM AccessKeys (AKs) for each in-cluster component, extract and prepare the Cloud Credential Operator (CCO) utility (`ccoctl`) binary.
|
||||
endif::alibabacloud[]
|
||||
|
||||
//Nutanix-only intro because it needs context in its install procedure.
|
||||
ifdef::nutanix[]
|
||||
The Cloud Credential Operator (CCO) manages cloud provider credentials as Kubernetes custom resource definitions (CRDs). To install a cluster on Nutanix, you must set the CCO to `manual` mode as part of the installation process.
|
||||
endif::nutanix[]
|
||||
|
||||
ifndef::alibabacloud[]
|
||||
To create and manage cloud credentials from outside of the cluster when the Cloud Credential Operator (CCO) is operating in
|
||||
ifdef::ibm-cloud,nutanix[manual mode,]
|
||||
ifdef::aws-sts[manual mode with STS,]
|
||||
ifdef::google-cloud-platform[manual mode with GCP Workload Identity,]
|
||||
extract and prepare the CCO utility (`ccoctl`) binary.
|
||||
endif::alibabacloud[]
|
||||
//Alibaba Cloud uses ccoctl, but creates different kinds of resources than other clouds, so this applies to everyone else. The upgrade procs also have a different intro, so they are excluded here.
|
||||
ifndef::alibabacloud,update[]
|
||||
To create and manage cloud credentials from outside of the cluster when the Cloud Credential Operator (CCO) is operating in manual mode, extract and prepare the CCO utility (`ccoctl`) binary.
|
||||
endif::alibabacloud,update[]
|
||||
|
||||
ifdef::alibabacloud[]
|
||||
To assign RAM users and policies that provide long-lived RAM AccessKeys (AKs) for each in-cluster component, extract and prepare the {product-title} Cloud Credential Operator (CCO) utility (`ccoctl`) binary.
|
||||
endif::alibabacloud[]
|
||||
//Intro for the upgrade procs.
|
||||
ifdef::update[]
|
||||
To upgrade a cluster that uses the Cloud Credential Operator (CCO) in manual mode to create and manage cloud credentials from outside of the cluster, extract and prepare the CCO utility (`ccoctl`) binary.
|
||||
endif::update[]
|
||||
|
||||
[NOTE]
|
||||
====
|
||||
The `ccoctl` is a Linux binary that must run in a Linux environment.
|
||||
The `ccoctl` utility is a Linux binary that must run in a Linux environment.
|
||||
====
|
||||
|
||||
ifdef::aws-sts[]
|
||||
.Prerequisites
|
||||
|
||||
* You have created an AWS account for the `ccoctl` to use with the following permissions:
|
||||
* You have access to an {product-title} account with cluster administrator access.
|
||||
* You have installed the OpenShift CLI (`oc`).
|
||||
|
||||
//Upgrade prereqs
|
||||
ifdef::update[]
|
||||
* Your cluster was configured using the `ccoctl` utility to create and manage cloud credentials from outside of the cluster.
|
||||
endif::update[]
|
||||
|
||||
//AWS permissions needed when running ccoctl during install (I think we can omit from upgrade, since they already have an appropriate AWS account if they are upgrading).
|
||||
ifdef::aws-sts[]
|
||||
* You have created an AWS account for the `ccoctl` utility to use with the following permissions:
|
||||
+
|
||||
.Required AWS permissions
|
||||
[cols="a,a"]
|
||||
@@ -163,8 +177,8 @@ Use "ccoctl [command] --help" for more information about a command.
|
||||
ifeval::["{context}" == "cco-mode-sts"]
|
||||
:!aws-sts:
|
||||
endif::[]
|
||||
ifeval::["{context}" == "sts-mode-upgrading"]
|
||||
:!aws-sts:
|
||||
ifeval::["{context}" == "cco-mode-gcp-workload-identity"]
|
||||
:!google-cloud-platform:
|
||||
endif::[]
|
||||
ifeval::["{context}" == "configuring-iam-ibm-cloud"]
|
||||
:!ibm-cloud:
|
||||
@@ -172,12 +186,9 @@ endif::[]
|
||||
ifeval::["{context}" == "manually-creating-alibaba-ram"]
|
||||
:!alibabacloud:
|
||||
endif::[]
|
||||
ifeval::["{context}" == "cco-mode-gcp-workload-identity"]
|
||||
:!google-cloud-platform:
|
||||
endif::[]
|
||||
ifeval::["{context}" == "wif-mode-upgrading"]
|
||||
:!google-cloud-platform:
|
||||
endif::[]
|
||||
ifeval::["{context}" == "preparing-to-install-on-nutanix"]
|
||||
:!nutanix:
|
||||
endif::[]
|
||||
ifeval::["{context}" == "preparing-manual-creds-update"]
|
||||
:!update:
|
||||
endif::[]
|
||||
|
||||
@@ -1,31 +1,19 @@
|
||||
// Module included in the following assemblies:
|
||||
//
|
||||
// * authentication/managing_cloud_provider_credentials/cco-mode-sts.adoc
|
||||
// NOTE: This module is included in the cco-mode-sts.adoc assembly, but is included past the secondary/temporary context established for the upgrade steps (sts-mode-upgrading). Thus the context evaluation for AWS is set to the temporary context rather than cco-mode-sts.
|
||||
// * updating/preparing-manual-creds-update.adoc
|
||||
|
||||
ifeval::["{context}" == "sts-mode-upgrading"]
|
||||
:aws-sts:
|
||||
endif::[]
|
||||
ifeval::["{context}" == "wif-mode-upgrading"]
|
||||
:google-cloud-platform:
|
||||
endif::[]
|
||||
|
||||
:_content-type: PROCEDURE
|
||||
[id="cco-ccoctl-upgrading_{context}"]
|
||||
= Updating cloud provider resources with the Cloud Credential Operator utility
|
||||
|
||||
The process for upgrading an {product-title} cluster configured for
|
||||
ifdef::aws-sts[manual mode with STS]
|
||||
ifdef::google-cloud-platform[manual mode with GCP Workload Identity]
|
||||
is similar to creating the cloud provider resources during installation.
|
||||
The process for upgrading an {product-title} cluster that was configured using the CCO utility (`ccoctl`) is similar to creating the cloud provider resources during installation.
|
||||
|
||||
[NOTE]
|
||||
====
|
||||
By default, `ccoctl` creates objects in the directory in which the commands are run. To create the objects in a different directory, use the `--output-dir` flag. This procedure uses `<path_to_ccoctl_output_dir>` to refer to this directory.
|
||||
ifdef::aws-sts[]
|
||||
|
||||
Some `ccoctl` commands make AWS API calls to create or modify AWS resources. You can use the `--dry-run` flag to avoid making API calls. Using this flag creates JSON files on the local file system instead. You can review and modify the JSON files and then apply them with the AWS CLI tool using the `--cli-input-json` parameters.
|
||||
endif::aws-sts[]
|
||||
On AWS clusters, some `ccoctl` commands make AWS API calls to create or modify AWS resources. You can use the `--dry-run` flag to avoid making API calls. Using this flag creates JSON files on the local file system instead. You can review and modify the JSON files and then apply them with the AWS CLI tool using the `--cli-input-json` parameters.
|
||||
====
|
||||
|
||||
.Prerequisites
|
||||
@@ -41,17 +29,20 @@ endif::aws-sts[]
|
||||
[source,terminal]
|
||||
----
|
||||
$ oc adm release extract --credentials-requests \
|
||||
ifdef::aws-sts[--cloud=aws \]
|
||||
ifdef::google-cloud-platform[--cloud=gcp \]
|
||||
--to=<path_to_directory_with_list_of_credentials_requests>/credrequests \ <1>
|
||||
quay.io/<path_to>/ocp-release:<version>
|
||||
--cloud=<provider_type> \
|
||||
--to=<path_to_directory_with_list_of_credentials_requests>/credrequests \
|
||||
quay.io/<path_to>/ocp-release:<version>
|
||||
----
|
||||
+
|
||||
<1> `credrequests` is the directory where the list of `CredentialsRequest` objects is stored. This command creates the directory if it does not exist.
|
||||
where:
|
||||
+
|
||||
--
|
||||
* `<provider_type>` is the value for your cloud provider. Valid values are `alibabacloud`, `aws`, `gcp`, `ibmcloud`, and `nutanix`.
|
||||
* `credrequests` is the directory where the list of `CredentialsRequest` objects is stored. This command creates the directory if it does not exist.
|
||||
--
|
||||
|
||||
. For each `CredentialsRequest` CR in the release image, ensure that a namespace that matches the text in the `spec.secretRef.namespace` field exists in the cluster. This field is where the generated secrets that hold the credentials configuration are stored.
|
||||
+
|
||||
ifdef::aws-sts[]
|
||||
.Sample AWS `CredentialsRequest` object
|
||||
[source,yaml]
|
||||
----
|
||||
@@ -75,36 +66,9 @@ spec:
|
||||
name: cloud-credential-operator-iam-ro-creds
|
||||
namespace: openshift-cloud-credential-operator <1>
|
||||
----
|
||||
endif::aws-sts[]
|
||||
ifdef::google-cloud-platform[]
|
||||
.Sample GCP `CredentialsRequest` object
|
||||
[source,yaml]
|
||||
----
|
||||
apiVersion: cloudcredential.openshift.io/v1
|
||||
kind: CredentialsRequest
|
||||
metadata:
|
||||
annotations:
|
||||
exclude.release.openshift.io/internal-openshift-hosted: "true"
|
||||
include.release.openshift.io/self-managed-high-availability: "true"
|
||||
name: cloud-credential-operator-gcp-ro-creds
|
||||
namespace: openshift-cloud-credential-operator
|
||||
spec:
|
||||
providerSpec:
|
||||
apiVersion: cloudcredential.openshift.io/v1
|
||||
kind: GCPProviderSpec
|
||||
predefinedRoles:
|
||||
- roles/iam.securityReviewer
|
||||
- roles/iam.roleViewer
|
||||
skipServiceCheck: true
|
||||
secretRef:
|
||||
name: cloud-credential-operator-gcp-ro-creds
|
||||
namespace: openshift-cloud-credential-operator <1>
|
||||
serviceAccountNames:
|
||||
- cloud-credential-operator
|
||||
----
|
||||
endif::google-cloud-platform[]
|
||||
+
|
||||
<1> This field indicates the namespace which needs to exist to hold the generated secret.
|
||||
+
|
||||
The `CredentialsRequest` CRs for other platforms have a similar format with different platform-specific values.
|
||||
|
||||
. For any `CredentialsRequest` CR for which the cluster does not already have a namespace with the name specified in `spec.secretRef.namespace`, create the namespace by running the following command:
|
||||
+
|
||||
@@ -113,63 +77,22 @@ endif::google-cloud-platform[]
|
||||
$ oc create namespace <component_namespace>
|
||||
----
|
||||
|
||||
. Use the `ccoctl` tool to process all `CredentialsRequest` objects in the `credrequests` directory by running the following command:
|
||||
+
|
||||
ifdef::aws-sts[]
|
||||
[source,terminal]
|
||||
----
|
||||
$ ccoctl aws create-iam-roles \
|
||||
--name=<name> \
|
||||
--region=<aws_region> \
|
||||
--credentials-requests-dir=<path_to_directory_with_list_of_credentials_requests>/credrequests \
|
||||
--identity-provider-arn=arn:aws:iam::<aws_account_id>:oidc-provider/<cluster_name>-oidc.s3.<aws_region>.amazonaws.com
|
||||
----
|
||||
+
|
||||
where:
|
||||
. Use the `ccoctl` tool to process all `CredentialsRequest` objects in the `credrequests` directory by running the command for your cloud provider. The following commands process `CredentialsRequest` objects:
|
||||
+
|
||||
--
|
||||
** `<name>` is the name used to tag any cloud resources that are created for tracking. For upgrades, use the same value that was used for the initial installation.
|
||||
** `<aws_account_id>` is the AWS account ID.
|
||||
** `<aws_region>` is the AWS region in which cloud resources will be created.
|
||||
** `<aws_account_id>`, `<cluster_name>`, and `<aws_region>` are standard elements of the Amazon Resource Name (ARN) for your cluster, provided here to illustrate the format of an ARN. You can obtain the ARN for your cluster's identity provider from the *Identity Providers* menu in the link:https://console.aws.amazon.com/iam/[AWS IAM console].
|
||||
* {alibaba}: `ccoctl alibabacloud create-ram-users`
|
||||
* Amazon Web Services (AWS): `ccoctl aws create-iam-roles`
|
||||
* Google Cloud Platform (GCP): `ccoctl gcp create-all`
|
||||
* IBM Cloud: `ccoctl ibmcloud create-service-id`
|
||||
* Nutanix: `ccoctl nutanix create-shared-secrets`
|
||||
--
|
||||
+
|
||||
[NOTE]
|
||||
[IMPORTANT]
|
||||
====
|
||||
For AWS environments that use alternative IAM API endpoints, such as GovCloud, you must also specify your region with the `--region` parameter.
|
||||
|
||||
If your cluster uses Technology Preview features that are enabled by the `TechPreviewNoUpgrade` feature set, you must include the `--enable-tech-preview` parameter.
|
||||
Refer to the `ccoctl` utility instructions in the installation content for your cloud provider for important platform-specific details about the required arguments and special considerations.
|
||||
====
|
||||
endif::aws-sts[]
|
||||
ifdef::google-cloud-platform[]
|
||||
[source,terminal]
|
||||
----
|
||||
$ ccoctl gcp create-service-accounts \
|
||||
--credentials-requests-dir=<path_to_directory_with_list_of_credentials_requests>/credrequests \
|
||||
--name=<name> \
|
||||
--project=<gcp_project_id> \
|
||||
--workload-identity-pool=<name> \
|
||||
--workload-identity-provider=<name>
|
||||
----
|
||||
+
|
||||
where:
|
||||
+
|
||||
--
|
||||
** `<path_to_directory_with_list_of_credentials_requests>/credrequests` is the directory containing the files of `CredentialsRequest` manifests to create GCP service accounts.
|
||||
** `<name>` is the user-defined name for all created GCP resources used for tracking.
|
||||
** `<gcp_project_id>` is the GCP project ID in which cloud resources will be created.
|
||||
--
|
||||
+
|
||||
[NOTE]
|
||||
====
|
||||
If your cluster uses Technology Preview features that are enabled by the `TechPreviewNoUpgrade` feature set, you must include the `--enable-tech-preview` parameter.
|
||||
====
|
||||
endif::google-cloud-platform[]
|
||||
+
|
||||
For each `CredentialsRequest` object, `ccoctl` creates
|
||||
ifdef::aws-sts[an IAM role with a trust policy that is tied to the specified OIDC identity provider,]
|
||||
ifdef::google-cloud-platform[a service account]
|
||||
and a permissions policy as defined in each `CredentialsRequest` object from the {product-title} release image.
|
||||
For each `CredentialsRequest` object, `ccoctl` creates the required provider resources and a permissions policy as defined in each `CredentialsRequest` object from the {product-title} release image.
|
||||
|
||||
. Apply the secrets to your cluster by running the following command:
|
||||
+
|
||||
@@ -180,22 +103,8 @@ $ ls <path_to_ccoctl_output_dir>/manifests/*-credentials.yaml | xargs -I{} oc ap
|
||||
|
||||
.Verification
|
||||
|
||||
You can verify that the
|
||||
ifdef::aws-sts[IAM roles]
|
||||
ifdef::google-cloud-platform[service accounts]
|
||||
are created by querying
|
||||
ifdef::aws-sts[AWS.]
|
||||
ifdef::google-cloud-platform[GCP.]
|
||||
For more information, refer to
|
||||
ifdef::aws-sts[AWS]
|
||||
ifdef::google-cloud-platform[GCP]
|
||||
documentation on listing
|
||||
ifdef::aws-sts[IAM roles.]
|
||||
ifdef::google-cloud-platform[service accounts.]
|
||||
You can verify that the required provider resources and permissions policies are created by querying the cloud provider. For more information, refer to your cloud provider documentation on listing roles or service accounts.
|
||||
|
||||
ifeval::["{context}" == "sts-mode-upgrading"]
|
||||
:!aws-sts:
|
||||
endif::[]
|
||||
ifeval::["{context}" == "wif-mode-upgrading"]
|
||||
:!google-cloud-platform:
|
||||
endif::[]
|
||||
.Next steps
|
||||
|
||||
* Update the `upgradeable-to` annotation to indicate that the cluster is ready to upgrade.
|
||||
|
||||
140
modules/cco-determine-mode-cli.adoc
Normal file
140
modules/cco-determine-mode-cli.adoc
Normal file
@@ -0,0 +1,140 @@
|
||||
// Module included in the following assemblies:
|
||||
//
|
||||
// * updating/preparing-manual-creds-update.adoc
|
||||
// * authentication/managing_cloud_provider_credentials/about-cloud-credential-operator.adoc
|
||||
|
||||
:_content-type: PROCEDURE
|
||||
|
||||
ifeval::["{context}" == "preparing-manual-creds-update"]
|
||||
:update:
|
||||
endif::[]
|
||||
ifeval::["{context}" == "about-cloud-credential-operator"]
|
||||
:about-cco:
|
||||
endif::[]
|
||||
|
||||
[id="cco-determine-mode-cli_{context}"]
|
||||
= Determining the Cloud Credential Operator mode by using the CLI
|
||||
|
||||
You can determine what mode the Cloud Credential Operator (CCO) is configured to use by using the CLI.
|
||||
|
||||
[NOTE]
|
||||
====
|
||||
Only Amazon Web Services (AWS), global Microsoft Azure, and Google Cloud Platform (GCP) clusters support multiple CCO modes.
|
||||
====
|
||||
|
||||
.Prerequisites
|
||||
|
||||
* You have access to an {product-title} account with cluster administrator permissions.
|
||||
* You have installed the OpenShift CLI (`oc`).
|
||||
|
||||
.Procedure
|
||||
|
||||
. Log in to `oc` on the cluster as a user with the `cluster-admin` role.
|
||||
|
||||
. To determine the mode that the CCO is configured to use, enter the following command:
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
$ oc get cloudcredentials cluster \
|
||||
-o=jsonpath={.spec.credentialsMode}
|
||||
----
|
||||
+
|
||||
The following output values are possible, though not all are supported on all platforms:
|
||||
+
|
||||
--
|
||||
* `''`: The CCO is operating in the default mode. In this configuration, the CCO operates in mint or passthrough mode, depending on the credentials provided during installation.
|
||||
* `Mint`: The CCO is operating in mint mode.
|
||||
* `Passthrough`: The CCO is operating in passthrough mode.
|
||||
* `Manual`: The CCO is operating in manual mode.
|
||||
--
|
||||
+
|
||||
[IMPORTANT]
|
||||
====
|
||||
To determine the specific configuration of an AWS or GCP cluster that has a `spec.credentialsMode` of `''`, `Mint`, or `Manual`, you must investigate further.
|
||||
|
||||
AWS and GCP clusters support using mint mode with the root secret deleted.
|
||||
ifdef::update[]
|
||||
If the cluster is specifically configured to use mint mode or uses mint mode by default, you must determine if the root secret is present on the cluster before updating.
|
||||
endif::update[]
|
||||
|
||||
An AWS or GCP cluster that uses manual mode might be configured to create and manage cloud credentials from outside of the cluster using the AWS Security Token Service (STS) or GCP Workload Identity. You can determine whether your cluster uses this strategy by examining the cluster `Authentication` object.
|
||||
====
|
||||
|
||||
ifdef::about-cco[]
|
||||
. AWS or GCP clusters that use the default (`''`) only: To determine whether the cluster is operating in mint or passthrough mode, run the following command:
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
$ oc get secret <secret_name> \
|
||||
-n kube-system \
|
||||
-o jsonpath \
|
||||
--template '{ .metadata.annotations }'
|
||||
----
|
||||
+
|
||||
where `<secret_name>` is `aws-creds` for AWS or `gcp-credentials` for GCP.
|
||||
+
|
||||
This command displays the value of the `.metadata.annotations` parameter in the cluster root secret object. The following output values are possible:
|
||||
+
|
||||
--
|
||||
* `Mint`: The CCO is operating in mint mode.
|
||||
* `Passthrough`: The CCO is operating in passthrough mode.
|
||||
--
|
||||
+
|
||||
If your cluster uses mint mode, you can also determine whether the cluster is operating without the root secret.
|
||||
endif::about-cco[]
|
||||
|
||||
. AWS or GCP clusters that use mint mode only: To determine whether the cluster is operating without the root secret, run the following command:
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
$ oc get secret <secret_name> \
|
||||
-n=kube-system
|
||||
----
|
||||
+
|
||||
where `<secret_name>` is `aws-creds` for AWS or `gcp-credentials` for GCP.
|
||||
+
|
||||
If the root secret is present, the output of this command returns information about the secret. An error indicates that the root secret is not present on the cluster.
|
||||
|
||||
. AWS or GCP clusters that use manual mode only: To determine whether the cluster is configured to create and manage cloud credentials from outside of the cluster, run the following command:
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
$ oc get authentication cluster \
|
||||
-o jsonpath \
|
||||
--template='{ .spec.serviceAccountIssuer }'
|
||||
----
|
||||
+
|
||||
This command displays the value of the `.spec.serviceAccountIssuer` parameter in the cluster `Authentication` object.
|
||||
+
|
||||
--
|
||||
* An output of a URL that is associated with your cloud provider indicates that the CCO is using manual mode with AWS STS or GCP Workload Identity to create and manage cloud credentials from outside of the cluster. These clusters are configured using the `ccoctl` utility.
|
||||
|
||||
* An empty output indicates that the cluster is using the CCO in manual mode but was not configured using the `ccoctl` utility.
|
||||
--
|
||||
|
||||
ifdef::update[]
|
||||
.Next steps
|
||||
|
||||
* If you are updating a cluster that has the CCO operating in mint or passthrough mode and the root secret is present, you do not need to update any cloud provider resources and can continue to the next part of the update process.
|
||||
|
||||
* If your cluster is using the CCO in mint mode with the root secret removed, you must reinstate the credential secret with the administrator-level credential before continuing to the next part of the update process.
|
||||
|
||||
* If your cluster was configured using the CCO utility (`ccoctl`), you must take the following actions:
|
||||
|
||||
.. Configure the `ccoctl` utility for the new release and use it to update the cloud provider resources.
|
||||
|
||||
.. Update the `upgradeable-to` annotation to indicate that the cluster is ready to update.
|
||||
|
||||
* If your cluster is using the CCO in manual mode but was not configured using the `ccoctl` utility, you must take the following actions:
|
||||
|
||||
.. Manually update the cloud provider resources for the new release.
|
||||
|
||||
.. Update the `upgradeable-to` annotation to indicate that the cluster is ready to update.
|
||||
endif::update[]
|
||||
|
||||
ifeval::["{context}" == "preparing-manual-creds-update"]
|
||||
:!update:
|
||||
endif::[]
|
||||
ifeval::["{context}" == "about-cloud-credential-operator"]
|
||||
:!about-cco:
|
||||
endif::[]
|
||||
163
modules/cco-determine-mode-gui.adoc
Normal file
163
modules/cco-determine-mode-gui.adoc
Normal file
@@ -0,0 +1,163 @@
|
||||
// Module included in the following assemblies:
|
||||
//
|
||||
// * updating/preparing-manual-creds-update.adoc
|
||||
// * authentication/managing_cloud_provider_credentials/about-cloud-credential-operator.adoc
|
||||
|
||||
:_content-type: PROCEDURE
|
||||
|
||||
ifeval::["{context}" == "preparing-manual-creds-update"]
|
||||
:update:
|
||||
endif::[]
|
||||
ifeval::["{context}" == "about-cloud-credential-operator"]
|
||||
:about-cco:
|
||||
endif::[]
|
||||
|
||||
[id="cco-determine-mode-gui_{context}"]
|
||||
= Determining the Cloud Credential Operator mode by using the web console
|
||||
|
||||
You can determine what mode the Cloud Credential Operator (CCO) is configured to use by using the web console.
|
||||
|
||||
[NOTE]
|
||||
====
|
||||
Only Amazon Web Services (AWS), global Microsoft Azure, and Google Cloud Platform (GCP) clusters support multiple CCO modes.
|
||||
====
|
||||
|
||||
.Prerequisites
|
||||
|
||||
* You have access to an {product-title} account with cluster administrator permissions.
|
||||
|
||||
.Procedure
|
||||
|
||||
. Log in to the {product-title} web console as a user with the `cluster-admin` role.
|
||||
|
||||
. Navigate to *Administration* -> *Cluster Settings*.
|
||||
|
||||
. On the *Cluster Settings* page, select the *Configuration* tab.
|
||||
|
||||
. Under *Configuration resource*, select *CloudCredential*.
|
||||
|
||||
. On the *CloudCredential details* page, select the *YAML* tab.
|
||||
|
||||
. In the YAML block, check the value of `spec.credentialsMode`. The following values are possible, though not all are supported on all platforms:
|
||||
+
|
||||
--
|
||||
* `''`: The CCO is operating in the default mode. In this configuration, the CCO operates in mint or passthrough mode, depending on the credentials provided during installation.
|
||||
* `Mint`: The CCO is operating in mint mode.
|
||||
* `Passthrough`: The CCO is operating in passthrough mode.
|
||||
* `Manual`: The CCO is operating in manual mode.
|
||||
--
|
||||
+
|
||||
[IMPORTANT]
|
||||
====
|
||||
To determine the specific configuration of an AWS or GCP cluster that has a `spec.credentialsMode` of `''`, `Mint`, or `Manual`, you must investigate further.
|
||||
|
||||
AWS and GCP clusters support using mint mode with the root secret deleted.
|
||||
ifdef::update[]
|
||||
If the cluster is specifically configured to use mint mode or uses mint mode by default, you must determine if the root secret is present on the cluster before updating.
|
||||
endif::update[]
|
||||
|
||||
An AWS or GCP cluster that uses manual mode might be configured to create and manage cloud credentials from outside of the cluster using the AWS Security Token Service (STS) or GCP Workload Identity. You can determine whether your cluster uses this strategy by examining the cluster `Authentication` object.
|
||||
====
|
||||
|
||||
ifdef::about-cco[]
|
||||
. AWS or GCP clusters that use the default (`''`) only: To determine whether the cluster is operating in mint or passthrough mode, inspect the annotations on the cluster root secret:
|
||||
|
||||
.. Navigate to *Workloads* -> *Secrets* and look for the root secret for your cloud provider.
|
||||
+
|
||||
[NOTE]
|
||||
====
|
||||
Ensure that the *Project* dropdown is set to *All Projects*.
|
||||
====
|
||||
+
|
||||
[cols=2,options=header]
|
||||
|===
|
||||
|Platform
|
||||
|Secret name
|
||||
|
||||
|AWS
|
||||
|`aws-creds`
|
||||
|
||||
|GCP
|
||||
|`gcp-credentials`
|
||||
|
||||
|===
|
||||
|
||||
.. To view the CCO mode that the cluster is using, click `1 annotation` under *Annotations*, and check the value field. The following values are possible:
|
||||
+
|
||||
--
|
||||
* `Mint`: The CCO is operating in mint mode.
|
||||
* `Passthrough`: The CCO is operating in passthrough mode.
|
||||
--
|
||||
+
|
||||
If your cluster uses mint mode, you can also determine whether the cluster is operating without the root secret.
|
||||
endif::about-cco[]
|
||||
|
||||
. AWS or GCP clusters that use mint mode only: To determine whether the cluster is operating without the root secret, navigate to *Workloads* -> *Secrets* and look for the root secret for your cloud provider.
|
||||
+
|
||||
[NOTE]
|
||||
====
|
||||
Ensure that the *Project* dropdown is set to *All Projects*.
|
||||
====
|
||||
+
|
||||
[cols=2,options=header]
|
||||
|===
|
||||
|Platform
|
||||
|Secret name
|
||||
|
||||
|AWS
|
||||
|`aws-creds`
|
||||
|
||||
|GCP
|
||||
|`gcp-credentials`
|
||||
|
||||
|===
|
||||
+
|
||||
--
|
||||
* If you see one of these values, your cluster is using mint or passthrough mode with the root secret present.
|
||||
* If you do not see these values, your cluster is using the CCO in mint mode with the root secret removed.
|
||||
--
|
||||
|
||||
. AWS or GCP clusters that use manual mode only: To determine whether the cluster is configured to create and manage cloud credentials from outside of the cluster, you must check the cluster `Authentication` object YAML values.
|
||||
|
||||
.. Navigate to *Administration* -> *Cluster Settings*.
|
||||
|
||||
.. On the *Cluster Settings* page, select the *Configuration* tab.
|
||||
|
||||
.. Under *Configuration resource*, select *Authentication*.
|
||||
|
||||
.. On the *Authentication details* page, select the *YAML* tab.
|
||||
|
||||
.. In the YAML block, check the value of the `.spec.serviceAccountIssuer` parameter.
|
||||
+
|
||||
--
|
||||
* A value that contains a URL that is associated with your cloud provider indicates that the CCO is using manual mode with AWS STS or GCP Workload Identity to create and manage cloud credentials from outside of the cluster. These clusters are configured using the `ccoctl` utility.
|
||||
|
||||
* An empty value (`''`) indicates that the cluster is using the CCO in manual mode but was not configured using the `ccoctl` utility.
|
||||
--
|
||||
|
||||
ifdef::update[]
|
||||
.Next steps
|
||||
|
||||
* If you are updating a cluster that has the CCO operating in mint or passthrough mode and the root secret is present, you do not need to update any cloud provider resources and can continue to the next part of the update process.
|
||||
|
||||
* If your cluster is using the CCO in mint mode with the root secret removed, you must reinstate the credential secret with the administrator-level credential before continuing to the next part of the update process.
|
||||
|
||||
* If your cluster was configured using the CCO utility (`ccoctl`), you must take the following actions:
|
||||
|
||||
.. Configure the `ccoctl` utility for the new release and use it to update the cloud provider resources.
|
||||
|
||||
.. Update the `upgradeable-to` annotation to indicate that the cluster is ready to update.
|
||||
|
||||
* If your cluster is using the CCO in manual mode but was not configured using the `ccoctl` utility, you must take the following actions:
|
||||
|
||||
.. Manually update the cloud provider resources for the new release.
|
||||
|
||||
.. Update the `upgradeable-to` annotation to indicate that the cluster is ready to update.
|
||||
endif::update[]
|
||||
|
||||
ifeval::["{context}" == "preparing-manual-creds-update"]
|
||||
:!update:
|
||||
endif::[]
|
||||
ifeval::["{context}" == "about-cloud-credential-operator"]
|
||||
:!about-cco:
|
||||
endif::[]
|
||||
55
modules/cco-manual-upgrade-annotation.adoc
Normal file
55
modules/cco-manual-upgrade-annotation.adoc
Normal file
@@ -0,0 +1,55 @@
|
||||
// Module included in the following assemblies:
|
||||
//
|
||||
// * authentication/managing_cloud_provider_credentials/cco-mode-manual.adoc
|
||||
// * updating/preparing-manual-creds-update.adoc
|
||||
|
||||
:_content-type: PROCEDURE
|
||||
|
||||
[id="cco-manual-upgrade-annotation_{context}"]
|
||||
= Indicating that the cluster is ready to upgrade
|
||||
|
||||
The Cloud Credential Operator (CCO) `Upgradable` status for a cluster with manually maintained credentials is `False` by default.
|
||||
|
||||
.Prerequisites
|
||||
|
||||
* For the release image that you are upgrading to, you have processed any new credentials manually or by using the Cloud Credential Operator utility (`ccoctl`).
|
||||
* You have installed the OpenShift CLI (`oc`).
|
||||
|
||||
.Procedure
|
||||
|
||||
. Log in to `oc` on the cluster as a user with the `cluster-admin` role.
|
||||
|
||||
. Edit the `CloudCredential` resource to add an `upgradeable-to` annotation within the `metadata` field by running the following command:
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
$ oc edit cloudcredential cluster
|
||||
----
|
||||
+
|
||||
.Text to add
|
||||
+
|
||||
[source,yaml]
|
||||
----
|
||||
...
|
||||
metadata:
|
||||
annotations:
|
||||
cloudcredential.openshift.io/upgradeable-to: <version_number>
|
||||
...
|
||||
----
|
||||
+
|
||||
Where `<version_number>` is the version that you are upgrading to, in the format `x.y.z`. For example, use `4.12.2` for {product-title} 4.12.2.
|
||||
+
|
||||
It may take several minutes after adding the annotation for the upgradeable status to change.
|
||||
|
||||
.Verification
|
||||
|
||||
//Would like to add CLI steps for same
|
||||
. In the *Administrator* perspective of the web console, navigate to *Administration* -> *Cluster Settings*.
|
||||
|
||||
. To view the CCO status details, click *cloud-credential* in the *Cluster Operators* list.
|
||||
+
|
||||
--
|
||||
* If the *Upgradeable* status in the *Conditions* section is *False*, verify that the `upgradeable-to` annotation is free of typographical errors.
|
||||
--
|
||||
|
||||
. When the *Upgradeable* status in the *Conditions* section is *True*, begin the {product-title} upgrade.
|
||||
@@ -1,33 +1,14 @@
|
||||
// Module included in the following assemblies:
|
||||
//
|
||||
// * authentication/managing_cloud_provider_credentials/cco-mode-manual.adoc
|
||||
// * authentication/managing_cloud_provider_credentials/cco-mode-sts.adoc
|
||||
// * installing/installing_ibm_cloud_public/manually-creating-iam-ibm-cloud.adoc
|
||||
// * updating/updating-cluster-within-minor.adoc
|
||||
// * updating/updating-cluster-cli.adoc
|
||||
|
||||
:_content-type: PROCEDURE
|
||||
|
||||
ifeval::["{context}" == "configuring-iam-ibm-cloud"]
|
||||
:ibm-cloud:
|
||||
endif::[]
|
||||
|
||||
[id="manually-maintained-credentials-upgrade_{context}"]
|
||||
= Upgrading clusters with manually maintained credentials
|
||||
= Updating cloud provider resources with manually maintained credentials
|
||||
|
||||
The Cloud Credential Operator (CCO) `Upgradable` status for a cluster with manually maintained credentials is `False` by default.
|
||||
|
||||
* For minor releases, for example, from 4.12 to 4.13, this status prevents you from upgrading until you have addressed any updated permissions and annotated the `CloudCredential` resource to indicate that the permissions are updated as needed for the next version. This annotation changes the `Upgradable` status to `True`.
|
||||
|
||||
* For z-stream releases, for example, from 4.13.0 to 4.13.1, no permissions are added or changed, so the upgrade is not blocked.
|
||||
|
||||
Before upgrading a cluster with manually maintained credentials, you must create any new credentials for the release image that you are upgrading to. Additionally, you must review the required permissions for existing credentials and accommodate any new permissions requirements in the new release for those components.
|
||||
|
||||
ifdef::ibm-cloud[]
|
||||
.Prerequisites
|
||||
|
||||
* You have configured the `ccoctl` binary.
|
||||
endif::ibm-cloud[]
|
||||
Before upgrading a cluster with manually maintained credentials, you must create any new credentials for the release image that you are upgrading to. You must also review the required permissions for existing credentials and accommodate any new permissions requirements in the new release for those components.
|
||||
|
||||
.Procedure
|
||||
|
||||
@@ -35,85 +16,58 @@ endif::ibm-cloud[]
|
||||
+
|
||||
The "Manually creating IAM" section of the installation content for your cloud provider explains how to obtain and use the credentials required for your cloud.
|
||||
|
||||
|
||||
. Update the manually maintained credentials on your cluster:
|
||||
+
|
||||
--
|
||||
** Create new secrets for any `CredentialsRequest` custom resources that are added by the new release image.
|
||||
ifndef::ibm-cloud[]
|
||||
** If the `CredentialsRequest` custom resources for any existing credentials that are stored in secrets have changed their permissions requirements, update the permissions as required.
|
||||
endif::ibm-cloud[]
|
||||
ifdef::ibm-cloud[]
|
||||
** If the `CredentialsRequest` custom resources for any existing credentials that are stored in secrets have changed their permissions requirements, create new service IDs and API keys for the credential requests and secret manifests using the `ccoctl` utility.
|
||||
+
|
||||
The "Manually creating IAM for IBM Cloud" section of the installation content for IBM Cloud explains how to use the `ccoctl` utility to create new service IDs.
|
||||
endif::ibm-cloud[]
|
||||
* Create new secrets for any `CredentialsRequest` custom resources that are added by the new release image.
|
||||
* If the `CredentialsRequest` custom resources for any existing credentials that are stored in secrets have changed permissions requirements, update the permissions as required.
|
||||
--
|
||||
|
||||
. If your cluster uses cluster capabilities to disable one or more optional components, delete the `CredentialsRequest` custom resources for any disabled components.
|
||||
+
|
||||
[NOTE]
|
||||
====
|
||||
If your cluster uses cluster capabilities to disable one or more optional components, delete the `CredentialsRequest` custom resources for any disabled components.
|
||||
====
|
||||
|
||||
. When all of the secrets are correct for the new release, indicate that the cluster is ready to upgrade:
|
||||
|
||||
.. Log in to the {product-title} CLI as a user with the `cluster-admin` role.
|
||||
|
||||
.. Edit the `CloudCredential` resource to add an `upgradeable-to` annotation within the `metadata` field:
|
||||
.Example `credrequests` directory contents for {product-title} 4.12 on AWS
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
$ oc edit cloudcredential cluster
|
||||
0000_30_machine-api-operator_00_credentials-request.yaml <1>
|
||||
0000_50_cloud-credential-operator_05-iam-ro-credentialsrequest.yaml <2>
|
||||
0000_50_cluster-image-registry-operator_01-registry-credentials-request.yaml <3>
|
||||
0000_50_cluster-ingress-operator_00-ingress-credentials-request.yaml <4>
|
||||
0000_50_cluster-network-operator_02-cncc-credentials.yaml <5>
|
||||
0000_50_cluster-storage-operator_03_credentials_request_aws.yaml <6>
|
||||
----
|
||||
+
|
||||
.Text to add
|
||||
--
|
||||
<1> The Machine API Operator CR is required.
|
||||
<2> The Cloud Credential Operator CR is required.
|
||||
<3> The Image Registry Operator CR is required.
|
||||
<4> The Ingress Operator CR is required.
|
||||
<5> The Network Operator CR is required.
|
||||
<6> The Storage Operator CR is an optional component and might be disabled in your cluster.
|
||||
--
|
||||
+
|
||||
[source,yaml]
|
||||
----
|
||||
...
|
||||
metadata:
|
||||
annotations:
|
||||
cloudcredential.openshift.io/upgradeable-to: <version_number>
|
||||
...
|
||||
----
|
||||
.Example `credrequests` directory contents for {product-title} 4.12 on GCP
|
||||
+
|
||||
Where `<version_number>` is the version you are upgrading to, in the format `x.y.z`. For example, `4.8.2` for {product-title} 4.8.2.
|
||||
+
|
||||
It may take several minutes after adding the annotation for the upgradeable status to change.
|
||||
|
||||
.Verification
|
||||
|
||||
. In the *Administrator* perspective of the web console, navigate to *Administration* -> *Cluster Settings*.
|
||||
|
||||
. To view the CCO status details, click *cloud-credential* in the *Cluster Operators* list.
|
||||
|
||||
.. If the *Upgradeable* status in the *Conditions* section is *False*, verify that the `upgradeable-to` annotation is free of typographical errors.
|
||||
ifndef::ibm-cloud[]
|
||||
When the *Upgradeable* status in the *Conditions* section is *True*, you can begin the {product-title} upgrade.
|
||||
endif::ibm-cloud[]
|
||||
ifdef::ibm-cloud[]
|
||||
+
|
||||
When the *Upgradeable* status in the *Conditions* section is *True*, you can begin the {product-title} upgrade.
|
||||
|
||||
. Revoke the old service IDs and API Keys:
|
||||
[source,terminal]
|
||||
+
|
||||
----
|
||||
$ ccoctl ibmcloud delete-service-id \
|
||||
--credentials-requests-dir <path_to_credential_requests_directory> \ <1>
|
||||
--name <name> <2>
|
||||
0000_26_cloud-controller-manager-operator_16_credentialsrequest-gcp.yaml <1>
|
||||
0000_30_machine-api-operator_00_credentials-request.yaml <2>
|
||||
0000_50_cloud-credential-operator_05-gcp-ro-credentialsrequest.yaml <3>
|
||||
0000_50_cluster-image-registry-operator_01-registry-credentials-request-gcs.yaml <4>
|
||||
0000_50_cluster-ingress-operator_00-ingress-credentials-request.yaml <5>
|
||||
0000_50_cluster-network-operator_02-cncc-credentials.yaml <6>
|
||||
0000_50_cluster-storage-operator_03_credentials_request_gcp.yaml <7>
|
||||
----
|
||||
<1> The directory where the credential requests are stored.
|
||||
<2> The name of the {product-title} cluster.
|
||||
+
|
||||
--
|
||||
[NOTE]
|
||||
====
|
||||
If your cluster uses Technology Preview features that are enabled by the `TechPreviewNoUpgrade` feature set, you must include the `--enable-tech-preview` parameter.
|
||||
====
|
||||
<1> The Cloud Controller Manager Operator CR is required.
|
||||
<2> The Machine API Operator CR is required.
|
||||
<3> The Cloud Credential Operator CR is required.
|
||||
<4> The Image Registry Operator CR is required.
|
||||
<5> The Ingress Operator CR is required.
|
||||
<6> The Network Operator CR is required.
|
||||
<7> The Storage Operator CR is an optional component and might be disabled in your cluster.
|
||||
--
|
||||
endif::ibm-cloud[]
|
||||
|
||||
ifeval::["{context}" == "configuring-iam-ibm-cloud"]
|
||||
:!ibm-cloud:
|
||||
endif::[]
|
||||
.Next steps
|
||||
* Update the `upgradeable-to` annotation to indicate that the cluster is ready to upgrade.
|
||||
|
||||
66
updating/preparing-manual-creds-update.adoc
Normal file
66
updating/preparing-manual-creds-update.adoc
Normal file
@@ -0,0 +1,66 @@
|
||||
:_content-type: ASSEMBLY
|
||||
[id="preparing-manual-creds-update"]
|
||||
= Preparing to update a cluster with manually maintained credentials
|
||||
include::_attributes/common-attributes.adoc[]
|
||||
:context: preparing-manual-creds-update
|
||||
|
||||
toc::[]
|
||||
|
||||
The Cloud Credential Operator (CCO) `Upgradable` status for a cluster with manually maintained credentials is `False` by default.
|
||||
|
||||
* For minor releases, for example, from 4.12 to 4.13, this status prevents you from updating until you have addressed any updated permissions and annotated the `CloudCredential` resource to indicate that the permissions are updated as needed for the next version. This annotation changes the `Upgradable` status to `True`.
|
||||
|
||||
* For z-stream releases, for example, from 4.13.0 to 4.13.1, no permissions are added or changed, so the update is not blocked.
|
||||
|
||||
Before updating a cluster with manually maintained credentials, you must accommodate any new or changed credentials in the release image for the version of {product-title} you are updating to.
|
||||
|
||||
//Upgrading clusters with manually maintained credentials
|
||||
include::modules/about-manually-maintained-credentials-upgrade.adoc[leveloffset=+1]
|
||||
[role="_additional-resources"]
|
||||
.Additional resources
|
||||
* xref:../updating/preparing-manual-creds-update.adoc#cco-determine-mode-gui_preparing-manual-creds-update[Determining the Cloud Credential Operator mode by using the web console]
|
||||
* xref:../updating/preparing-manual-creds-update.adoc#cco-determine-mode-cli_preparing-manual-creds-update[Determining the Cloud Credential Operator mode by using the CLI]
|
||||
* xref:../updating/preparing-manual-creds-update.adoc#cco-ccoctl-configuring_preparing-manual-creds-update[Configuring the Cloud Credential Operator utility for a cluster update]
|
||||
* xref:../updating/preparing-manual-creds-update.adoc#manually-maintained-credentials-upgrade_preparing-manual-creds-update[Updating cloud provider resources with manually maintained credentials]
|
||||
* xref:../authentication/managing_cloud_provider_credentials/about-cloud-credential-operator.adoc#about-cloud-credential-operator[About the Cloud Credential Operator]
|
||||
|
||||
//Determining the Cloud Credential Operator mode by using the web console
|
||||
include::modules/cco-determine-mode-gui.adoc[leveloffset=+2]
|
||||
[role="_additional-resources"]
|
||||
.Additional resources
|
||||
* xref:../updating/preparing-manual-creds-update.adoc#cco-ccoctl-configuring_preparing-manual-creds-update[Configuring the Cloud Credential Operator utility for a cluster update]
|
||||
* xref:../updating/preparing-manual-creds-update.adoc#manually-maintained-credentials-upgrade_preparing-manual-creds-update[Updating cloud provider resources with manually maintained credentials]
|
||||
|
||||
//Determining the Cloud Credential Operator mode by using the CLI
|
||||
include::modules/cco-determine-mode-cli.adoc[leveloffset=+2]
|
||||
[role="_additional-resources"]
|
||||
.Additional resources
|
||||
* xref:../updating/preparing-manual-creds-update.adoc#cco-ccoctl-configuring_preparing-manual-creds-update[Configuring the Cloud Credential Operator utility for a cluster update]
|
||||
* xref:../updating/preparing-manual-creds-update.adoc#manually-maintained-credentials-upgrade_preparing-manual-creds-update[Updating cloud provider resources with manually maintained credentials]
|
||||
|
||||
//Configuring the Cloud Credential Operator utility for a cluster update
|
||||
include::modules/cco-ccoctl-configuring.adoc[leveloffset=+1]
|
||||
|
||||
//Updating cloud provider resources with the Cloud Credential Operator utility
|
||||
include::modules/cco-ccoctl-upgrading.adoc[leveloffset=+1]
|
||||
[role="_additional-resources"]
|
||||
.Additional resources
|
||||
* xref:../installing/installing_alibaba/installing-alibaba-default.adoc#cco-ccoctl-creating-at-once_installing-alibaba-default[Creating {alibaba} credentials for {product-title} components with the `ccoctl` tool]
|
||||
* xref:../authentication/managing_cloud_provider_credentials/cco-mode-sts.adoc#sts-mode-create-aws-resources-ccoctl_cco-mode-sts[Creating AWS resources with the Cloud Credential Operator utility]
|
||||
* xref:../authentication/managing_cloud_provider_credentials/cco-mode-gcp-workload-identity.adoc#cco-ccoctl-creating-at-once_cco-mode-gcp-workload-identity[Creating GCP resources with the Cloud Credential Operator utility]
|
||||
* xref:../installing/installing_ibm_cloud_public/installing-ibm-cloud-customizations.adoc#manually-create-iam-ibm-cloud_installing-ibm-cloud-customizations[Manually creating IAM for IBM Cloud VPC]
|
||||
* xref:../installing/installing_nutanix/installing-nutanix-installer-provisioned.adoc#manually-create-iam-nutanix_installing-nutanix-installer-provisioned[Configuring IAM for Nutanix]
|
||||
* xref:../updating/preparing-manual-creds-update.adoc#cco-manual-upgrade-annotation_preparing-manual-creds-update[Indicating that the cluster is ready to upgrade]
|
||||
|
||||
//Updating cloud provider resources with manually maintained credentials
|
||||
include::modules/manually-maintained-credentials-upgrade.adoc[leveloffset=+1]
|
||||
[role="_additional-resources"]
|
||||
.Additional resources
|
||||
* xref:../installing/installing_aws/manually-creating-iam.adoc#manually-create-iam_manually-creating-iam-aws[Manually creating IAM for AWS]
|
||||
* xref:../installing/installing_azure/manually-creating-iam-azure.adoc#manually-create-iam_manually-creating-iam-azure[Manually creating IAM for Azure]
|
||||
* xref:../installing/installing_azure_stack_hub/installing-azure-stack-hub-default.adoc#manually-create-iam_installing-azure-stack-hub-default[Manually creating IAM for Azure Stack Hub]
|
||||
* xref:../installing/installing_gcp/manually-creating-iam-gcp.adoc#manually-create-iam_manually-creating-iam-gcp[Manually creating IAM for GCP]
|
||||
* xref:../updating/preparing-manual-creds-update.adoc#cco-manual-upgrade-annotation_preparing-manual-creds-update[Indicating that the cluster is ready to upgrade]
|
||||
|
||||
//Indicating that the cluster is ready to upgrade
|
||||
include::modules/cco-manual-upgrade-annotation.adoc[leveloffset=+1]
|
||||
@@ -21,8 +21,7 @@ See xref:../authentication/using-rbac.adoc[Using RBAC to define and apply permis
|
||||
* Support for {op-system-base}7 workers is removed in {product-title} {product-version}. You must replace {op-system-base}7 workers with {op-system-base}8 or {op-system} workers before upgrading to {product-title} {product-version}. Red Hat does not support in-place {op-system-base}7 to {op-system-base}8 updates for {op-system-base} workers; those hosts must be replaced with a clean operating system install.
|
||||
* Ensure all Operators previously installed through Operator Lifecycle Manager (OLM) are updated to their latest version in their latest channel. Updating the Operators ensures they have a valid update path when the default OperatorHub catalogs switch from the current minor version to the next during a cluster update. See xref:../operators/admin/olm-upgrading-operators.adoc#olm-upgrading-operators[Updating installed Operators] for more information.
|
||||
* Ensure that all machine config pools (MCPs) are running and not paused. Nodes associated with a paused MCP are skipped during the update process. You can pause the MCPs if you are performing a canary rollout update strategy.
|
||||
* If your cluster uses manually maintained credentials, ensure that the Cloud Credential Operator (CCO) is in an upgradeable state. For more information, see xref:../updating/updating-cluster-cli.adoc#manually-maintained-credentials-upgrade_updating-cluster-cli[Upgrading clusters with manually maintained credentials].
|
||||
* If your cluster uses manually maintained credentials with the AWS Security Token Service (STS), obtain a copy of the `ccoctl` utility from the release image being updated to and use it to process any updated credentials. For more information, see xref:../authentication/managing_cloud_provider_credentials/cco-mode-sts.adoc#sts-mode-upgrading[Upgrading an OpenShift Container Platform cluster configured for manual mode with STS].
|
||||
* If your cluster uses manually maintained credentials, update the cloud provider resources for the new release. For more information, including how to determine if this is a requirement for your cluster, see xref:../updating/preparing-manual-creds-update.adoc#preparing-manual-creds-update[Preparing to update a cluster with manually maintained credentials].
|
||||
* Ensure that you address all `Upgradeable=False` conditions so the cluster allows an update to the next minor version. An alert displays at the top of the *Cluster Settings* page when you have one or more cluster Operators that cannot be upgraded. You can still update to the next available patch update for the minor release you are currently on.
|
||||
* Review the list of APIs that were removed in Kubernetes 1.26, migrate any affected components to use the new API version, and provide the administrator acknowledgment. For more information, see xref:../updating/updating-cluster-prepare.adoc#updating-cluster-prepare[Preparing to update to {product-title} 4.13].
|
||||
* If you run an Operator or you have configured any application with the pod disruption budget, you might experience an interruption during the upgrade process. If `minAvailable` is set to 1 in `PodDisruptionBudget`, the nodes are drained to apply pending machine configs which might block the eviction process. If several nodes are rebooted, all the pods might run on only one node, and the `PodDisruptionBudget` field can prevent the node drain.
|
||||
@@ -35,16 +34,8 @@ See xref:../authentication/using-rbac.adoc[Using RBAC to define and apply permis
|
||||
|
||||
[role="_additional-resources"]
|
||||
.Additional resources
|
||||
|
||||
* xref:../architecture/architecture-installation.adoc#unmanaged-operators_architecture-installation[Support policy for unmanaged Operators]
|
||||
|
||||
include::modules/manually-maintained-credentials-upgrade.adoc[leveloffset=+1]
|
||||
|
||||
.Additional resources
|
||||
* xref:../installing/installing_aws/manually-creating-iam.adoc[Manually creating IAM for AWS]
|
||||
* xref:../installing/installing_azure/manually-creating-iam-azure.adoc[Manually creating IAM for Azure]
|
||||
* xref:../installing/installing_gcp/manually-creating-iam-gcp.adoc[Manually creating IAM for GCP]
|
||||
|
||||
include::modules/machine-health-checks-pausing.adoc[leveloffset=+1]
|
||||
|
||||
include::modules/updating-sno.adoc[leveloffset=+1]
|
||||
|
||||
@@ -16,8 +16,7 @@ those machines.
|
||||
See xref:../authentication/using-rbac.adoc[Using RBAC to define and apply permissions].
|
||||
* Have a recent xref:../backup_and_restore/control_plane_backup_and_restore/backing-up-etcd.adoc#backup-etcd[etcd backup] in case your update fails and you must xref:../backup_and_restore/control_plane_backup_and_restore/disaster_recovery/scenario-2-restoring-cluster-state.adoc#dr-restoring-cluster-state[restore your cluster to a previous state].
|
||||
* Support for {op-system-base}7 workers is removed in {product-title} {product-version}. You must replace {op-system-base}7 workers with {op-system-base}8 or {op-system} workers before upgrading to {product-title} {product-version}. Red Hat does not support in-place {op-system-base}7 to {op-system-base}8 updates for {op-system-base} workers; those hosts must be replaced with a clean operating system install.
|
||||
* If your cluster uses manually maintained credentials, ensure that the Cloud Credential Operator (CCO) is in an upgradeable state. For more information, see _Upgrading clusters with manually maintained credentials_ for xref:../installing/installing_aws/manually-creating-iam.adoc#manually-maintained-credentials-upgrade_manually-creating-iam-aws[AWS], xref:../installing/installing_azure/manually-creating-iam-azure.adoc#manually-maintained-credentials-upgrade_manually-creating-iam-azure[Azure], or xref:../installing/installing_gcp/manually-creating-iam-gcp.adoc#manually-maintained-credentials-upgrade_manually-creating-iam-gcp[GCP].
|
||||
* If your cluster uses manually maintained credentials with the AWS Security Token Service (STS), obtain a copy of the `ccoctl` utility from the release image being updated to and use it to process any updated credentials. For more information, see xref:../authentication/managing_cloud_provider_credentials/cco-mode-sts.adoc#sts-mode-upgrading[_Upgrading an OpenShift Container Platform cluster configured for manual mode with STS_].
|
||||
* If your cluster uses manually maintained credentials, update the cloud provider resources for the new release. For more information, including how to determine if this is a requirement for your cluster, see xref:../updating/preparing-manual-creds-update.adoc#preparing-manual-creds-update[Preparing to update a cluster with manually maintained credentials].
|
||||
* If you run an Operator or you have configured any application with the pod disruption budget, you might experience an interruption during the upgrade process. If `minAvailable` is set to 1 in `PodDisruptionBudget`, the nodes are drained to apply pending machine configs which might block the eviction process. If several nodes are rebooted, all the pods might run on only one node, and the `PodDisruptionBudget` field can prevent the node drain.
|
||||
|
||||
[role="_additional-resources"]
|
||||
|
||||
@@ -23,8 +23,7 @@ See xref:../authentication/using-rbac.adoc[Using RBAC to define and apply permis
|
||||
* Ensure that all machine config pools (MCPs) are running and not paused. Nodes associated with a paused MCP are skipped during the update process. You can pause the MCPs if you are performing a canary rollout update strategy.
|
||||
//remove this???^ or maybe just add another bullet that you can break up the update?
|
||||
* To accommodate the time it takes to update, you are able to do a partial update by updating the worker or custom pool nodes. You can pause and resume within the progress bar of each pool.
|
||||
* If your cluster uses manually maintained credentials, ensure that the Cloud Credential Operator (CCO) is in an upgradeable state. For more information, see xref:../updating/updating-cluster-cli.adoc#manually-maintained-credentials-upgrade_updating-cluster-cli[Upgrading clusters with manually maintained credentials].
|
||||
* If your cluster uses manually maintained credentials with the AWS Security Token Service (STS), obtain a copy of the `ccoctl` utility from the release image being updated to and use it to process any updated credentials. For more information, see xref:../authentication/managing_cloud_provider_credentials/cco-mode-sts.adoc#sts-mode-upgrading[Upgrading an OpenShift Container Platform cluster configured for manual mode with STS].
|
||||
* If your cluster uses manually maintained credentials, update the cloud provider resources for the new release. For more information, including how to determine if this is a requirement for your cluster, see xref:../updating/preparing-manual-creds-update.adoc#preparing-manual-creds-update[Preparing to update a cluster with manually maintained credentials].
|
||||
* Review the list of APIs that were removed in Kubernetes 1.26, migrate any affected components to use the new API version, and provide the administrator acknowledgment. For more information, see xref:../updating/updating-cluster-prepare.adoc#updating-cluster-prepare[Preparing to update to {product-title} 4.13].
|
||||
* If you run an Operator or you have configured any application with the pod disruption budget, you might experience an interruption during the upgrade process. If `minAvailable` is set to 1 in `PodDisruptionBudget`, the nodes are drained to apply pending machine configs which might block the eviction process. If several nodes are rebooted, all the pods might run on only one node, and the `PodDisruptionBudget` field can prevent the node drain.
|
||||
|
||||
@@ -43,13 +42,6 @@ include::modules/update-using-custom-machine-config-pools-canary.adoc[leveloffse
|
||||
|
||||
If you want to use the canary rollout update process, see xref:../updating/update-using-custom-machine-config-pools.adoc#update-using-custom-machine-config-pools[Performing a canary rollout update].
|
||||
|
||||
include::modules/manually-maintained-credentials-upgrade.adoc[leveloffset=+1]
|
||||
|
||||
.Additional resources
|
||||
* xref:../installing/installing_aws/manually-creating-iam.adoc[Manually creating IAM for AWS]
|
||||
* xref:../installing/installing_azure/manually-creating-iam-azure.adoc[Manually creating IAM for Azure]
|
||||
* xref:../installing/installing_gcp/manually-creating-iam-gcp.adoc[Manually creating IAM for GCP]
|
||||
|
||||
include::modules/machine-health-checks-pausing-web-console.adoc[leveloffset=+1]
|
||||
|
||||
include::modules/updating-sno.adoc[leveloffset=+1]
|
||||
|
||||
@@ -16,9 +16,8 @@ Use the following procedures to update a cluster in a disconnected environment w
|
||||
See xref:../../authentication/using-rbac.adoc#using-rbac[Using RBAC to define and apply permissions].
|
||||
* You must have a recent xref:../../backup_and_restore/control_plane_backup_and_restore/backing-up-etcd.adoc#backup-etcd[etcd backup] in case your update fails and you must xref:../../backup_and_restore/control_plane_backup_and_restore/disaster_recovery/scenario-2-restoring-cluster-state.adoc#dr-restoring-cluster-state[restore your cluster to a previous state].
|
||||
* You must ensure that all machine config pools (MCPs) are running and not paused. Nodes associated with a paused MCP are skipped during the update process. You can pause the MCPs if you are performing a canary rollout update strategy.
|
||||
* If your cluster uses manually maintained credentials, you must ensure that the Cloud Credential Operator (CCO) is in an upgradeable state. For more information, see _Upgrading clusters with manually maintained credentials_ for xref:../../installing/installing_aws/manually-creating-iam.adoc#manually-maintained-credentials-upgrade_manually-creating-iam-aws[AWS], xref:../../installing/installing_azure/manually-creating-iam-azure.adoc#manually-maintained-credentials-upgrade_manually-creating-iam-azure[Azure], or xref:../../installing/installing_gcp/manually-creating-iam-gcp.adoc#manually-maintained-credentials-upgrade_manually-creating-iam-gcp[GCP].
|
||||
//STS is not currently supported in a disconnected environment, but the following bullet can be uncommented when that changes.
|
||||
//* If your cluster uses manually maintained credentials with the AWS Security Token Service (STS), obtain a copy of the `ccoctl` utility from the release image being upgraded to and use it to process any updated credentials. For more information, see xref:../../authentication/managing_cloud_provider_credentials/cco-mode-sts.adoc#sts-mode-upgrading[_Upgrading an OpenShift Container Platform cluster configured for manual mode with STS_].
|
||||
* If your cluster uses manually maintained credentials, update the cloud provider resources for the new release. For more information, including how to determine if this is a requirement for your cluster, see xref:../../updating/preparing-manual-creds-update.adoc#preparing-manual-creds-update[Preparing to update a cluster with manually maintained credentials].
|
||||
* If you run an Operator or you have configured any application with the pod disruption budget, you might experience an interruption during the upgrade process. If `minAvailable` is set to 1 in `PodDisruptionBudget`, the nodes are drained to apply pending machine configs which might block the eviction process. If several nodes are rebooted, all the pods might run on only one node, and the `PodDisruptionBudget` field can prevent the node drain.
|
||||
|
||||
[NOTE]
|
||||
====
|
||||
|
||||
Reference in New Issue
Block a user