Sécurité Kubernetes : problèmes courants et bonnes pratiques

Pourquoi la sécurité Kubernetes est-elle importante ?

La sécurité Kubernetes est importante en raison de la diversité des menaces auxquelles sont exposés les clusters et les pods, notamment :

• Les acteurs malveillants

• Les logiciels malveillants exécutés dans les conteneurs

• Les images de conteneur défectueuses

• Les utilisateurs compromis ou malveillants

Sans contrôles adaptés, un acteur malveillant qui parvient à compromettre une application peut tenter de prendre le contrôle de l’hôte ou de l’ensemble du cluster.

Quelle est la place de Kubernetes dans le processus global de développement ?

Le schéma ci-dessous montre la place de la sécurité Kubernetes dans le cycle de vie du développement logiciel (SDLC). Le code est testé après l’étape de build afin de s’assurer qu’aucune vulnérabilité n’atteigne l’environnement Kubernetes de production. Le déploiement et la sécurité de l’infrastructure cloud surveillent ensuite les applications en cours d’exécution et transmettent leurs observations aux développeurs, créant ainsi une boucle de rétroaction positive du code au cloud, puis du cloud au code.

La sécurité de Kubernetes dans le cycle de développement

Principaux enjeux de sécurité Kubernetes

Parmi les nombreux enjeux de sécurité Kubernetes, les trois plus importants à prendre en compte sont les suivants :

1. Configuration des contrôles de sécurité Kubernetes : lorsque vous déployez vous-même Kubernetes à partir de la version open source, aucun contrôle de sécurité n’est configuré par défaut. Il revient entièrement à l’opérateur de comprendre leur fonctionnement et de savoir les configurer de manière sécurisée.

2. Déploiement sécurisé des workloads : que vous utilisiez une distribution Kubernetes avec des contrôles de sécurité préconfigurés ou que vous créiez vous-même un cluster et ses mécanismes de sécurité, les développeurs et les équipes applicatives qui ne connaissent pas bien les rouages de Kubernetes peuvent avoir du mal à sécuriser correctement leurs workloads.

3. Absence de sécurité intégrée : Kubernetes propose des contrôles d’accès et des fonctionnalités permettant de créer un cluster sécurisé, mais sa configuration par défaut n’est pas totalement sécurisée. Les entreprises doivent modifier correctement la configuration des workloads, du cluster, du réseau et de l’infrastructure pour garantir la sécurité complète des clusters Kubernetes et des conteneurs.

Défis et solutions en matière de sécurité Kubernetes

Les solutions de sécurité intégrées à Kubernetes ne couvrent pas tous les problèmes potentiels, mais l’écosystème Kubernetes regorge de solutions de sécurité.

Certains domaines complexes de Kubernetes nécessitent des outils de sécurité supplémentaires, notamment :

1. Sécurité des workloads : la majorité des workloads Kubernetes sont des conteneurs exécutés par des moteurs tels que containerd, cri-o ou Docker. Le code et les autres packages présents dans ces conteneurs doivent être exempts de vulnérabilités.

2. Configuration des workloads : que vous utilisiez des manifestes Kubernetes, des graphiques Helm ou des outils de templating, la configuration nécessaire au déploiement de vos applications dans Kubernetes est généralement définie dans du code. Ce code influe sur les contrôles de sécurité Kubernetes, qui déterminent comment un workload s’exécute et ce qui peut ou non se produire en cas de compromission. Par exemple, limiter le processeur, la mémoire et le réseau de chaque workload à l’utilisation maximale prévue permet de circonscrire une compromission au seul workload touché et d’éviter que d’autres services ne soient compromis.

3. Configuration du cluster : il existe plusieurs outils d’évaluation de la sécurité Kubernetes pour vos clusters en cours d’exécution, tels que Sysdig, Falco et Prometheus. Ces outils s’appuient notamment sur les journaux d’audit et d’autres métriques Kubernetes intégrées pour vérifier le respect des bonnes pratiques de sécurité Kubernetes, ainsi que des référentiels CIS et autres benchmarks de sécurité pertinents.

