This is a cache of https://docs.okd.io/latest/post_installation_configuration/changing-cloud-credentials-configuration.html. It is a snapshot of the page at 2024-11-26T18:12:41.963+0000.
Changing the cloud provider credentials configuration | Postinstallation configuration | OKD 4
  1. Documentation
×

Changing the cloud provider credentials configuration

Rotating or removing cloud provider credentials

After installing OKD, some organizations require the rotation or removal of the cloud provider credentials that were used during the initial installation.

To allow the cluster to use the new credentials, you must update the secrets that the Cloud Credential Operator (CCO) uses to manage cloud provider credentials.

Rotating cloud provider credentials with the Cloud Credential Operator utility

The Cloud Credential Operator (CCO) utility ccoctl supports updating secrets for clusters installed on IBM Cloud®.

Rotating API keys

You can rotate API keys for your existing service IDs and update the corresponding secrets.

Prerequisites

  • You have configured the ccoctl binary.

  • You have existing service IDs in a live OKD cluster installed.

Procedure

  • Use the ccoctl utility to rotate your API keys for the service IDs and update the secrets:

    $ ccoctl <provider_name> refresh-keys \ (1)
    --kubeconfig <openshift_kubeconfig_file> \ (2)
    --credentials-requests-dir <path_to_credential_requests_directory> \ (3)
    --name <name> (4)
    1 The name of the provider. For example: ibmcloud or powervs.
    2 The kubeconfig file associated with the cluster. For example, <installation_directory>/auth/kubeconfig.
    3 The directory where the credential requests are stored.
    4 The name of the OKD cluster.

    If your cluster uses Technology Preview features that are enabled by the TechPreviewNoupgrade feature set, you must include the --enable-tech-preview parameter.

Maintaining cloud provider credentials

If your cloud provider credentials are changed for any reason, you must manually update the secret that the Cloud Credential Operator (CCO) uses to manage cloud provider credentials.

The process for rotating cloud credentials depends on the mode that the CCO is configured to use. After you rotate credentials for a cluster that is using mint mode, you must manually remove the component credentials that were created by the removed credential.

Prerequisites

  • Your cluster is installed on a platform that supports rotating cloud credentials manually with the CCO mode that you are using:

    • For mint mode, Amazon Web Services (AWS) and Google Cloud Platform (GCP) are supported.

    • For passthrough mode, Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform (GCP), OpenStack, and VMware vSphere are supported.

  • You have changed the credentials that are used to interface with your cloud provider.

  • The new credentials have sufficient permissions for the mode CCO is configured to use in your cluster.

Procedure

  1. In the Administrator perspective of the web console, navigate to Workloads → Secrets.

  2. In the table on the Secrets page, find the root secret for your cloud provider.

    Platform Secret name

    AWS

    aws-creds

    Azure

    azure-credentials

    GCP

    gcp-credentials

    OpenStack

    openstack-credentials

    VMware vSphere

    vsphere-creds

  3. Click the Options menu kebab in the same row as the secret and select Edit Secret.

  4. Record the contents of the Value field or fields. You can use this information to verify that the value is different after updating the credentials.

  5. Update the text in the Value field or fields with the new authentication information for your cloud provider, and then click Save.

  6. If you are updating the credentials for a vSphere cluster that does not have the vSphere CSI Driver Operator enabled, you must force a rollout of the Kubernetes controller manager to apply the updated credentials.

    If the vSphere CSI Driver Operator is enabled, this step is not required.

    To apply the updated vSphere credentials, log in to the OKD CLI as a user with the cluster-admin role and run the following command:

    $ oc patch kubecontrollermanager cluster \
  -p='{"spec": {"forceRedeploymentReason": "recovery-'"$( date )"'"}}' \
  --type=merge

    While the credentials are rolling out, the status of the Kubernetes Controller Manager Operator reports Progressing=true. To view the status, run the following command:

    $ oc get co kube-controller-manager

    1. Log in to the OKD CLI as a user with the cluster-admin role.

    2. Get the names and namespaces of all referenced component secrets:

      $ oc -n openshift-cloud-credential-operator get CredentialsRequest \
  -o json | jq -r '.items[] | select (.spec.providerSpec.kind=="<provider_spec>") | .spec.secretRef'

      where <provider_spec> is the corresponding value for your cloud provider:

      • AWS: AWSProviderSpec

      • GCP: GCPProviderSpec

      Partial example output for AWS
      {
  "name": "ebs-cloud-credentials",
  "namespace": "openshift-cluster-csi-drivers"
}
{
  "name": "cloud-credential-operator-iam-ro-creds",
  "namespace": "openshift-cloud-credential-operator"
}

    3. Delete each of the referenced component secrets:

      $ oc delete secret <secret_name> \(1)
  -n <secret_namespace> (2)
      1 Specify the name of a secret.
      2 Specify the namespace that contains the secret.
      Example deletion of an AWS secret
      $ oc delete secret ebs-cloud-credentials -n openshift-cluster-csi-drivers

      You do not need to manually delete the credentials from your provider console. Deleting the referenced component secrets will cause the CCO to delete the existing credentials from the platform and create new ones.

Verification

To verify that the credentials have changed:

  1. In the Administrator perspective of the web console, navigate to Workloads → Secrets.

  2. Verify that the contents of the Value field or fields have changed.

Additional resources

Removing cloud provider credentials

After installing an OKD cluster with the Cloud Credential Operator (CCO) in mint mode, you can remove the administrator-level credential secret from the kube-system namespace in the cluster. The administrator-level credential is required only during changes that require its elevated permissions, such as upgrades.

Prior to a non z-stream upgrade, you must reinstate the credential secret with the administrator-level credential. If the credential is not present, the upgrade might be blocked.
Prerequisites

  • Your cluster is installed on a platform that supports removing cloud credentials from the CCO. Supported platforms are AWS and GCP.

Procedure

  1. In the Administrator perspective of the web console, navigate to Workloads → Secrets.

  2. In the table on the Secrets page, find the root secret for your cloud provider.

    Platform Secret name

    AWS

    aws-creds

    GCP

    gcp-credentials

  3. Click the Options menu kebab in the same row as the secret and select Delete Secret.

Additional resources

Enabling token-based authentication

After installing an Microsoft Azure OKD cluster, you can enable Microsoft Entra Workload ID to use short-term credentials.

Configuring the Cloud Credential Operator utility

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.

The ccoctl utility is a Linux binary that must run in a Linux environment.
Prerequisites

  • You have access to an OKD account with cluster administrator access.

  • You have installed the OpenShift CLI (oc).

Procedure

  1. Set a variable for the OKD release image by running the following command:

    $ RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')

  2. Obtain the CCO container image from the OKD release image by running the following command:

    $ CCO_IMAGE=$(oc adm release info --image-for='cloud-credential-operator' $RELEASE_IMAGE -a ~/.pull-secret)

    Ensure that the architecture of the $RELEASE_IMAGE matches the architecture of the environment in which you will use the ccoctl tool.

  3. Extract the ccoctl binary from the CCO container image within the OKD release image by running the following command:

    $ oc image extract $CCO_IMAGE \
  --file="/usr/bin/ccoctl.<rhel_version>" \(1)
  -a ~/.pull-secret
    1 For <rhel_version>, specify the value that corresponds to the version of Fedora that the host uses. If no value is specified, ccoctl.rhel8 is used by default. The following values are valid:

    • rhel8: Specify this value for hosts that use Fedora 8.

    • rhel9: Specify this value for hosts that use Fedora 9.

  4. Change the permissions to make ccoctl executable by running the following command:

    $ chmod 775 ccoctl.<rhel_version>
Verification

  • To verify that ccoctl is ready to use, display the help file. Use a relative file name when you run the command, for example:

    $ ./ccoctl.rhel9
    Example output
    OpenShift credentials provisioning tool

Usage:
  ccoctl [command]

Available Commands:
  aws          Manage credentials objects for AWS cloud
  azure        Manage credentials objects for Azure
  gcp          Manage credentials objects for Google cloud
  help         Help about any command
  ibmcloud     Manage credentials objects for {ibm-cloud-title}
  nutanix      Manage credentials objects for Nutanix

Flags:
  -h, --help   help for ccoctl

Use "ccoctl [command] --help" for more information about a command.

Enabling Microsoft Entra Workload ID on an existing cluster

If you did not configure your Microsoft Azure OKD cluster to use Microsoft Entra Workload ID during installation, you can enable this authentication method on an existing cluster.

