Manually create IAM

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.

  1. Create the install-config.yaml file:

    $ openshift-install create install-config --dir=<installation_directory>
  2. Edit the install-config.yaml configuration file so that it contains the credentialsMode parameter set to Manual.

    Example install-config.yaml configuration file
    apiVersion: v1
    credentialsMode: Manual (1)
    - architecture: amd64
      hyperthreading: Enabled
    1 This line is added to set the credentialsMode parameter to Manual.
  3. Run the OKD installer to generate manifests:

    $ openshift-install create manifests --dir=<installation_directory> (1)
    1 For <installation_directory>, specify the directory name to store the files that the installation program creates.
  4. Remove the admin credential secret created using your local cloud credentials. This removal prevents your admin credential from being stored in the cluster:

    $ rm mycluster/openshift/99_cloud-creds-secret.yaml
  5. Obtain the OKD release image your openshift-install binary is built to use:

    $ openshift-install version
    Example output
    release image
  6. Locate all CredentialsRequest objects in this release image that target the cloud you are deploying on:

    $ oc adm release extract --credentials-requests --cloud=aws

    This displays the details for each request.

    Sample CredentialsRequest object
    kind: CredentialsRequest
      name: cloud-credential-operator-iam-ro
      namespace: openshift-cloud-credential-operator
        name: cloud-credential-operator-iam-ro-creds
        namespace: openshift-cloud-credential-operator
        kind: AWSProviderSpec
        - effect: Allow
          - iam:GetUser
          - iam:GetUserPolicy
          - iam:ListAccessKeys
          resource: "*"
  7. 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. The format for the secret data varies for each cloud provider.

  8. Proceed with 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.

Admin credentials root secret format

Each cloud provider uses a credentials root secret in the kube-system 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 passthrough mode.

The format for the secret varies by cloud, and is also used for each CredentialsRequest secret.

Amazon Web Services (AWS) secret format
apiVersion: v1
kind: Secret
  namespace: kube-system
  name: aws-creds
  aws_access_key_id: <AccessKeyID>
  aws_secret_access_key: <SecretAccessKey>

Upgrading clusters with manually maintained credentials

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.

  1. Navigate to AdministrationCluster Settings.

  2. To view the CCO status details, click cloud-credential in the Cluster Operators list.

  3. If the Upgradeable status in the Conditions section is False, examine the credentialsRequests 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

Mint Mode is supported for AWS, GCP, and Azure.

The default and recommended best practice for running OKD is to run the installer with an administrator-level cloud credential. The admin credential is stored in the kube-system namespace, and then used by the Cloud Credential Operator to process the CredentialsRequest objects in the cluster and create new users for each with specific permissions.

The benefits of Mint Mode include:

  • Each cluster component only has the permissions it requires.

  • Automatic, on-going reconciliation for cloud credentials including upgrades, which might require additional credentials or permissions.

One drawback is that Mint Mode requires admin credential storage in a cluster kube-system secret.

Mint Mode with removal or rotation of the admin credential

Currently, this mode is only supported on AWS.

In this mode, a user installs OKD with an admin credential just like the normal mint mode. However, this mode removes the admin credential secret from the cluster post-installation.

The administrator can have the Cloud Credential Operator make its own request for a read-only credential that allows it to verify if all CredentialsRequest objects have their required permissions, thus the admin credential is not required unless something needs to be changed. After the associated credential is removed, it can be destroyed on the underlying cloud, if desired.

Prior to upgrade, the admin credential should be restored. In the future, upgrade might be blocked if the credential is not present.

The admin credential is not stored in the cluster permanently.

This mode still requires the admin credential in the cluster for brief periods of time. It also requires manually re-instating the secret with admin credentials for each upgrade.