4. Réseau Kubernetes : la sécurisation du réseau joue un rôle majeur dans Kubernetes. Les communications entre pods, le trafic entrant et sortant, la découverte de services et, si nécessaire, les maillages de services (par exemple Istio) doivent tous être pris en compte. Lorsqu’un cluster est compromis, tous les services et toutes les machines du réseau sont en danger. Il est donc essentiel de veiller à ce que vos services et leurs communications soient limités au strict nécessaire. Le recours à la cryptographie pour préserver la confidentialité de vos machines et services peut également contribuer à circonscrire la menace et à éviter une compromission de grande ampleur touchant l’ensemble du réseau.

5. Sécurité de l’infrastructure : une application distribuée s’exécute sur de nombreux serveurs, avec des réseaux et du stockage physiques ou virtuels. Il est donc essentiel de sécuriser votre infrastructure Kubernetes, en particulier les nœuds maîtres, les bases de données et les certificats. Si un acteur malveillant parvient à compromettre votre infrastructure, il pourrait également accéder à tout ce qui lui permettrait d’accéder à votre cluster et à vos applications.

Chacun de ces défis peut être relevé à l’aide des outils de sécurité disponibles dans l’écosystème Kubernetes. Le partenariat entre Snyk et Sysdig rapproche les développeurs et les équipes SecOps en proposant des outils conçus pour les développeurs, couvrant tous les aspects de la sécurité Kubernetes, du conteneur au cluster. Snyk propose des outils de sécurité centrés sur les développeurs, qui interviennent tout au long du SDLC, tels que Snyk Container et Snyk Open Source. En combinant ces workflows conçus pour les développeurs à Sysdig, nous pouvons transmettre aux développeurs, dans leurs workflows habituels, les informations issues de l’intelligence d’exécution de Sysdig (qui utilise les journaux d’audit pour surveiller les environnements Kubernetes). Ce partenariat donne naissance à la première plateforme de gestion de la posture de sécurité cloud conçue pour les développeurs.

Résultat de l’analyse de la configuration des workloads Kubernetes par Snyk

Sécurisation des hôtes Kubernetes

L’hôte cloud constitue la dernière couche d’un environnement Kubernetes. Les principaux fournisseurs cloud proposent des outils de gestion des ressources Kubernetes, notamment Google Kubernetes Engine (GKE), Azure Kubernetes Service (AKS) et Elastic Kubernetes Service (EKS) d’Amazon. Toutefois, la sécurité reste régie par un modèle de responsabilité partagée.

Il existe plusieurs façons de protéger les hôtes Kubernetes contre les vulnérabilités :

• Sécurisez la couche des workloads : assurez-vous que les images de conteneur sont exemptes de vulnérabilités et correctement configurées (par exemple, en interdisant les conteneurs privilégiés).

• Établissez des barrières entre les workloads et les hôtes : limitez l’accès aux ressources de l’hôte en réduisant les privilèges des conteneurs et en configurant l’environnement d’exécution pour restreindre l’utilisation des ressources en cas de compromission.

• Surveillez les clusters en cours d’exécution : surveillez les journaux d’audit afin de détecter les erreurs de configuration ou les comportements suspects.

Paramètres de contexte de sécurité Kubernetes à mettre en œuvre

Pour empêcher les pods et les clusters d’accéder au reste du système Kubernetes, vous pouvez utiliser les securityContexts. Voici dix principaux paramètres de contexte de sécurité que chaque pod et conteneur devrait utiliser :

1. runAsNonRoot : définir cette valeur sur « true » empêche les conteneurs de s’exécuter en tant qu’utilisateur root.

2. runAsUser / runAsGroup : ces paramètres garantissent que les conteneurs utilisent un utilisateur et un groupe d’exécution spécifiés.

3. seLinuxOptions : définit le contexte SELinux du conteneur ou du pod.

4. seccompProfile : permet de définir le profil seccomp sur le noyau Linux afin de restreindre les opérations des conteneurs.

5. privileged / allowPrivilegeEscalation : il est généralement déconseillé d’autoriser les conteneurs privilégiés ou les processus qu’ils contiennent à élever leurs privilèges. Ces paramètres doivent donc être définis sur false.

6. capabilities : permet de contrôler l’accès aux appels système du noyau. N’accordez que les droits minimum nécessaires.

