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

Selon la période de validité

Selon la méthode d'accès

Une EIP associée entraîne des frais de paiement à l'utilisation .

Pour les clusters dédiés ACK avec accès public, vous pouvez également vous connecter au nœud maître via SSH pour récupérer le kubeconfig.

Renouveler les identifiants avant leur expiration

Un kubeconfig de longue durée est valide pendant 3 ans. Obtenez-en un nouveau depuis la console ACK ou via l'API DescribeClusterUserKubeconfig dans les 180 jours précédant l'expiration afin d'éviter toute interruption de service.

Le nouveau kubeconfig est valide pendant 3 ans. L'ancien reste valide jusqu'à sa date d'expiration initiale.

Révoquer des identifiants compromis

Si vous suspectez qu'un kubeconfig a été compromis, révoquez immédiatement les identifiants kubeconfig du cluster. Cette action invalide toutes les connexions existantes et génère un nouveau kubeconfig.

Nettoyer les autorisations des utilisateurs partis

Lorsqu'un utilisateur n'a plus besoin d'accès (par exemple, après la fin d'un projet ou le départ d'un employé), révoquez ses autorisations kubeconfig en masse en supprimant les fichiers kubeconfig ou en utilisant ack-ram-tool. Le système ne génère pas de nouveau kubeconfig après la révocation.

Pour restaurer des autorisations révoquées par erreur, utilisez la corbeille kubeconfig .

Comment trouver l'identité associée à un certificat kubeconfig ?

Extrayez le sujet du certificat :

# 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:

Résultat attendu :

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

• O — Le groupe d'utilisateurs Kubernetes. Dans cet exemple, system:users.

• CN — L'identifiant de l'utilisateur. Dans cet exemple, 1***-1673419473, où 1*** correspond à l'ID utilisateur Alibaba Cloud.

Comment vérifier la date d'expiration d'un certificat kubeconfig ?

Vérifiez l'expiration du certificat :

# 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

Résultat attendu :

notAfter=Jan 10 06:44:34 2026 GMT

Dans cet exemple, le certificat expire le 10 janvier 2026.

Obtenez un nouveau kubeconfig depuis la console ou l'API dans les 180 jours précédant l'expiration, ou à tout moment après celle-ci.

Comment extraire le certificat client, la clé privée et l'URL du serveur API d'un kubeconfig ?

Extrayez le certificat, la clé et l'URL du serveur API :

# 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}')

Comment résoudre l'erreur « certificate is valid for » ?

Cette erreur survient lorsque vous associez une nouvelle adresse IP à l'instance Server Load Balancer (SLB) du serveur API. Les commandes kubectl ciblant la nouvelle IP échouent avec l'erreur Error while proxying request: x509: certificate is valid for xxx ou Unable to connect to the server: x509: certificate is valid for xxx.

La solution dépend du type de votre cluster :

• Clusters gérés ACK : Ajoutez la nouvelle adresse IP au Subject Alternative Name (SAN) du certificat du serveur API.

• Clusters dédiés ACK : Configurez kubectl pour ignorer la vérification TLS à l'aide de l'une des méthodes suivantes :

  Important

  Ignorer la vérification TLS présente un risque de sécurité. N'utilisez pas cette méthode en production. Migrez vers des clusters ACK Pro, puis ajoutez la nouvelle adresse IP au SAN du certificat du serveur API.

  • Méthode 1 : Passez l'option --insecure-skip-tls-verify :

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

  • Méthode 2 : Modifiez le fichier kubeconfig. Ajoutez insecure-skip-tls-verify: true et supprimez le champ certificate-authority-data :

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

Puis-je obtenir la clé du certificat racine d'un cluster géré ACK pour générer moi-même un kubeconfig ?

Non. Les clusters gérés ACK n'exposent pas la clé du certificat racine. Obtenez le kubeconfig depuis la console ou via l'API DescribeClusterUserKubeconfig.