Il est certain que Kubernetes nous donne un bon ensemble de principes fondamentaux de sécurité logicielle avec lesquels travailler, mais il faut encore les comprendre et les mettre en œuvre.
Avec un déploiement distribué tel qu'un cluster Kubernetes, le nombre de vecteurs d'attaque augmente, et il est important de connaître les bonnes pratiques pour limiter autant que possible ces surfaces d'attaque.
Même en utilisant un service Kubernetes managé, une partie de la responsabilité de la sécurité incombe toujours aux utilisateurs finaux. Le fournisseur du cloud est généralement responsable de la gestion et de la sécurisation du "control plane" d'un cluster Kubernetes (API Server, scheduler, etcd, contrôleurs) et les clients sont responsables de la sécurisation du "data plane" (pools de nœuds, ingress, mise en réseau, service mesh, etc.)
J'ai commencé à travailler sur Kubernetes il y a environ six ans avec "minikube" et "Vagrant", et je suis maintenant plus familier avec les nouveaux services Cloud. Sur la base de cette expérience, voici six bonnes pratiques de sécurité Kubernetes qui devraient vous être utiles, que vous utilisiez Kubernetes open source ou un service Kubernetes géré par Oracle, Azure, AWS ou un autre fournisseur de cloud computing.
1. Utiliser le contrôle d'accès basé sur les rôles (RBAC)
Le contrôle d'accès basé sur les rôles (RBAC) permet au client de contrôler les personnes qui peuvent accéder à l'API Kubernetes et les autorisations dont elles disposent. Le RBAC est généralement activé par défaut dans Kubernetes. Toutefois, si vous avez effectué une mise à niveau à partir d'une très ancienne version de Kubernetes et que vous ne l'aviez pas activé auparavant, il convient de vérifier les paramètres RBAC pour s'assurer qu'ils sont bien activés.
Une autre chose à garder à l'esprit est que la simple activation de RBAC n'est pas suffisante. Vous devez également gérer les politiques d'autorisation et les utiliser correctement. Utilisez RBAC pour limiter les utilisateurs et les groupes aux seules actions et tâches dont ils peuvent avoir besoin. Suivez toujours le principe du moindre privilège pour vous assurer que les utilisateurs et les comptes de service Kubernetes disposent du minimum de privilèges requis. Veillez à ne pas accorder de permissions à l'échelle du cluster, et ne donnez à personne des privilèges d'administrateur de cluster, sauf en cas de nécessité absolue. Pour en savoir plus, consultez la documentation officielle de Kubernetes RBAC pour plus d'informations.
Pour les opérations sur les clusters Kubernetes créés et gérés à l'aide d'un "Cloud Provider", le fournisseur peut proposer son propre service de gestion des identités et des accès. L'authentification multifactorielle (MFA) est une autre option pour renforcer la sécurité de l'authentification à l'API Kubernetes, si vous avez besoin de plus d'un élément pour vérifier l'identité de vos administrateurs ou développeurs.
2. Les secrets doivent rester des secrets
Les secrets contiennent des données sensibles telles qu'un mot de passe, un jeton ou une clé SSH. Les secrets Kubernetes aident à initialiser de manière sécurisée les pods avec des artefacts tels que des clés, des mots de passe, des jetons, etc. Lorsqu'un pod démarre, il a généralement besoin d'accéder à ses secrets. Chaque fois qu'un compte de service est créé, un secret Kubernetes stockant son jeton d'autorisation est automatiquement généré. Kubernetes prend en charge le chiffrement au démarrage, cela permet de chiffrer les ressources secrètes dans etcd, empêchant ainsi la visualisation du contenu de ces secrets.
Le chiffrement offre un niveau de défense supplémentaire lorsque les sauvegardes ne sont pas chiffrées ou qu'un attaquant obtient un accès en lecture à etcd. Assurez-vous que la communication entre les utilisateurs et le serveur API et entre le serveur API et les kubelets est protégée par SSL/TLS, comme expliqué ici :
Il est recommandé de fixer une courte durée de vie pour un secret ou un identifiant afin qu'il soit plus difficile pour un attaquant de les utiliser. Définir des durées de vie courtes pour les certificats et automatiser leur rotation est une bonne pratique.
Une autre chose à ne pas oublier, il faut être vigilant quant aux intégrations tierces qui demandent l'accès aux secrets de votre cluster Kubernetes. Dans ce type de cas, examinez attentivement les autorisations RBAC et les accès demandés, sinon vous risquez de compromettre le profil de sécurité de votre cluster.
Si vous utilisez Oracle Kubernetes Engine, consultez cette documentation:
3. Privatisation de l'API Endpoint Kubernetes
Les administrateurs et opérateurs de cluster Kubernetes peuvent configurer le endpoint API Kubernetes d'un cluster comme faisant partie d'un sous-réseau privé ou public.
Dans un cluster privé, le serveur API (endpoint) à l'intérieur du "control plane" possède une adresse IP privée qui rend le "Master" inaccessible depuis l'internet public. En plus des nœuds "Workers" privés, vous devez vous assurer de configurer le point de terminaison de l'API Kubernetes comme un Endpoint privé. Cette mesure est importante si vous devez créer des clusters entièrement privés qui n'utilisent ou n'exposent aucune IP publique et ne permettent aucune entrée/sortie de trafic depuis/vers l'Internet public.
L'accès réseau au serveur (endpoint) API du cluster peut être contrôlé à l'aide de listes de contrôle d'accès de sécurité (ACL), ou à un niveau granulaire à l'aide de paramètres de sécurité réseau.
Par exemple, le moteur Kubernetes d'Oracle vous offre la possibilité de configurer à la fois le point de terminaison de l'API Kubernetes et les nœuds de travail.
4. Sécuriser les nœuds et les pods
Nœuds : Un nœud Kubernetes est un nœud de travail qui peut être une VM ou une machine physique fonctionnant généralement sous le système d'exploitation (OS) Linux.
Les services exécutés sur un nœud comprennent le moteur d'exécution de conteneur, kubelet et kube-proxy. Il est important de renforcer et de sécuriser le système d'exploitation exécuté sur les nœuds, ce qui est de la responsabilité du fournisseur de cloud computing et de l'administrateur Kubernetes.
Par exemple, les nœuds d'un cluster mangé "OpenShift" (RedHat) sont fournis avec une image Linux renforcée. Les correctifs de sécurité doivent être appliqués régulièrement sur l'image Linux qui fonctionne sur ces nœuds par l'administrateur Kubernetes ou en utilisant la fonctionnalité de mise à niveau automatique du fournisseur de services une fois qu'ils ont été approvisionnés par un client. L'utilisation du benchmark Kubernetes du Center for Internet Security (CIS) pour les nœuds est une autre bonne pratique.
En plus de la sécurité du système d'exploitation, il est recommandé que les nœuds restent sur un réseau privé et ne soient pas accessibles depuis Internet. Une passerelle peut être configurée pour l'accès à d'autres services en dehors du réseau du cluster, si nécessaire. L'accès aux ports réseau sur les nœuds doit être contrôlé par des (NACL) listes d'accès réseau. Il est également recommandé de limiter l'accès Secure Shell (SSH) aux nœuds. D'ailleur "Oracle" fournit fournit des conseils supplémentaires sur la sécurité du pool de nœuds du moteur Kubernetes .
Pods : Un pod est un groupe d'un ou plusieurs conteneurs qui s'exécutent sur des nœuds et peuvent utiliser un stockage partagé ou dédié.
Par défaut, il n'y a pas de restrictions sur les nœuds qui peuvent exécuter un pod. Je vous recommande d'utiliser les politiques de réseau pour définir les règles de communication pour les pods au sein d'un cluster. Les politiques réseau sont mises en œuvre par le plugin réseau et leur utilisation peut nécessiter un pilote réseau prenant en charge ces politiques.
Pour obtenir la meilleure position de sécurité réseau, essayez d'utiliser une combinaison de stratégies réseau pour sécuriser les communications réseau au niveau des pods afin de protéger les communications réseau au niveau des hôtes.
5. Éliminer les risques liés à la sécurité des conteneurs
Les applications sont conditionnées sous forme d'images de conteneurs, généralement des images Docker. Les images de conteneurs sont stockées et extraites d'un registre de conteneurs et instanciées en tant que conteneurs d'exécution à l'intérieur de pods. La sécurité doit être un principe de conception dès le début du processus de développement, lorsque vous travaillez sur le code source et les bibliothèques pour créer des images de conteneurs pour vos applications.
Mettez en œuvre des pratiques de sécurité dans votre chaîne d'outils CI/CD et pendant tout le processus de construction, de stockage et de déploiement des images de conteneur. Ces pratiques comprennent le stockage sécurisé des images de conteneurs, l'analyse de ces images pour détecter les vulnérabilités de sécurité et la gestion de la sécurité d'exécution des conteneurs. Dans le cadre de votre cycle DevSecOps, il est judicieux d'automatiser l'analyse des vulnérabilités des bibliothèques tierces que vous pouvez utiliser pour construire des applications. Vous pouvez également vous tourner vers des solutions comme Sonarqube,NeuVector, Deepfence, Aqua Security et Prisma Cloud Security. Vous pouvez également trouver des capacités natives d'analyse, de signature et de vérification des images de conteneurs dans le cadre de la plateforme.
Lorsque vous créez des images Docker et des conteneurs, utilisez des images d'OS épurés & renforcées (alpine) et assurez-vous que les utilisateurs qui exécutent l'application ont le niveau le plus bas de privilèges d'OS nécessaires pour exécuter les processus à l'intérieur du conteneur. Une autre chose importante à retenir est d'appliquer régulièrement des mises à jour de sécurité sur l'image source, puis de les redéployer en tant que conteneurs mis à jour. Il est également important d'utiliser des registres Docker privés comme Gitlab Registry, par exemple, avec un contrôle d'accès et des politiques appropriés en place, ainsi qu'une gouvernance pour la gestion des images de conteneurs. Il est suggéré de signer les images de conteneurs et de maintenir un système de confiance pour le contenu des conteneurs.
6. L'audit, la journalisation et la surveillance sont essentiels
L'audit, la journalisation et la surveillance sont des aspects importants de la sécurité qui peuvent contribuer à améliorer la position de sécurité de votre cluster et ne doivent pas être négligés. Les journaux d'audit Kubernetes sont des descriptions détaillées de chaque appel effectué au serveur API Kubernetes. Ces journaux d'audit fournissent des informations utiles sur ce qui se passe dans un cluster et peuvent même être utilisés pour l'audit, la conformité et l'analyse de la sécurité. Les enregistrements d'audit Kubernetes comprennent des enregistrements de sécurité qui capturent la séquence complète des activités et peuvent aider à détecter les comportements anormaux et l'accès aux ressources sensibles.
Il est recommandé d'activer la journalisation des audits et d'enregistrer les journaux d'audit sur un référentiel sécurisé pour les analyser en cas de compromission. Kubernetes fournit également une journalisation basée sur le cluster pour enregistrer l'activité des conteneurs dans un sous-système de journalisation central. La sortie standard et la sortie d'erreur standard de chaque conteneur dans un cluster Kubernetes peuvent être ingérées à l'aide d'un agent comme Fluentd exécuté sur chaque nœud dans des outils comme Elasticsearch et visualisées avec Kibana. Enfin, surveillez les conteneurs, les pods, les applications, les services et les autres composants de votre cluster à l'aide d'outils tels que Prometheus, Grafana ou Jaeger pour la surveillance, la visibilité et le traçage du cluster.
Une bonne référence pour en apprendre davantage sur ce sujet est le livre "Kubernetes Security" de "Brendan Creane & Amit Gupta " que je vous conseille vivement:
