Sécuriser l'authentification Kubernetes

Le service managé Kubernetes intègre des mécanismes de sécurité pour protéger l'accès au cluster et les ressources. Cette page présente les bonnes pratiques pour sécuriser l'authentification, notamment dans un contexte de conformité SecNumCloud.

Connexions sécurisées TLS

Toutes les communications avec l'API server Kubernetes sont chiffrées avec TLS (Transport Layer Security).

Vérifier le chiffrement TLS

Le fichier kubeconfig utilise automatiquement TLS pour toutes les connexions. Vérifiez la configuration :

kubectl config view --raw -o jsonpath='{.clusters[*].cluster.server}'

L'URL doit commencer par https://.

Certificats

Le service managé Kubernetes gère automatiquement les certificats TLS pour l'API server. Les certificats sont renouvelés automatiquement avant expiration.

Authentification avec le kubeconfig

Télécharger le kubeconfig

Pour télécharger le fichier kubeconfig, consultez Télécharger le kubeconfig.

# Définir le fichier kubeconfig
export KUBECONFIG=~/chemin/vers/kubeconfig

# Vérifier la connexion
kubectl get nodes

Sécuriser le kubeconfig

Le fichier kubeconfig contient des identifiants sensibles. Appliquez ces bonnes pratiques :

# Restreindre les permissions du fichier
chmod 600 ~/chemin/vers/kubeconfig

# Ne jamais commiter le kubeconfig dans un dépôt git

Authentification forte et conformité SecNumCloud

Pour répondre aux exigences SecNumCloud en matière d'authentification forte, combinez plusieurs couches de sécurité.

Architecture multi-facteurs recommandée

Facteur	Mécanisme	Protection
Ce que vous savez	Token kubeconfig	Authentification Kubernetes
Ce que vous possédez	Accès VPN	Couche réseau
Ce que vous êtes	Contrôle d'accès réseau (IP, VPC)	Périmètre de sécurité

Configuration recommandée pour environnements sensibles

1. Accès via réseau privé : Connectez-vous au cluster via un VPN ou un VPC (Virtual Private Cloud) pour limiter l'exposition du control plane ;

2. Restriction des IP : Limitez l'accès aux plages d'adresses IP autorisées ;

3. Rotation des identifiants : Régénérez régulièrement le kubeconfig.

note

L'authentification multi-facteurs native Kubernetes n'est pas actuellement configurable via l'API Numspot. Pour une authentification forte, utilisez le contrôle d'accès au niveau réseau (VPN, bastion).

Authentification multi-facteurs (MFA)

Kubernetes ne dispose pas de MFA natif. Pour implémenter une authentification multi-facteurs, utilisez une architecture en couches.

Approche MFA recommandée

Couche	Mécanisme	Facteur
Couche 1	Token/Certificat kubeconfig	Ce que vous savez
Couche 2	VPN avec MFA	Ce que vous possédez
Couche 3	Certificat client	Ce que vous possédez
Couche 4	Restriction IP/VPC	Ce que vous êtes

Configuration MFA via bastion

Pour implémenter le MFA, installez un bastion avec authentification forte :

1. Bastion SSH avec MFA :

   • Déployez un bastion SSH avec support MFA (TOTP, clé hardware) ;
   • Configurez l'accès au cluster uniquement via le bastion.

2. Accès via VPN avec MFA :

   • Configurez un VPN avec authentification MFA ;
   • Limitez l'accès au cluster aux clients connectés au VPN.

Architecture MFA type

[Utilisateur/kubectl] 
    → [VPN avec MFA] 
    → [Bastion SSH] 
    → [Cluster Kubernetes]

Intégration OIDC

Pour les déploiements critiques, intégrez un fournisseur d'identité externe OIDC (OpenID Connect) :

• Authentification centralisée ;
• Support MFA natif via le fournisseur d'identité ;
• Gestion des groupes et des utilisateurs externe.

Consultez le support Numspot pour configurer l'authentification OIDC.

Politique de mots de passe

Les clusters Kubernetes managés n'utilisent pas de mots de passe traditionnels. L'authentification repose sur des tokens et certificats.

Gestion des tokens

• Les tokens sont générés automatiquement lors de la création du cluster ;
• Les tokens ont une durée de vie limitée ;
• Renouvelez le kubeconfig si vous suspectez une compromission.

RBAC (Role-Based Access Control)

Kubernetes utilise RBAC pour gérer les permissions. Configurez RBAC selon le principe du moindre privilège.

Structure RBAC

Composant	Description
Role	Permissions au niveau d'un namespace
ClusterRole	Permissions au niveau du cluster
RoleBinding	Lie un Role à un utilisateur ou groupe
ClusterRoleBinding	Lie un ClusterRole à un utilisateur ou groupe

Pour plus de détails, consultez Gérer les utilisateurs et les rôles.

Audit des connexions

Le cluster Kubernetes journalise les événements d'authentification pour permettre l'audit et la détection d'anomalies.

Événements journalisés

Événement	Description
Connexion à l'API	Appels à l'API server
Opérations sur les ressources	Création, modification, suppression
Échecs d'authentification	Tentatives avec identifiants invalides

Consulter les logs d'audit

Les logs Kubernetes sont disponibles via les outils d'observabilité de votre cluster. Contactez le support pour accéder aux logs d'audit.

