This is a cache of https://docs.okd.io/4.12/authentication/managing_cloud_provider_credentials/cco-mode-manual.html. It is a snapshot of the page at 2024-11-21T18:27:51.291+0000.
Using manual mode - Managing cloud provider credentials | Authentication and authorization | OKD 4.12
  1. Documentation
×

Using manual mode

Manual mode is supported for Alibaba Cloud, Amazon Web Services (AWS), Microsoft Azure, IBM Cloud, and Google Cloud Platform (GCP).

In manual mode, a user manages cloud credentials instead of the Cloud Credential Operator (CCO). To use this mode, you must examine the CredentialsRequest CRs in the release image for the version of OKD that you are running or installing, create corresponding credentials in the underlying cloud provider, and create Kubernetes Secrets in the correct namespaces to satisfy all CredentialsRequest CRs for the cluster’s cloud provider.

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 the manual credentials management options for your cloud provider:

Manual mode with cloud credentials created and managed outside of the cluster

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 Using manual mode with Amazon Web Services Security Token Service or Using manual mode with GCP Workload Identity.

Updating cloud provider resources with manually maintained credentials

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

  1. Extract and examine the CredentialsRequest custom resource for the new release.

    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.

  2. Update the manually maintained credentials on your cluster:

    • 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.

  3. If your cluster uses cluster capabilities to disable one or more optional components, delete the CredentialsRequest custom resources for any disabled components.

    Example credrequests directory contents for OKD 4.12 on AWS
    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)
    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.
    Example credrequests directory contents for OKD 4.12 on GCP
    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 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.
Next steps

  • Update the upgradeable-to annotation to indicate that the cluster is ready to upgrade.

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

  1. Log in to oc on the cluster as a user with the cluster-admin role.

  2. Edit the CloudCredential resource to add an upgradeable-to annotation within the metadata field by running the following command:

    $ oc edit cloudcredential cluster
    Text to add
    ...
  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 OKD 4.12.2.

    It may take several minutes after adding the annotation for the upgradeable status to change.

Verification

  1. In the Administrator perspective of the web console, navigate to Administration → Cluster Settings.

  2. 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.

  3. When the upgradeable status in the Conditions section is True, begin the OKD upgrade.

Additional resources