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.
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
-
Log on to the ACK console. In the left navigation pane, click Clusters.
-
On the Clusters page, click your cluster name, or click Details in the Actions column.
-
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.
-
Click the Internal Access or Public Access tab, then click Copy.
-
Paste the content into the
$HOME/.kube/configfile on your client, and save the file.Note: If the directory or file does not exist, create it first.
-
Verify the connection by listing all namespaces:
kubectl get namespacesExpected 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 theKUBECONFIGenvironment variable or pass the--kubeconfigflag. In the commands below, replacekubeconfigwith 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, where1***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:
ImportantSkipping 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-verifyflag:kubectl -s https://<IP>:6443 --insecure-skip-tls-verify get ns -
Method 2: Edit the kubeconfig file. Add
insecure-skip-tls-verify: trueand remove thecertificate-authority-datafield: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
-
Query a kubeconfig programmatically with the DescribeClusterUserKubeconfig API.
-
Log on to a cluster node. See ECS remote connection methods.