$ 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 install-config.yaml
file.
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 OKD 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 kube-system
namespace.
Change to the directory that contains the installation program and create the install-config.yaml
file:
$ openshift-install create install-config --dir <installation_directory>
where <installation_directory>
is the directory in which the installation program creates files.
Edit the install-config.yaml
configuration file so that it contains the credentialsMode
parameter set to Manual
.
install-config.yaml
configuration fileapiVersion: v1
baseDomain: cluster1.example.com
credentialsMode: Manual (1)
compute:
- architecture: amd64
hyperthreading: Enabled
...
1 | This line is added to set the credentialsMode parameter to Manual . |
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 OKD 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
Locate all 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 CredentialsRequest
object.
CredentialsRequest
objectapiVersion: 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. |
If credentials are added in a future release, the Cloud Credential Operator (CCO) upgradable
status for a cluster with manually maintained credentials changes to false
. For minor release, for example, from 4.6 to 4.7, this status prevents you from upgrading until you have addressed any updated permissions. For z-stream releases, for example, from 4.6.10 to 4.6.11, the upgrade is not blocked, but the credentials must still be updated for the new release.
Use the Administrator perspective of the web console to determine if the CCO is upgradeable.
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, examine the CredentialsRequest
custom resource for the new release and update the manually maintained credentials on your cluster to match before upgrading.
In addition to creating new credentials for the release image that you are
upgrading to, you must review the required permissions for existing credentials
and accommodate any new permissions requirements for existing components in the
new release. The CCO cannot detect these mismatches and will not set
upgradable
to false
in this case.
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.
Mint mode is the default and recommended Cloud Credential Operator (CCO) credentials mode for OKD. 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 kube-system
secret.
Install an OKD cluster:
Installing a cluster quickly on Azure with default options on installer-provisioned infrastructure
Install a cluster with cloud customizations on installer-provisioned infrastructure
Install a cluster with network customizations on installer-provisioned infrastructure