openshift-docs/modules/manually-rotating-cloud-creds.adoc

// Module included in the following assemblies:
//
// * post_installation_configuration/cluster-tasks.adoc
// * authentication/managing_cloud_provider_credentials/cco-mode-mint.adoc
// * authentication/managing_cloud_provider_credentials/cco-mode-passthrough.adoc

ifeval::["{context}" == "changing-cloud-credentials-configuration"]
:post-install:
endif::[]
ifeval::["{context}" == "cco-mode-mint"]
:mint:
endif::[]
ifeval::["{context}" == "cco-mode-passthrough"]
:passthrough:
endif::[]

:_mod-docs-content-type: PROCEDURE
[id="manually-rotating-cloud-creds_{context}"]
ifdef::post-install[= Rotating cloud provider credentials manually]
ifndef::post-install[= 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.

////
[NOTE]
====
You can also use the command-line interface to complete all parts of this procedure.
====
////

.Prerequisites

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

ifndef::passthrough[]
** For mint mode, Amazon Web Services (AWS) and {gcp-first} are supported.
endif::passthrough[]

ifndef::mint[]
** For passthrough mode, Amazon Web Services (AWS), Microsoft Azure, {gcp-first}, {rh-openstack-first}, and VMware vSphere are supported.
endif::mint[]

* 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

. In the *Administrator* perspective of the web console, navigate to *Workloads* -> *Secrets*.

. In the table on the *Secrets* page, find the root secret for your cloud provider.
+
[cols=2,options=header]
|===
|Platform
|Secret name

|AWS
|`aws-creds`

ifndef::mint[]
|Azure
|`azure-credentials`
endif::mint[]

|{gcp-short}
|`gcp-credentials`

ifndef::mint[]
|{rh-openstack}
|`openstack-credentials`

|VMware vSphere
|`vsphere-creds`
endif::mint[]

|===

. Click the Options menu {kebab} in the same row as the secret and select *Edit Secret*.

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

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

ifndef::mint[]
. 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.
+
[NOTE]
====
If the vSphere CSI Driver Operator is enabled, this step is not required.
====
+
To apply the updated vSphere credentials, log in to the {product-title} CLI as a user with the `cluster-admin` role and run the following command:
+
[source,terminal]
----
$ 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:
+
[source,terminal]
----
$ oc get co kube-controller-manager
----
endif::mint[]

ifdef::post-install[]
. If the CCO for your cluster is configured to use mint mode, delete each component secret that is referenced by the individual `CredentialsRequest` objects.
endif::post-install[]
ifdef::mint[]
. Delete each component secret that is referenced by the individual `CredentialsRequest` objects.
endif::mint[]

ifndef::passthrough[]
.. Log in to the {product-title} CLI as a user with the `cluster-admin` role.

.. Get the names and namespaces of all referenced component secrets:
+
[source,terminal]
----
$ 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-short}: `GCPProviderSpec`
--
+
.Partial example output for AWS
+
[source,json]
----
{
  "name": "ebs-cloud-credentials",
  "namespace": "openshift-cluster-csi-drivers"
}
{
  "name": "cloud-credential-operator-iam-ro-creds",
  "namespace": "openshift-cloud-credential-operator"
}
----

.. Delete each of the referenced component secrets:
+
[source,terminal]
----
$ 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
+
[source,terminal]
----
$ 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.
endif::passthrough[]

.Verification

To verify that the credentials have changed:

. In the *Administrator* perspective of the web console, navigate to *Workloads* -> *Secrets*.

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

////
// Provider-side verification also possible, though cluster-side is cleaner process.
. To verify that the credentials have changed from the console of your cloud provider:

.. Get the `CredentialsRequest` CR names for your platform:
+
[source,terminal]
----
$ oc -n openshift-cloud-credential-operator get CredentialsRequest -o json | jq -r '.items[] | select (.spec[].kind=="<provider_spec>") | .metadata.name'
----
+
Where `<provider_spec>` is the corresponding value for your cloud provider: `AWSProviderSpec` for AWS, `AzureProviderSpec` for Azure, or `GCPProviderSpec` for {gcp-short}.
+
.Example output for AWS
+
[source,terminal]
----
aws-ebs-csi-driver-operator
cloud-credential-operator-iam-ro
openshift-image-registry
openshift-ingress
openshift-machine-api-aws
----

.. Get the IAM username that corresponds to each `CredentialsRequest` CR name:
+
[source,terminal]
----
$ oc get credentialsrequest <cr_name> -n openshift-cloud-credential-operator -o json | jq -r ".status.providerStatus"
----
+
Where `<cr_name>` is the name of a `CredentialsRequest` CR.
+
.Example output for AWS
+
[source,json]
----
{
  "apiVersion": "cloudcredential.openshift.io/v1",
  "kind": "AWSProviderStatus",
  "policy": "<example-iam-username-policy>",
  "user": "<example-iam-username>"
}
----
+
Where `<example-iam-username>` is the name of an IAM user on the cloud provider.

.. For each IAM username, view the details for the user on the cloud provider. The credentials should show that they were created after being rotated on the cluster.
////

ifeval::["{context}" == "changing-cloud-credentials-configuration"]
:!post-install:
endif::[]
ifeval::["{context}" == "cco-mode-mint"]
:!mint:
endif::[]
ifeval::["{context}" == "cco-mode-passthrough"]
:!passthrough:
endif::[]