The process to enable Workload ID on an existing cluster is disruptive and takes a significant amount of time. Before proceeding, observe the following considerations:

  • Read the following steps and ensure that you understand and accept the time requirement. The exact time requirement varies depending on the individual cluster, but it is likely to require at least one hour.

  • During this process, you must refresh all service accounts and restart all pods on the cluster. These actions are disruptive to workloads. To mitigate this impact, you can temporarily halt these services and then redeploy them when the cluster is ready.

  • After starting this process, do not attempt to update the cluster until it is complete. If an update is triggered, the process to enable Workload ID on an existing cluster fails.
Prerequisites

  • You have installed an OKD cluster on Microsoft Azure.

  • You have access to the cluster using an account with cluster-admin permissions.

  • You have installed the OpenShift CLI (oc).

  • You have extracted and prepared the Cloud Credential Operator utility (ccoctl) binary.

  • You have access to your Azure account by using the Azure CLI (az).

Procedure

  1. Create an output directory for the manifests that the ccoctl utility generates. This procedure uses ./output_dir as an example.

  2. Extract the service account public signing key for the cluster to the output directory by running the following command:

    $ oc get configmap \
  --namespace openshift-kube-apiserver bound-sa-token-signing-certs \
  --output 'go-template={{index .data "service-account-001.pub"}}' > ./output_dir/serviceaccount-signer.public (1)
    1 This procedure uses a file named serviceaccount-signer.public as an example.

  3. Use the extracted service account public signing key to create an OpenID Connect (OIDC) issuer and Azure blob storage container with OIDC configuration files by running the following command:

    $ ./ccoctl azure create-oidc-issuer \
  --name <azure_infra_name> \(1)
  --output-dir ./output_dir \
  --region <azure_region> \(2)
  --subscription-id <azure_subscription_id> \(3)
  --tenant-id <azure_tenant_id> \
  --public-key-file ./output_dir/serviceaccount-signer.public (4)
    1 The value of the name parameter is used to create an Azure resource group. To use an existing Azure resource group instead of creating a new one, specify the --oidc-resource-group-name argument with the existing group name as its value.
    2 Specify the region of the existing cluster.
    3 Specify the subscription ID of the existing cluster.
    4 Specify the file that contains the service account public signing key for the cluster.

  4. Verify that the configuration file for the Azure pod identity webhook was created by running the following command:

    $ ll ./output_dir/manifests
    Example output
    total 8