Audit des accès RBAC

Vérifiez les accès existants avec ces commandes :

# Lister les roles
kubectl get roles --all-namespaces

# Lister les clusterroles
kubectl get clusterroles

# Lister les rolebindings
kubectl get rolebindings --all-namespaces

# Lister les clusterrolebindings
kubectl get clusterrolebindings

# Vérifier les permissions d'un utilisateur
kubectl auth can-i --list --as=system:anonymous

Protection contre les attaques

Limitation des tentatives

Le service managé Kubernetes applique des protections contre les attaques par force brute :

• Rate limiting sur l'API server ;
• Blocage temporaire après échecs répétés ;
• Protection contre les dénis de service.

note

Le service Kubernetes managé n'applique pas de blocage automatique configurable après un nombre défini d'échecs de connexion. Pour un blocage automatique basé sur le nombre de tentatives, utilisez un outil externe comme un pare-feu applicatif ou une solution de sécurité périmétrique.

Détection des anomalies

Surveillez les comportements suspects :

• Multiples échecs de connexion depuis une même IP ;
• Tentatives d'accès à des ressources non autorisées ;
• Appels API inhabituels ou à des heures anormales.

Bloquer un utilisateur en cas d'utilisation abusive

Si vous détectez une activité suspecte ou un compte compromis, vous pouvez bloquer immédiatement l'accès.

Révoquer un kubeconfig

En cas de compromission, contactez le support Numspot pour régénérer le kubeconfig principal.

En attendant, révoquez immédiatement les accès via RBAC :

# Supprimer les RoleBindings de l'utilisateur compromis
kubectl delete rolebinding -n <namespace> <nom_rolebinding>

# Supprimer les ClusterRoleBindings
kubectl delete clusterrolebinding <nom_clusterrolebinding>

Consultez Gérer les utilisateurs et les rôles pour plus de détails sur la gestion RBAC.

Bloquer un ServiceAccount

# Supprimer un ServiceAccount compromis
kubectl delete serviceaccount <nom_serviceaccount> -n <namespace>

Restreindre via RBAC

Révoquez les permissions d'un utilisateur :

# Supprimer un RoleBinding
kubectl delete rolebinding <nom_rolebinding> -n <namespace>

# Supprimer un ClusterRoleBinding
kubectl delete clusterrolebinding <nom_clusterrolebinding>

Vérifier les accès actifs

# Vérifier qui peut effectuer une action
kubectl auth can-i <verbe> <ressource> --all-namespaces

# Vérifier les permissions d'un utilisateur spécifique
kubectl auth can-i --list --as=<utilisateur>

Supprimer définitivement un accès

Si le compte n'est plus nécessaire ou si la compromission est confirmée :

# Supprimer les RoleBindings de l'utilisateur
kubectl delete rolebinding -n <namespace> --field-selector=subjects\[0\].name=<utilisateur>

# Supprimer les ClusterRoleBindings de l'utilisateur
kubectl delete clusterrolebinding --field-selector=subjects\[0\].name=<utilisateur>

avertissement

La suppression est irréversible. Vérifiez qu'aucune application ne dépend de cet accès avant la suppression.

Procédure de réponse à un incident

En cas de détection d'utilisation abusive :

1. Régénérer le kubeconfig pour invalider les anciens tokens ;
2. Révoquer les RBAC de l'utilisateur compromis ;
3. Analyser les logs pour identifier l'origine de l'attaque ;
4. Restreindre l'accès réseau via les groupes de sécurité ou le VPN ;
5. Appliquer des restrictions réseau sur le cluster si nécessaire.

Extraire les droits pour audit

Audit des permissions RBAC

# Exporter toutes les permissions RBAC
kubectl get roles,rolebindings,clusterroles,clusterrolebindings --all-namespaces -o yaml > rbac-audit.yaml

# Lister les accès par utilisateur
kubectl get rolebindings,clusterrolebindings --all-namespaces -o json | jq '.items[] | select(.subjects[]?.name != null) | {name: .metadata.name, namespace: .metadata.namespace, subjects: .subjects}'

Audit croisé

Vérifiez que les permissions appliquées correspondent aux politiques de sécurité :

# Vérifier qu'aucun utilisateur anonyme n'a d'accès
kubectl auth can-i --list --as=system:anonymous

# Vérifier les accès à des ressources sensibles
kubectl auth can-i create pods --as=<utilisateur> -n <namespace>
kubectl auth can-i delete deployments --as=<utilisateur> -n <namespace>
kubectl auth can-i create secrets --as=<utilisateur> -n <namespace>

Résumé des bonnes pratiques SecNumCloud

Exigence	Implémentation recommandée
Chiffrement des connexions	TLS obligatoire (https)
Authentification forte	Réseau privé (VPN/VPC) + kubeconfig
Politique RBAC	Principe du moindre privilège
Audit des accès	Logs d'audit activés, revue régulière RBAC
Contrôle d'accès	RBAC par namespace, restriction réseau
Blocage de compte	Révocation kubeconfig et RoleBindings en cas d'incident
Audit des droits	Extraction régulière des RBAC, audit croisé

astuce

Pour les architectures critiques, installez un bastion SSH ou un proxy d'accès pour centraliser et auditer toutes les connexions au cluster Kubernetes.