Votre cluster Kubernetes est-il sécurisé ou est-il simplement en cours d'exécution ?Les configurations Kubernetes par défaut donnent la priorité à la facilité d'utilisation plutôt qu'à la sécurité. Sans un renforcement délibéré, les clusters sont vulnérables aux fuites de conteneurs, à l’élévation des privilèges, aux mouvements latéraux et au vol de données. Cette liste de contrôle couvre tous les contrôles de sécurité que vous devez mettre en œuvre pour les environnements de production Kubernetes.
Points clés à retenir
- Kubernetes par défaut n'est pas sécurisé :Les configurations prêtes à l'emploi permettent des conteneurs privilégiés, un accès réseau illimité et des autorisations de serveur API étendues.
- RBAC est votre première défense :Limitez l’accès au serveur API au minimum requis pour chaque compte de service et utilisateur.
- Les politiques de réseau empêchent les mouvements latéraux :Sans politiques réseau, chaque pod peut communiquer avec tous les autres pods : un réseau plat au sein de votre cluster.
- Les normes de sécurité des pods remplacent la PSP :Pod Security Admission (PSA) applique des contraintes de sécurité sur tous les pods.
- La sécurité de la chaîne d’approvisionnement est importante :Vérifiez la provenance des images, recherchez les vulnérabilités et appliquez des politiques d’image via le contrôle d’admission.
Kubernetes Liste de contrôle de sécurité
API Sécurité du serveur
- Activez RBAC et désactivez l'authentification anonyme
- Utilisez une authentification forte (OIDC, basée sur un certificat) – pas d'authentification de base ou de jetons statiques
- Restreindre l'accès au serveur API aux plages IP connues (Kubernetes géré : utiliser les réseaux autorisés)
- Activer la journalisation d'audit pour toutes les requêtes du serveur API
- Désactiver les fonctionnalités alpha/bêta dans les clusters de production
- Configurer les contrôleurs d'admission : PodSecurity, ResourceQuota, LimitRange
Meilleures pratiques RBAC
- Suivre le moindre privilège : aucune liaison ClusterAdmin pour les comptes de service
- Utilisez des rôles avec espace de noms au lieu de ClusterRoles lorsque cela est possible
- Auditez régulièrement RBAC avec des outils comme kubectl-who-can et rbac-lookup
- N'accordez jamais d'autorisations génériques (verbes : ["*"], ressources : ["*"])
- Restreindre l'accès aux secrets — n'accorder l'accès/liste des secrets qu'aux pods qui en ont besoin
- Utilisez des comptes de service distincts par application (pas le compte de service par défaut)
Sécurité du réseau
- Implémenter des NetworkPolicies de refus par défaut dans tous les espaces de noms
- Autoriser uniquement le trafic d'entrée et de sortie requis par application
- Utilisez un CNI prenant en charge NetworkPolicies (Calico, Cilium, Antrea)
- Chiffrer la communication inter-pods avec le service mesh mTLS (Istio, Linkerd)
- Restreindre la sortie aux points de terminaison externes connus (empêcher l'exfiltration de données)
- Isolez les charges de travail sensibles dans des espaces de noms dédiés avec des politiques strictes
Sécurité des pods
- Activer l'admission à la sécurité des pods au niveau de l'espace de noms (appliquer le profil « restreint »)
- Exécuter les conteneurs en tant que non-root (runAsNonRoot : true)
- Utiliser le système de fichiers racine en lecture seule (readOnlyRootFilesystem : true)
- Supprimez toutes les fonctionnalités, ajoutez uniquement ce qui est nécessaire (supprimez : ["ALL"])
- Désactiver l'élévation de privilèges (allowPrivilegeEscalation : false)
- Définissez des limites de ressources (CPU, mémoire) sur tous les conteneurs pour éviter les abus de ressources
- Ne montez pas le jeton du compte de service sauf si cela est nécessaire (automountServiceAccountToken : false)
Sécurité des images
- Analyser toutes les images à la recherche de vulnérabilités avant le déploiement (Trivy, Snyk)
- Utilisez des images de base minimales (sans distribution, Alpine) pour réduire la surface d'attaque
- Signez les images des conteneurs et vérifiez les signatures à l'admission (cosign, notation)
- Autoriser uniquement les images provenant de registres de confiance (appliquer via le contrôle d'admission)
- N'utilisez jamais la balise :latest — épinglez des résumés d'images spécifiques pour plus de reproductibilité
- Reconstruisez et mettez à jour régulièrement les images de base pour incorporer les correctifs de sécurité
Gestion des secrets
- Ne stockez pas de secrets dans des variables d'environnement ou dans ConfigMaps
- Utiliser la gestion externe des secrets (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault)
- Si vous utilisez Kubernetes Secrets, activez le chiffrement au repos (EncryptionConfiguration)
- Effectuez régulièrement une rotation des secrets avec une rotation automatisée via des opérateurs de secrets externes
- Restreindre l'accès RBAC aux secrets — la plupart des pods ne devraient pas être en mesure de répertorier tous les secrets
Surveillance et détection
- Activez la journalisation d'audit Kubernetes et transférez-la à SIEM
- Déployer la surveillance de la sécurité d'exécution (Falco, Sysdig)
- Surveiller : l'exécution inattendue de processus, les connexions réseau, les modifications de fichiers, l'élévation de privilèges
- Alerte sur : nouvelle création de ClusterRoleBinding, accès secret par des pods inattendus, commandes d'exécution de conteneur
- Implémenter les violations de la politique de sécurité des pods en tant qu'alertes SIEM
CIS Kubernetes Indice de référence
Le Center for Internet Security (CIS) publie des tests de sécurité détaillés pour Kubernetes. Utilisez Kube-bench pour évaluer automatiquement votre cluster par rapport aux benchmarks CIS. Traitez tous les résultats critiques et élevés avant le déploiement en production. Les services gérés Kubernetes (EKS, AKS, GKE) gèrent automatiquement certains éléments de référence, mais les éléments responsables du client nécessitent toujours une configuration.
Comment Opsio sécurise Kubernetes
- Évaluation de la sécurité du cluster :Nous évaluons vos clusters Kubernetes par rapport aux références CIS et aux meilleures pratiques des fournisseurs de cloud.
- Mise en œuvre du durcissement :Nous mettons en œuvre tous les éléments de la liste de contrôle, y compris le RBAC, les politiques réseau, la sécurité des pods et la surveillance.
- Surveillance du temps d'exécution :Notre SOC surveille les clusters Kubernetes pour détecter les événements de sécurité et les comportements anormaux.
- Application des règles :Nous déployons OPA/Gatekeeper ou Kyverno pour appliquer automatiquement les politiques de sécurité.
- Gestion courante :Examens de sécurité réguliers, réévaluation des références CIS et mises à jour de la configuration de sécurité.
Foire aux questions
Quel est le contrôle de sécurité Kubernetes le plus important ?
Politiques réseau avec refus par défaut. Sans politiques réseau, chaque pod peut communiquer avec tous les autres pods : un pod d'application Web compromis peut accéder directement au pod de base de données, à la pile de surveillance et au serveur Kubernetes API. Les politiques réseau de refus par défaut réduisent immédiatement le rayon d’action de tout conteneur compromis.
Dois-je utiliser un maillage de services pour la sécurité ?
Le maillage de services (Istio, Linkerd) ajoute mTLS entre les services, fournissant le cryptage et l'authentification pour toutes les communications inter-pods. Si vous gérez des données sensibles ou devez répondre aux exigences de conformité en matière de chiffrement en transit, le maillage de services est précieux. Pour les environnements plus simples, les politiques réseau seules peuvent suffire.
Comment gérer les secrets dans Kubernetes en toute sécurité ?
Utilisez un gestionnaire de secrets externe (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) avec un opérateur de secrets Kubernetes (External Secrets Operator, Vault Secrets Operator). Cela maintient les secrets hors de Git, fournit une journalisation d'audit, permet la rotation et centralise la gestion des secrets sur les charges de travail Kubernetes et non-Kubernetes.