-rw-------. 1 cloud-user cloud-user 193 May 22 02:29 azure-ad-pod-identity-webhook-config.yaml (1)
-rw-------. 1 cloud-user cloud-user 165 May 22 02:29 cluster-authentication-02-config.yaml
    1 The file azure-ad-pod-identity-webhook-config.yaml contains the Azure pod identity webhook configuration.

  5. Set an OIDC_ISSUER_URL variable with the OIDC issuer URL from the generated manifests in the output directory by running the following command:

    $ OIDC_ISSUER_URL=`awk '/serviceAccountIssuer/ { print $2 }' ./output_dir/manifests/cluster-authentication-02-config.yaml`

  6. Update the spec.serviceAccountIssuer parameter of the cluster authentication configuration by running the following command:

    $ oc patch authentication cluster \
  --type=merge \
  -p "{\"spec\":{\"serviceAccountIssuer\":\"${OIDC_ISSUER_URL}\"}}"

  7. Monitor the configuration update progress by running the following command:

    $ oc adm wait-for-stable-cluster

    This process might take 15 minutes or longer. The following output indicates that the process is complete:

    All clusteroperators are stable

  8. Restart all of the pods in the cluster by running the following command:

    $ oc adm reboot-machine-config-pool mcp/worker mcp/master

    Restarting a pod updates the serviceAccountIssuer field and refreshes the service account public signing key.

  9. Monitor the restart and update process by running the following command:

    $ oc adm wait-for-node-reboot nodes --all

    This process might take 15 minutes or longer. The following output indicates that the process is complete:

    All nodes rebooted

  10. Update the Cloud Credential Operator spec.credentialsMode parameter to Manual by running the following command:

    $ oc patch cloudcredential cluster \
  --type=merge \
  --patch '{"spec":{"credentialsMode":"Manual"}}'

  11. Extract the list of CredentialsRequest objects from the OKD release image by running the following command:

    $ oc adm release extract \
  --credentials-requests \
  --included \
  --to <path_to_directory_for_credentials_requests> \
  --registry-config ~/.pull-secret

    This command might take a few moments to run.

  12. Set an AZURE_INSTALL_RG variable with the Azure resource group name by running the following command:

    $ AZURE_INSTALL_RG=`oc get infrastructure cluster -o jsonpath --template '{ .status.platformStatus.azure.resourceGroupName }'`

  13. Use the ccoctl utility to create managed identities for all CredentialsRequest objects by running the following command:

    $ ccoctl azure create-managed-identities \
  --name <azure_infra_name> \
  --output-dir ./output_dir \
  --region <azure_region> \
  --subscription-id <azure_subscription_id> \
  --credentials-requests-dir <path_to_directory_for_credentials_requests> \
  --issuer-url "${OIDC_ISSUER_URL}" \
  --dnszone-resource-group-name <azure_dns_zone_resourcegroup_name> \(1)
  --installation-resource-group-name "${AZURE_INSTALL_RG}"
    1 Specify the name of the resource group that contains the DNS zone.

  14. Apply the Azure pod identity webhook configuration for Workload ID by running the following command:

    $ oc apply -f ./output_dir/manifests/azure-ad-pod-identity-webhook-config.yaml

  15. Apply the secrets generated by the ccoctl utility by running the following command:

    $ find ./output_dir/manifests -iname "openshift*yaml" -print0 | xargs -I {} -0 -t oc replace -f {}

    This process might take several minutes.

  16. Restart all of the pods in the cluster by running the following command:

    $ oc adm reboot-machine-config-pool mcp/worker mcp/master

    Restarting a pod updates the serviceAccountIssuer field and refreshes the service account public signing key.

  17. Monitor the restart and update process by running the following command:

    $ oc adm wait-for-node-reboot nodes --all

    This process might take 15 minutes or longer. The following output indicates that the process is complete:

    All nodes rebooted

  18. Monitor the configuration update progress by running the following command:

    $ oc adm wait-for-stable-cluster

    This process might take 15 minutes or longer. The following output indicates that the process is complete:

    All clusteroperators are stable

  19. Optional: Remove the Azure root credentials secret by running the following command:

    $ oc delete secret -n kube-system azure-credentials
Additional resources

Verifying that a cluster uses short-term credentials

You can verify that a cluster uses short-term security credentials for individual components by checking the Cloud Credential Operator (CCO) configuration and other values in the cluster.

Prerequisites

  • You deployed an OKD cluster using the Cloud Credential Operator utility (ccoctl) to implement short-term credentials.

  • You installed the OpenShift CLI (oc).

  • You are logged in as a user with cluster-admin privileges.

Procedure

  • Verify that the CCO is configured to operate in manual mode by running the following command:

    $ oc get cloudcredentials cluster \
  -o=jsonpath={.spec.credentialsMode}

    The following output confirms that the CCO is operating in manual mode:

    Example output
    Manual

  • Verify that the cluster does not have root credentials by running the following command:

    $ oc get secrets \
  -n kube-system <secret_name>

    where <secret_name> is the name of the root secret for your cloud provider.

    Platform Secret name

    Amazon Web Services (AWS)

    aws-creds

    Microsoft Azure

    azure-credentials

    Google Cloud Platform (GCP)

    gcp-credentials

    An error confirms that the root secret is not present on the cluster.

    Example output for an AWS cluster
    Error from server (NotFound): secrets "aws-creds" not found

  • Verify that the components are using short-term security credentials for individual components by running the following command:

    $ 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 cluster is using manual mode with short-term credentials that are created and managed from outside of the cluster.

  • Azure clusters: Verify that the components are assuming the Azure client ID that is specified in the secret manifests by running the following command:

    $ oc get secrets \
  -n openshift-image-registry installer-cloud-credentials \
  -o jsonpath='{.data}'

    An output that contains the azure_client_id and azure_federated_token_file felids confirms that the components are assuming the Azure client ID.

  • Azure clusters: Verify that the pod identity webhook is running by running the following command:

    $ oc get pods \
  -n openshift-cloud-credential-operator
    Example output
    NAME                                         READY   STATUS    RESTARTS   AGE
cloud-credential-operator-59cf744f78-r8pbq   2/2     Running   2          71m
pod-identity-webhook-548f977b4c-859lz        1/1     Running   1          70m

Additional resources