Télécharger le kubeconfig d'un cluster Kubernetes

Téléchargez le fichier kubeconfig d'un cluster Kubernetes. Ce fichier permet à un client Kubernetes de se connecter au cluster.

info

Exemple d'utilisation avec kubectl :

kubectl --kubeconfig=kubeconfig.yaml get nodes

Permissions

info

Cette action nécessite les permissions IAM (Identity and Access Management) suivantes :

• kubernetes.cluster.get

Console

1. Depuis le menu latéral gauche, cliquez sur Services managés → Kubernetes pour accéder à la liste des clusters Kubernetes.

   

2. Cliquez sur l'ID du cluster dont vous souhaitez télécharger le kubeconfig pour accéder à sa page de détails.

   

3. Dans la section Général, cliquez sur le bouton Voir KubeConfig.

   

4. Dans la fenêtre qui s'affiche, choisissez l'action souhaitée :

   • Copier KubeConfig : copie le contenu du kubeconfig dans le presse-papiers ;
   • KubeConfig (icône télécharger) : télécharge le fichier kubeconfig au format YAML.

   

   note

   Le bouton Voir KubeConfig n'est disponible que si le cluster est à l'état « En cours » (running).

API

Utilisez la route GET /kubernetes/spaces/{spaceId}/clusters/{clusterId}/kubeConfig pour récupérer le fichier kubeconfig d'un cluster Kubernetes.

Exemple de réponse

{
  "kubeConfig": "apiVersion: v1\nclusters:\n- cluster:\n    certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0t...\n    server: https://550e8400-e29b-41d4-a716-446655440000.eu-west-2.numspot.com:6443\n  name: mon-cluster\ncontexts:\n- context:\n    cluster: mon-cluster\n    user: admin\n  name: admin@mon-cluster\ncurrent-context: admin@mon-cluster\nkind: Config\npreferences: {}\nusers:\n- name: admin\n  user:\n    client-certificate-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0t...\n    client-key-data: LS0tLS1CRUdJTiBFQyBQUklWQVRFIEtFWS0tLS0t..."
}

Voir la spécification complète

Créer un kubeconfig spécifique pour un utilisateur

Le kubeconfig récupéré via l'API possède des droits administrateur. Pour créer un kubeconfig avec des permissions limitées, utilisez un ServiceAccount.

Principe

1. Créez un ServiceAccount ;
2. Attribuez des permissions via RBAC (Role-Based Access Control) ;
3. Extrayez le token du ServiceAccount ;
4. Générez un kubeconfig personnalisé.

Créer un ServiceAccount

apiVersion: v1
kind: ServiceAccount
metadata:
  name: dev-user
  namespace: production

kubectl apply -f serviceaccount.yaml

Attribuer des permissions

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: developer
  namespace: production
