In multi-tenant scenarios, ACK issues kubeconfig files embedded with user identity information for cluster access. Revoke distributed kubeconfig credentials when employees leave or credentials may be exposed to protect cluster security. This topic describes how an Alibaba Cloud account or a RAM user revokes issued kubeconfig credentials.
Deleting a RAM user or RAM role does not automatically revoke RBAC permissions in the kubeconfig file. Always revoke the kubeconfig before deleting the RAM user.
Prerequisites
Ensure the following:
-
An ACK cluster created after the following dates:
-
ACK managed cluster or ACK dedicated cluster: October 15, 2019
-
ACK Serverless cluster: September 6, 2019
-
-
An Alibaba Cloud account or RAM user with access to the ACK console
Who can revoke what
| Actor | What can be revoked |
|---|---|
| Alibaba Cloud account | kubeconfig files of all RAM users and RAM roles under the account |
| RAM user | The RAM user's own kubeconfig file |
After revocation, ACK automatically assigns a new kubeconfig file to the cluster.
Revoke kubeconfig files as an Alibaba Cloud account
Revoke kubeconfig files of RAM users or RAM roles under your account, for example, when an employee leaves.
An Alibaba Cloud account can only revoke kubeconfig files of RAM users or RAM roles it manages.
-
Log on to the ACK console. In the left-side navigation pane, click Authorizations.
-
On the RAM Users tab, find the target RAM user and click KubeConfig Management.
-
In the Actions column, click Delete KubeConfig File and confirm.
Revoke your own kubeconfig file as a RAM user
Revoke your own kubeconfig file when it is no longer needed or has been exposed.
Once revoked, the kubeconfig file cannot be used to access the cluster.
-
Log on to the ACK console. In the left-side navigation pane, click Clusters.
-
On the Clusters page, click the target cluster name. In the left-side navigation pane, click Cluster Information.
-
On the Connection Information tab, click Revoke KubeConfig and click OK.
Revoke kubeconfig for a permanently deleted RAM user
If a RAM user was deleted before their kubeconfig was revoked, the associated RBAC bindings remain. Choose the cleanup method based on whether the RAM user is in the recycle bin.
Before revoking, ensure no cluster application relies on the permissions in that kubeconfig file.
If the RAM user is in the recycle bin
-
Restore the RAM user from the recycle bin. You do not need to restore the AccessKey pair.
-
As the Alibaba Cloud account, revoke the kubeconfig files for all clusters created by the RAM user.
If the RAM user is permanently deleted
Manually delete the RBAC bindings for the deleted RAM user or RAM role.
ACK names bindings using the RAM user or role ID:
| Binding type | Naming format |
|---|---|
| ClusterRoleBinding | xxxxxxx-clusterrolebinding |
| RoleBinding | xxxxxxx-yyyyy-rolebinding |
The ID prefix indicates the principal type: 2 = RAM user, 3 = RAM role.
Step 1: List ClusterRoleBindings
As the cluster administrator:
kubectl get clusterrolebinding
Identify bindings that start with the deleted user's or role's ID.
Step 2: List RoleBindings
kubectl get rolebinding -A | grep 'cs:ns:'
Identify bindings that start with the deleted user's or role's ID.
Step 3: Verify whether the RAM user or role still exists
-
For bindings with a prefix of
2(RAM user): In the RAM console, go to Users and search by RAM user ID. If the user is not found, delete the binding. -
For bindings with a prefix of
3(RAM role): Call the ListRoles API. If the RAM role ID does not appear in the response, delete the binding.
Step 4: Delete the orphaned bindings
kubectl delete clusterrolebinding xxxxxxx-clusterrolebinding
kubectl delete rolebinding xxxxxxx-yyyyy-rolebinding -n zzzz
Replace xxxxxxx with the RAM user or role ID, yyyyy with the binding identifier, and zzzz with the namespace of the RoleBinding.