All Products
Search
Document Center

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

Last Updated:Jun 15, 2026

Use a temporary or long-term kubeconfig to authenticate kubectl with your cluster's API server.

You can also manage clusters and applications through the ACK console.

Important

Under the shared responsibility model, secure your kubeconfig credentials by rotating them regularly and following the principle of least privilege.

Choose a kubeconfig type

Choose a kubeconfig type based on how long you need access and how your client connects to the cluster.

By validity period

Type

Validity

Best for

Security

Temporary

30 minutes to 3 days (configurable)

Daily operations and maintenance (O&M), troubleshooting, CI/CD pipelines

Lower risk—auto-expires after the configured period

Long-term

3 years (default)

Automated systems, long-running monitoring services

Requires manual rotation before expiry

By access method

Type

When to use

Details

Private access

Your client machine is in the same Virtual Private Cloud (VPC) as the cluster

Connects over the internal network with lower latency and stronger security

Public access

Connect from any machine with Internet access

Exposes the API server through an Elastic IP Address (EIP)—for local development and remote O&M

A bound EIP incurs pay-as-you-go charges.

For ACK dedicated clusters with public access, you can also connect to the master node via SSH to get the kubeconfig.

Prerequisites

Before you begin, make sure that you have:

  • kubectl installed, within one minor version of your cluster's Kubernetes version (e.g., kubectl 1.27–1.29 for Kubernetes 1.28).

  • A RAM user with permissions granted at both ACK and cluster levels.

Get a kubeconfig file and connect to the cluster

  1. Log on to the ACK console. In the left navigation pane, click Clusters.

  2. On the Clusters page, click your cluster name, or click Details in the Actions column.

  3. On the Cluster Information page, click the Connection Information tab. Select a temporary or long-term kubeconfig. For a temporary kubeconfig, set the validity period.

  4. Click the Internal Access or Public Access tab, then click Copy.

  5. Paste the content into the $HOME/.kube/config file on your client, and save the file.

    Note: If the directory or file does not exist, create it first.
  6. Verify the connection by listing all namespaces:

    kubectl get namespaces

    Expected output:

    NAME              STATUS   AGE
    default           Active   4h39m
    kube-node-lease   Active   4h39m
    kube-public       Active   4h39m
    kube-system       Active   4h39m

Manage kubeconfig credentials

Rotate credentials before they expire

A long-term kubeconfig is valid for 3 years. Get a new one from the ACK console or the DescribeClusterUserKubeconfig API within 180 days of expiration to avoid service disruptions.

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

Revoke compromised credentials

If you suspect a kubeconfig is compromised, revoke the cluster's kubeconfig credentials immediately. This invalidates all existing connections 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 by deleting kubeconfig files or using ack-ram-tool. The system does not generate a new kubeconfig after revocation.

To restore accidentally revoked permissions, use the kubeconfig recycle bin.

FAQ

By default, kubectl uses $HOME/.kube/config. To use a different file, set the KUBECONFIG environment variable or pass the --kubeconfig flag. In the commands below, replace kubeconfig with the path to your kubeconfig file.

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

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:

Expected output:

        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?

Check the certificate expiration:

# 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

Expected output:

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 API within 180 days before expiration, or at any time after it expires.

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

Extract the certificate, key, and API server URL:

# 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 API server. kubectl commands targeting the new IP fail with Error while proxying request: x509: certificate is valid for xxx or Unable to connect to the server: x509: certificate is valid for xxx.

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.

  • ACK dedicated clusters: Configure kubectl to skip TLS verification with 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 kubeconfig from the console or the DescribeClusterUserKubeconfig API.

References