7. readonlyRootFilesystem : définissez ce paramètre sur true lorsque c’est possible. Cela empêche les attaquants d’installer des logiciels ou de modifier les configurations du système de fichiers.

8. procMount : utilisez le paramètre « Default », sauf dans des situations particulières, comme les conteneurs imbriqués.

9. fsGroup / fsGroupChangePolicy : utilisez ce paramètre avec précaution, car modifier la propriété d’un volume avec fsGroup peut ralentir le démarrage des pods et avoir des effets négatifs sur les systèmes de fichiers partagés.

10. sysctls : évitez de modifier les paramètres du noyau à l’aide de sysctls, sauf si vos besoins sont très spécifiques, car cela pourrait déstabiliser le système hôte.

Play Video: Kubernetes security with Snyk

Observabilité de la sécurité Kubernetes

Pour sécuriser K8s, des configurations sûres vous aident à tirer parti des fonctionnalités de sécurité de Kubernetes. Il est également important de mettre en place des processus de surveillance efficaces pour garder une bonne visibilité sur les ressources Kubernetes. Voici quelques conseils pour la surveillance de Kubernetes :

• Utilisez des tags et des labels : ils définissent les applications à l’aide de métadonnées afin d’en simplifier la gestion.

• Surveillez l’ensemble des conteneurs, et non des conteneurs individuels : Kubernetes gère des pods, et non des conteneurs. Il est donc important d’effectuer la surveillance au niveau des pods.

• Utilisez la découverte de services : elle vous aide à surveiller les services Kubernetes malgré leur nature volatile.

• Tirez parti des alertes : vous pouvez configurer des alertes en fonction des critères qui définissent un environnement Kubernetes sain. Attention toutefois à la multiplication des alertes : les systèmes distribués peuvent comporter de nombreux points de surveillance potentiels.

• Inspectez le plan de contrôle :Le plan de contrôle Kubernetes joue le rôle de tour de contrôle aérien pour les workloads et les clusters. L’inspection de chacun de ses composants contribue à garantir une orchestration et une planification efficaces des tâches.

Bonnes pratiques de sécurité Kubernetes à chaque étape

Voici quelques bonnes pratiques de sécurité Kubernetes à appliquer à chaque étape :

Phase de développement et de conception

• Certains environnements Kubernetes peuvent être plus sécurisés que d’autres. Une architecture multicluster ou plusieurs espaces de noms dotés de contrôles RBAC adaptés peuvent contribuer à isoler les workloads.

Phase de build

• Choisissez une image minimale provenant d’un dépôt vérifié.

• Utilisez des outils d’analyse de conteneurs pour détecter les vulnérabilités et les erreurs de configuration dans les conteneurs.

Phase de déploiement

• Les images doivent être analysées et validées avant le déploiement.

• Un contrôleur d’admission peut automatiser cette validation afin que seules les images de conteneur vérifiées soient déployées.

Phase d’exécution

• L’environnement d’exécution constitue la dernière ligne de défense des ressources Kubernetes.

• L’API Kubernetes génère des journaux d’audit qui doivent être surveillés à l’aide d’un outil de sécurité de l’exécution, tel que Sysdig.

• Les images et les fichiers de politiques doivent également être analysés en continu afin d’éviter les logiciels malveillants et les erreurs de configuration dans l’environnement d’exécution.

Utiliser Snyk pour sécuriser Kubernetes

Snyk vous aide à améliorer et à maintenir votre posture de sécurité Kubernetes grâce à ses outils conçus pour les développeurs, notamment Snyk Container et Snyk IaC. Snyk automatise l’analyse du code applicatif, des images de conteneur et des configurations Kubernetes, puis fournit aux développeurs des informations et des recommandations directement dans leurs workflows.

« Un produit comme Snyk nous aide à repérer les parties de nos services qui sont potentiellement exposées aux menaces d’acteurs externes », explique Rizzo. … « Depuis que Snyk fait partie de notre pipeline CI/CD, les contrôles de sécurité sont toujours effectués plus tôt dans le développement. »

Ciro Rizzo - Responsable de l’ingénierie - The Telegraph

Notre partenariat avec Sysdig étend nos capacités de sécurité à l’environnement d’exécution.

FAQ sur la sécurité Kubernetes