Using mint mode

    Mint mode is the default and recommended best practice setting for the Cloud Credential Operator (CCO) to use on the platforms for which it is supported. In this mode, the CCO uses the provided administrator-level cloud credential to create new credentials for components in the cluster with only the specific permissions that are required.

    If the credential is not removed after installation, it is stored and used by the CCO to process CRs for components in the cluster and create new credentials for each with only the specific permissions that are required. The continuous reconciliation of cloud credentials in mint mode allows actions that require additional credentials or permissions, such as upgrading, to proceed.

    If the requirement that mint mode stores the administrator-level credential in the cluster kube-system namespace does not suit the security requirements of your organization, see Alternatives to storing administrator-level secrets in the kube-system project for AWS, , or GCP.

    When using the CCO in mint mode, ensure that the credential you provide meets the requirements of the cloud on which you are running or installing OKD. If the provided credentials are not sufficient for mint mode, the CCO cannot create an IAM user.

    The credential you provide for mint mode in AWS must have the following permissions:

    • iam:CreateAccessKey

    • iam:CreateUser

    • iam:DeleteAccessKey

    • iam:DeleteUser

    • iam:DeleteUserPolicy

    • iam:GetUser

    • iam:GetUserPolicy

    • iam:ListAccessKeys

    • iam:PutUserPolicy

    The credential you provide for mint mode in Azure must have a service principal with the permissions specified in .

    The credential you provide for mint mode in GCP must have the following permissions:

    • resourcemanager.projects.get

    • serviceusage.services.list

    • iam.serviceAccountKeys.create

    • iam.serviceAccountKeys.delete

    • iam.serviceAccounts.create

    • iam.serviceAccounts.delete

    • iam.serviceAccounts.get

    • iam.roles.get

    • resourcemanager.projects.setIamPolicy

    Currently, this mode is only supported on AWS and GCP.

    In this mode, a user installs OKD with an administrator-level credential just like the normal mint mode. However, this process removes the administrator-level 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 administrator-level credential is not required unless something needs to be changed. After the associated credential is removed, it can be deleted or deactivated on the underlying cloud, if desired.

    The administrator-level credential is not stored in the cluster permanently.

    Following these steps still requires the administrator-level credential in the cluster for brief periods of time. It also requires manually re-instating the secret with administrator-level credentials for each upgrade.

    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, AWS, Azure, and GCP are supported.

      • For passthrough mode, AWS, Azure, GCP, Red Hat OpenStack Platform (RHOSP), oVirt, 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 WorkloadsSecrets.

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

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

    4. If the CCO for your cluster is configured to use mint mode, delete each component secret that is referenced by the individual CredentialsRequest objects.

      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:

        Where <provider_spec> is the corresponding value for your cloud provider: AWSProviderSpec for AWS, AzureProviderSpec for Azure, or GCPProviderSpec for GCP.

        Partial example output for AWS

      3. Delete each of the referenced component secrets:

        Where <secret_name> is the name of a secret and <secret_namespace> is the namespace that contains the secret.

        Example deletion of an AWS secret

        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.

    5. To verify that the credentials have changed:

      1. In the Administrator perspective of the web console, navigate to WorkloadsSecrets.

      2. Verify that the contents of the Value field or fields are different than the previously recorded information.

    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.

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

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

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