Using mint mode

• Mint mode permissions requirements
  • Amazon Web Services (AWS) permissions
  • Microsoft Azure permissions
  • Google Cloud Platform (GCP) permissions
• Mint mode with removal or rotation of the administrator-level credential
  • Rotating cloud provider credentials manually
  • Removing cloud provider credentials
• Additional resources

Mint mode is supported for Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP).

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 CredentialsRequest 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, Azure, or GCP.

Mint mode permissions requirements

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.

Amazon Web Services (AWS) permissions

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

• iam:TagUser

• iam:SimulatePrincipalPolicy

Microsoft Azure permissions

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

Google Cloud Platform (GCP) permissions

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

• resourcemanager.projects.setIamPolicy

Mint mode with removal or rotation of the administrator-level credential

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.

Rotating cloud provider credentials manually

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 Workloads → Secrets.

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

   Platform	Secret name
   AWS	aws-creds
   Azure	azure-credentials
   GCP	gcp-credentials

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

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

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

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

      $ oc -n openshift-cloud-credential-operator get CredentialsRequest -o json | jq -r '.items[] | select (.spec[].kind=="<provider_spec>") | .spec.secretRef'

      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

      {
        "name": "ebs-cloud-credentials",
        "namespace": "openshift-cluster-csi-drivers"
      }
      {
        "name": "cloud-credential-operator-iam-ro-creds",
        "namespace": "openshift-cloud-credential-operator"
      }
      ...

   3. Delete each of the referenced component secrets:

      $ oc delete secret <secret_name> -n <secret_namespace>

      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

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

7. To verify that the credentials have changed:

   1. In the Administrator perspective of the web console, navigate to Workloads → Secrets.

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

Removing cloud provider credentials

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 Workloads → Secrets.

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

   Platform	Secret name
   AWS	aws-creds
   GCP	gcp-credentials

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

Additional resources

• Alternatives to storing administrator-level secrets in the kube-system project for AWS

• Alternatives to storing administrator-level secrets in the kube-system project for Azure

• Alternatives to storing administrator-level secrets in the kube-system project for GCP

• Creating a service principal in Azure