Container Service for Kubernetes:Get a cluster kubeconfig and connect to the cluster using kubectl

By validity period

By access method

A bound EIP incurs charges. For details, see Pay-as-you-go.

If you have an ACK dedicated cluster with public access enabled, you can also get the kubeconfig file directly from the master node via SSH. For more information, see Connect to the master node of an ACK dedicated cluster by using SSH.

Rotate credentials before they expire

A long-term kubeconfig is valid for 3 years. To prevent service disruptions, get a new kubeconfig from the ACK console or through the DescribeClusterUserKubeconfig API within 180 days of its expiration.

The new kubeconfig is also valid for 3 years. The old kubeconfig remains valid until its original expiration date.

Revoke compromised credentials

If you suspect a kubeconfig file has been compromised, revoke the cluster's kubeconfig credentials immediately. This invalidates all connections that use the old credentials and generates a new kubeconfig.

Clean up permissions for departing users

When a user no longer needs access (for example, after a project ends or an employee leaves), revoke their kubeconfig permissions in bulk. After revocation, the system does not generate a new kubeconfig. For details, see Delete kubeconfig files and Use ack-ram-tool to revoke the permissions of specified users on ACK clusters.

To recover accidentally deleted permissions, use the kubeconfig recycle bin to restore specific revoked kubeconfig permissions.

How do I find the identity associated with a kubeconfig certificate?

Run the following command to extract the certificate subject:

# Extract the client certificate, decode it from base64,
# then use OpenSSL to display the Subject field
grep client-certificate-data kubeconfig | awk '{print $2}' | base64 -d | openssl x509 -noout -text | grep Subject:

The output looks similar to:

        Subject: O=system:users, OU=, CN=1***-1673419473

• O -- The Kubernetes user group. In this example, system:users.

• CN -- The user identifier. In this example, 1***-1673419473, where 1*** is the Alibaba Cloud user ID.

How do I check when a kubeconfig certificate expires?

Run the following command:

# Extract the client certificate, decode it from base64,
# then use OpenSSL to print the expiration date
grep client-certificate-data kubeconfig | awk '{print $2}' | base64 -d | openssl x509 -noout -enddate

The output looks similar to:

notAfter=Jan 10 06:44:34 2026 GMT

In this example, the certificate expires on January 10, 2026.

Get a new kubeconfig from the console or by calling the API within 180 days before the certificate expires, or at any time after it has expired.

How do I extract the client certificate, private key, and API server URL from a kubeconfig?

Run the following commands:

# Extract and decode the client certificate to a PEM file
grep client-certificate-data ./kubeconfig | awk -F ' ' '{print $2}' | base64 -d > ./client-cert.pem

# Extract and decode the client private key to a PEM file
grep client-key-data ./kubeconfig | awk -F ' ' '{print $2}' | base64 -d > ./client-key.pem

# Extract the API server URL into a variable
APISERVER=$(grep server ./kubeconfig | awk -F ' ' '{print $2}')

How do I resolve the "certificate is valid for" error?

This error occurs when you bind a new IP address to the Server Load Balancer (SLB) instance for the cluster's API server. kubectl commands targeting the new IP fail with an Error while proxying request: x509: certificate is valid for xxx or Unable to connect to the server: x509: certificate is valid for xxx error.

The fix depends on your cluster type:

• ACK managed clusters: Add the new IP address to the Subject Alternative Name (SAN) of the API server certificate. For more information, see Customize the SANs of the API server certificate when you create an ACK cluster.

• ACK dedicated clusters: Configure kubectl to skip TLS verification using one of these methods:

  Important

  Skipping TLS verification is a security risk. Do not use this in production. Migrate to ACK Pro clusters, then add the new IP address to the SAN of the API server certificate.

  • Method 1: Pass the --insecure-skip-tls-verify flag:

    kubectl -s https://<IP>:6443 --insecure-skip-tls-verify get ns

  • Method 2: Edit the kubeconfig file. Add insecure-skip-tls-verify: true and remove the certificate-authority-data field:

    apiVersion: v1
    clusters:
    - cluster:
        server: https://<IP>:6443
        insecure-skip-tls-verify: true
      name: kubernetes
    contexts:
    ...

Can I get the root certificate key for an ACK managed cluster to generate a kubeconfig myself?

No. ACK managed clusters do not expose the root certificate key. Get the cluster kubeconfig from the console or by calling the DescribeClusterUserKubeconfig API.