rules:
- apiGroups: [""]
  resources: ["pods", "services", "configmaps"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
- apiGroups: ["apps"]
  resources: ["deployments", "replicasets"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: dev-user-binding
  namespace: production
subjects:
- kind: ServiceAccount
  name: dev-user
  namespace: production
roleRef:
  kind: Role
  name: developer
  apiGroup: rbac.authorization.k8s.io

kubectl apply -f role.yaml

Extraire le token du ServiceAccount

# Kubernetes < 1.24 : token automatiquement créé
kubectl get secret -n production $(kubectl get serviceaccount dev-user -n production -o jsonpath='{.secrets[0].name}') -o jsonpath='{.data.token}' | base64 -d

# Kubernetes >= 1.24 : créer un token manuellement
kubectl create token dev-user -n production --duration=8760h

Générer le kubeconfig personnalisé

#!/bin/bash

CLUSTER_NAME="mon-cluster"
CLUSTER_ENDPOINT="https://<cluster-endpoint>:6443"
NAMESPACE="production"
SA_NAME="dev-user"

# Récupérer le CA du cluster
CA_CERT=$(kubectl config view --raw -o jsonpath='{.clusters[0].cluster.certificate-authority-data}')

# Créer le token (Kubernetes >= 1.24)
TOKEN=$(kubectl create token $SA_NAME -n $NAMESPACE --duration=8760h)

# Générer le kubeconfig
cat > kubeconfig-dev-user.yaml <<EOF
apiVersion: v1
kind: Config
clusters:
- cluster:
    certificate-authority-data: $CA_CERT
    server: $CLUSTER_ENDPOINT
  name: $CLUSTER_NAME
contexts:
- context:
    cluster: $CLUSTER_NAME
    namespace: $NAMESPACE
    user: $SA_NAME
  name: ${SA_NAME}@${CLUSTER_NAME}
current-context: ${SA_NAME}@${CLUSTER_NAME}
users:
- name: $SA_NAME
  user:
    token: $TOKEN
EOF

echo "Kubeconfig généré: kubeconfig-dev-user.yaml"

Vérifier le kubeconfig

# Tester la connexion
kubectl --kubeconfig=kubeconfig-dev-user.yaml get pods -n production

# Vérifier les permissions
kubectl --kubeconfig=kubeconfig-dev-user.yaml auth can-i --list

Rotation des kubeconfig

La rotation des identifiants kubeconfig est essentielle pour la sécurité. Effectuez une rotation régulière (tous les 90 jours pour les environnements sensibles).

Rotation du kubeconfig principal

Pour régénérer le kubeconfig principal (admin), contactez le support Numspot qui procédera à la rotation des identifiants.

En attendant la rotation, vous pouvez immédiatement bloquer les accès suspects via RBAC (voir Bloquer un utilisateur).

Rotation des tokens ServiceAccount

Pour les ServiceAccounts, créez un nouveau token :

# Supprimer l'ancien token (si secret existant)
kubectl delete secret -n <namespace> <nom-secret>

# Créer un nouveau token
kubectl create token <serviceaccount> -n <namespace> --duration=8760h

Automatiser la rotation

Créez un script de rotation automatisé :

#!/bin/bash

CLUSTER_NAME="mon-cluster"
NAMESPACE="production"
SA_NAME="dev-user"
KUBECONFIG_PATH="/path/to/kubeconfigs"

# Créer un nouveau token
NEW_TOKEN=$(kubectl create token $SA_NAME -n $NAMESPACE --duration=8760h)

# Récupérer le CA
CA_CERT=$(kubectl config view --raw -o jsonpath='{.clusters[0].cluster.certificate-authority-data}')

# Récupérer l'endpoint
CLUSTER_ENDPOINT=$(kubectl config view --raw -o jsonpath='{.clusters[0].cluster.server}')

# Générer le nouveau kubeconfig
cat > ${KUBECONFIG_PATH}/kubeconfig-${SA_NAME}-$(date +%Y%m%d).yaml <<EOF
apiVersion: v1
kind: Config
clusters:
- cluster:
    certificate-authority-data: $CA_CERT
    server: $CLUSTER_ENDPOINT
  name: $CLUSTER_NAME
contexts:
- context:
    cluster: $CLUSTER_NAME
    namespace: $NAMESPACE
    user: $SA_NAME
  name: ${SA_NAME}@${CLUSTER_NAME}
current-context: ${SA_NAME}@${CLUSTER_NAME}
users:
- name: $SA_NAME
  user:
    token: $NEW_TOKEN
EOF

echo "Nouveau kubeconfig généré: ${KUBECONFIG_PATH}/kubeconfig-${SA_NAME}-$(date +%Y%m%d).yaml"

Planification de la rotation

Type de kubeconfig	Fréquence recommandée	Méthode
Admin principal	Tous les 90 jours	API Numspot
ServiceAccount production	Tous les 90 jours	kubectl create token
ServiceAccount dev	Tous les 180 jours	kubectl create token
CI/CD	Tous les 365 jours	Automatisé

Groupes d'utilisateurs Kubernetes

Kubernetes supporte les groupes pour gérer les permissions de plusieurs utilisateurs simultanément.

Principe des groupes

Les groupes permettent de :

• Appliquer des permissions communes à plusieurs utilisateurs ;
• Simplifier la gestion des accès ;
• Faciliter l'attribution et la révocation de permissions.

Créer un RoleBinding pour un groupe

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: dev-team-binding
  namespace: production
subjects:
- kind: Group
  name: dev-team
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: developer
  apiGroup: rbac.authorization.k8s.io

ClusterRoleBinding pour un groupe

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: ops-team-binding
subjects:
- kind: Group
  name: ops-team
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: view
  apiGroup: rbac.authorization.k8s.io

Configurer un kubeconfig avec un groupe

Pour les utilisateurs authentifiés via OIDC (OpenID Connect), le groupe est fourni par le fournisseur d'identité. Le kubeconfig inclut les claims de groupe :

users:
- name: utilisateur-oidc
  user:
    auth-provider:
      config:
        client-id: kubernetes
        id-token: <jwt-token>
        idp-issuer-url: https://<oidc-provider>
      name: oidc

Gérer les groupes avec ServiceAccount

Les ServiceAccounts ne supportent pas nativement les groupes. Pour gérer des groupes d'applications :

1. Créez un ServiceAccount par application ;
2. Utilisez un RoleBinding commun pour plusieurs ServiceAccounts :

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: apps-binding
  namespace: production
subjects:
- kind: ServiceAccount
  name: app-a
  namespace: production
- kind: ServiceAccount
  name: app-b
  namespace: production
- kind: ServiceAccount
  name: app-c
  namespace: production
roleRef:
  kind: Role
  name: app-role
  apiGroup: rbac.authorization.k8s.io

Vérifier les permissions d'un groupe

# Vérifier les permissions d'un groupe
kubectl auth can-i --list --as-group=dev-team

# Vérifier une action spécifique
kubectl auth can-i create pods --as-group=dev-team -n production

Organisation des groupes recommandée

Groupe	ClusterRole/Role	Portée
system:admins	cluster-admin	Cluster
ops-team	view + nodes	Cluster
dev-team	Role développeur	Namespace
ci-cd	Role déploiement	Namespace

Bonnes pratiques de sécurité

Sécuriser le kubeconfig

# Restreindre les permissions du fichier
chmod 600 kubeconfig.yaml

# Ne jamais commiter le kubeconfig
echo "kubeconfig.yaml" >> .gitignore

# Utiliser des chemins absolus
export KUBECONFIG=/home/user/.kube/config-mon-cluster

Principe du moindre privilège

• Utilisez des ServiceAccounts dédiés pour chaque utilisateur ou application ;
• Limitez les permissions au namespace nécessaire ;
• Évitez d'utiliser le kubeconfig admin pour les opérations courantes.

Audit et surveillance

# Surveiller les connexions
kubectl get events --field-selector reason=Authenticated

# Vérifier les tokens actifs
kubectl get secrets -A --field-selector type=ServiceAccountToken