$ openshift-install create install-config --dir=<installation_directory>
In environments where the cloud identity and access management (IAM) APIs are not reachable, or the administrator prefers not to store an administrator-level credential secret in the cluster
kube-system namespace, you can put the Cloud Credential Operator (CCO) into manual mode before you install the cluster.
The Cloud Credential Operator (CCO) manages cloud provider credentials as Kubernetes custom resource definitions (CRDs). You can configure the CCO to suit the security requirements of your organization by setting different values for the
credentialsMode parameter in the
If you prefer not to store an administrator-level credential secret in the cluster
kube-system project, you can set the
credentialsMode parameter for the CCO to
Manual when installing OpenShift Container Platform and manage your cloud credentials manually.
Using manual mode allows each cluster component to have only the permissions it requires, without storing an administrator-level credential in the cluster. You can also use this mode if your environment does not have connectivity to the cloud provider public IAM endpoint. However, you must manually reconcile permissions with new release images for every upgrade. You must also manually supply credentials for every component that requests them.
For a detailed description of all available CCO credential modes and their supported platforms, see About the Cloud Credential Operator.
The Cloud Credential Operator (CCO) can be put into manual mode prior to
installation in environments where the cloud identity and access management
(IAM) APIs are not reachable, or the administrator prefers not to store an
administrator-level credential secret in the cluster
Change to the directory that contains the installation program and create the
$ openshift-install create install-config --dir=<installation_directory>
<installation_directory> is the directory in which the installation program creates files.
install-config.yaml configuration file so that it contains the
credentialsMode parameter set to
apiVersion: v1 baseDomain: cluster1.example.com credentialsMode: Manual (1) compute: - architecture: amd64 hyperthreading: Enabled ...
|1||This line is added to set the
To generate the manifests, run the following command from the directory that contains the installation program:
$ openshift-install create manifests --dir=<installation_directory>
From the directory that contains the installation program, obtain details of the OpenShift Container Platform release image that your
openshift-install binary is built to use:
$ openshift-install version
release image quay.io/openshift-release-dev/ocp-release:4.y.z-x86_64
CredentialsRequest objects in this release image that target the cloud you are deploying on:
$ oc adm release extract quay.io/openshift-release-dev/ocp-release:4.y.z-x86_64 --credentials-requests --cloud=azure
This command creates a YAML file for each
apiVersion: cloudcredential.openshift.io/v1 kind: CredentialsRequest metadata: labels: controller-tools.k8s.io: "1.0" name: openshift-image-registry-azure namespace: openshift-cloud-credential-operator spec: secretRef: name: installer-cloud-credentials namespace: openshift-image-registry providerSpec: apiVersion: cloudcredential.openshift.io/v1 kind: AzureProviderSpec roleBindings: - role: Contributor
Create YAML files for secrets in the
openshift-install manifests directory that you generated previously. The secrets must be stored using the namespace and secret name defined in the
spec.secretRef for each
CredentialsRequest object. The format for the secret data varies for each cloud provider.
From the directory that contains the installation program, proceed with your cluster creation:
$ openshift-install create cluster --dir=<installation_directory>
Before upgrading a cluster that uses manually maintained credentials, you must ensure that the CCO is in an upgradeable state. For details, see the "Upgrading clusters with manually maintained credentials" section of the installation content for your cloud provider.
Each cloud provider uses a credentials root secret in the
namespace by convention, which is then used to satisfy all credentials requests
and create their respective secrets. This is done either by minting new
credentials, with mint mode, or by copying the credentials root secret, with
The format for the secret varies by cloud, and is also used for each
apiVersion: v1 kind: Secret metadata: namespace: kube-system name: azure-credentials stringData: azure_subscription_id: <SubscriptionID> azure_client_id: <ClientID> azure_client_secret: <ClientSecret> azure_tenant_id: <TenantID> azure_resource_prefix: <ResourcePrefix> azure_resourcegroup: <ResourceGroup> azure_region: <Region>
On Microsoft Azure, the credentials secret format includes two properties that must contain the cluster’s infrastructure ID, generated randomly for each cluster installation. This value can be found after running create manifests:
$ cat .openshift_install_state.json | jq '."*installconfig.ClusterID".InfraID' -r
This value would be used in the secret data as follows:
azure_resource_prefix: mycluster-2mpcn azure_resourcegroup: mycluster-2mpcn-rg
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.8 to 4.9, 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
For z-stream releases, for example, from 4.9.0 to 4.9.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.
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.
Update the manually maintained credentials on your cluster:
Create new secrets for any
CredentialsRequest custom resources that are added by the new release image.
CredentialsRequest custom resources for any existing credentials that are stored in secrets have changed their permissions requirements, update the permissions as required.
When all of the secrets are correct for the new release, indicate that the cluster is ready to upgrade:
Log in to the OpenShift Container Platform CLI as a user with the
CloudCredential resource to add an
upgradeable-to annotation within the
$ oc edit cloudcredential cluster
... metadata: annotations: cloudcredential.openshift.io/upgradeable-to: <version_number> ...
<version_number> is the version you are upgrading to, in the format
x.y.z. For example,
4.8.2 for OpenShift Container Platform 4.8.2.
It may take several minutes after adding the annotation for the upgradeable status to change.
Verify that the CCO is upgradeable:
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, you can begin the OpenShift Container Platform upgrade.
Mint mode is the default and recommended Cloud Credential Operator (CCO) credentials mode for OpenShift Container Platform. In this mode, the CCO uses the provided administrator-level cloud credential to run the cluster. Mint mode is supported for AWS, GCP, and Azure.
In mint mode, the
admin credential is stored in the
kube-system namespace and then used by the CCO to process the
CredentialsRequest objects in the cluster and create users for each with specific permissions.
The benefits of mint mode include:
Each cluster component has only the permissions it requires
Automatic, on-going reconciliation for cloud credentials, including additional credentials or permissions that might be required for upgrades
One drawback is that mint mode requires
admin credential storage in a cluster
Install an OpenShift Container Platform cluster:
Installing a cluster quickly on Azure with default options on installer-provisioned infrastructure