The Cloud Credential Operator in mint mode
Mint mode is the default Cloud Credential Operator (CCO) credentials mode for OKD on platforms that support it. Mint mode supports Amazon Web Services (AWS) and Google Cloud Platform (GCP) clusters.
Mint mode credentials management
For clusters that use the CCO in mint mode, the administrator-level credential is stored in the kube-system
namespace. The CCO uses the admin
credential to process the CredentialsRequest
objects in the cluster and create users for components with limited permissions.
With mint mode, each cluster component has only the specific permissions it requires. The automatic, continuous reconciliation of cloud credentials in mint mode allows actions that require additional credentials or permissions, such as upgrading, to proceed.
By default, mint mode requires storing the |
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.
The credential you provide for mint mode in Amazon Web Services (AWS) must have the following permissions:
Required AWS permissions
iam:CreateAccessKey
iam:CreateUser
iam:DeleteAccessKey
iam:DeleteUser
iam:DeleteUserPolicy
iam:GetUser
iam:GetUserPolicy
iam:ListAccessKeys
iam:PutUserPolicy
iam:TagUser
iam:SimulatePrincipalPolicy
The credential you provide for mint mode in Google Cloud Platform (GCP) must have the following permissions:
Required GCP 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
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
metadata:
namespace: kube-system
name: aws-creds
stringData:
aws_access_key_id: <base64-encoded_access_key_id>
aws_secret_access_key: <base64-encoded_secret_access_key>
Google Cloud Platform (GCP) secret format
apiVersion: v1
kind: Secret
metadata:
namespace: kube-system
name: gcp-credentials
stringData:
service_account.json: <base64-encoded_service_account>
Maintaining cloud provider credentials
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, Amazon Web Services (AWS) and Google Cloud Platform (GCP) 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
In the Administrator perspective of the web console, navigate to Workloads → Secrets.
In the table on the Secrets page, find the root secret for your cloud provider.
Platform Secret name AWS
aws-creds
GCP
gcp-credentials
Click the Options menu in the same row as the secret and select Edit Secret.
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.
Update the text in the Value field or fields with the new authentication information for your cloud provider, and then click Save.
Delete each component secret that is referenced by the individual
CredentialsRequest
objects.Log in to the OKD CLI as a user with the
cluster-admin
role.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.providerSpec.kind=="<provider_spec>") | .spec.secretRef'
where
<provider_spec>
is the corresponding value for your cloud provider:AWS:
AWSProviderSpec
GCP:
GCPProviderSpec
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"
}
Delete each of the referenced component secrets:
$ oc delete secret <secret_name> \(1)
-n <secret_namespace> (2)
1 Specify the name of a secret. 2 Specify 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.
Verification
To verify that the credentials have changed:
In the Administrator perspective of the web console, navigate to Workloads → Secrets.
Verify that the contents of the Value field or fields have changed.