CIS 1.23 : Guide d’auto-évaluation

Le fichier de spécification du pod du serveur API contrôle divers paramètres qui définissent le comportement du serveur API. Vous devez restreindre ses permissions de fichier pour maintenir l’intégrité du fichier. Le fichier ne doit être modifiable que par les administrateurs du système.

Le fichier de spécification du pod du serveur API contrôle divers paramètres qui définissent le comportement du serveur API. Vous devez définir sa propriété de fichier pour maintenir l’intégrité du fichier. Le fichier doit appartenir à root:root.

Le fichier de spécification du pod du gestionnaire de contrôleur contrôle divers paramètres qui définissent le comportement du gestionnaire de contrôleur sur le nœud maître. Vous devez restreindre ses permissions de fichier pour maintenir l’intégrité du fichier. Le fichier ne doit être modifiable que par les administrateurs du système.

Le fichier de spécification du pod du gestionnaire de contrôleur contrôle divers paramètres qui définissent le comportement de divers composants du nœud maître. Vous devez définir sa propriété de fichier pour maintenir l’intégrité du fichier. Le fichier doit appartenir à root:root.

Le fichier de spécification du pod du planificateur contrôle divers paramètres qui définissent le comportement du service de planification dans le nœud maître. Vous devez restreindre ses permissions de fichier pour maintenir l’intégrité du fichier. Le fichier ne doit être modifiable que par les administrateurs du système.

Le fichier de spécification du pod du planificateur contrôle divers paramètres qui définissent le comportement du service kube-scheduler dans le nœud maître. Vous devez définir sa propriété de fichier pour maintenir l’intégrité du fichier. Le fichier doit appartenir à root:root.

Le fichier de spécification du pod etcd /var/lib/rancher/rke2/agent/pod-manifests/etcd.yaml contrôle divers paramètres qui définissent le comportement du service etcd dans le nœud maître. etcd est un magasin de valeurs clé hautement disponible que Kubernetes utilise pour le stockage persistant de tous ses objets d’API REST. Vous devez restreindre ses permissions de fichier pour maintenir l’intégrité du fichier. Le fichier ne doit être modifiable que par les administrateurs du système.

Le fichier de spécification du pod etcd /var/lib/rancher/rke2/agent/pod-manifests/etcd.yaml contrôle divers paramètres qui définissent le comportement du service etcd dans le nœud maître. etcd est un magasin de valeurs clé hautement disponible que Kubernetes utilise pour le stockage persistant de tous ses objets d’API REST. Vous devez définir sa propriété de fichier pour maintenir l’intégrité du fichier. Le fichier doit appartenir à root:root.

L’interface réseau du conteneur offre diverses options pour les réseaux superposés. Vous devez consulter leur documentation et restreindre les autorisations de fichier respectives pour maintenir l’intégrité de ces fichiers. Ces fichiers ne doivent être modifiables que par les administrateurs du système.

L’interface réseau du conteneur offre diverses options pour les réseaux superposés. Vous devez consulter leur documentation et restreindre les autorisations de fichier respectives pour maintenir l’intégrité de ces fichiers. Ces fichiers doivent appartenir à root:root.

etcd est un magasin de valeurs-clés hautement disponible utilisé par les déploiements Kubernetes pour le stockage persistant de tous ses objets API REST. Ce répertoire de données doit être protégé contre toute lecture ou écriture non autorisée. Il ne doit pas être lisible ou modifiable par des membres de groupe ou le grand public.

etcd est un magasin de valeurs-clés hautement disponible utilisé par les déploiements Kubernetes pour le stockage persistant de tous ses objets API REST. Ce répertoire de données doit être protégé contre toute lecture ou écriture non autorisée. Il doit appartenir à etcd:etcd.

Le fichier admin.conf est le fichier kubeconfig de l’administrateur définissant divers paramètres pour l’administration du cluster. Vous devez restreindre ses permissions de fichier pour maintenir l’intégrité du fichier. Le fichier ne doit être modifiable que par les administrateurs du système.

Dans RKE2, ce fichier se trouve à /var/lib/rancher/rke2/server/cred/admin.kubeconfig.

Le fichier admin.conf contient les identifiants administratifs pour le cluster. Vous devez définir sa propriété de fichier pour maintenir l’intégrité du fichier. Le fichier doit appartenir à root:root.

Dans RKE2, ce fichier se trouve à /var/lib/rancher/rke2/server/cred/admin.kubeconfig.

Le fichier scheduler.conf est le fichier kubeconfig pour le Scheduler. Vous devez restreindre ses permissions de fichier pour maintenir l’intégrité du fichier. Le fichier ne doit être modifiable que par les administrateurs du système.

Dans RKE2, ce fichier se trouve à /var/lib/rancher/rke2/server/cred/scheduler.kubeconfig.

Le fichier scheduler.conf est le fichier kubeconfig pour le Scheduler. Vous devez définir sa propriété de fichier pour maintenir l’intégrité du fichier. Le fichier doit appartenir à root:root.

Dans RKE2, ce fichier se trouve à /var/lib/rancher/rke2/server/cred/scheduler.kubeconfig.

Le fichier controller.kubeconfig est le fichier kubeconfig pour le Scheduler. Vous devez restreindre ses permissions de fichier pour maintenir l’intégrité du fichier. Le fichier ne doit être modifiable que par les administrateurs du système.

Dans RKE2, ce fichier se trouve à /var/lib/rancher/rke2/server/cred/controller.kubeconfig.

Le fichier controller.kubeconfig est le fichier kubeconfig pour le Scheduler. Vous devez définir sa propriété de fichier pour maintenir l’intégrité du fichier. Le fichier doit appartenir à root:root.

Dans RKE2, ce fichier se trouve à /var/lib/rancher/rke2/server/cred/controller.kubeconfig.

Kubernetes utilise un certain nombre de certificats dans le cadre de son fonctionnement. Vous devez définir la propriété du répertoire contenant les informations de l’infrastructure de clés publiques ainsi que celle de tous les fichiers qu’il contient pour maintenir leur intégrité. Le répertoire et les fichiers doivent être possédés par root:root.

Kubernetes utilise un certain nombre de fichiers de certificat dans le cadre du fonctionnement de ses composants. Les permissions sur ces fichiers doivent être définies sur 644 ou plus restrictives pour protéger leur intégrité.

Kubernetes utilise un certain nombre de fichiers clés dans le cadre du fonctionnement de ses composants. Les permissions sur ces fichiers doivent être définies sur 600 pour protéger leur intégrité et leur confidentialité.

Lorsqu’il est activé, les requêtes qui ne sont pas rejetées par d’autres méthodes d’authentification configurées sont traitées comme des requêtes anonymes. Ces requêtes sont ensuite servies par le serveur API. Vous devez vous fier à l’authentification pour autoriser l’accès et interdire les requêtes anonymes.

Si vous utilisez l’autorisation RBAC, il est généralement considéré comme raisonnable de permettre l’accès anonyme au serveur API pour les vérifications de santé et les objectifs de découverte, et donc cette recommandation est manuelle. Cependant, vous devez considérer si la découverte anonyme représente un risque acceptable pour vos objectifs.

L’authentification basée sur des tokens utilise des tokens statiques pour authentifier les requêtes au serveur API. Les tokens sont stockés en texte clair dans un fichier sur le serveur API et ne peuvent pas être révoqués ou renouvelés sans redémarrer le serveur API. Par conséquent, n’utilisez pas l’authentification basée sur des tokens statiques.

Ce contrôleur d’admission rejette toute nouvelle utilisation du champ Service externalIPs. Cette fonctionnalité est très puissante (permet l’interception du trafic réseau) et n’est pas bien contrôlée par la stratégie. Lorsqu’elle est activée, les utilisateurs du cluster ne peuvent pas créer de nouveaux Services utilisant des externalIPs et ne peuvent pas ajouter de nouvelles valeurs aux externalIPs sur les objets Service existants. Les utilisations existantes des externalIPs ne sont pas affectées, et les utilisateurs peuvent supprimer des valeurs des externalIPs sur les objets Service existants.

La plupart des utilisateurs n’ont pas du tout besoin de cette fonctionnalité, et les administrateurs de cluster devraient envisager de la désactiver. Les clusters qui ont besoin d’utiliser cette fonctionnalité devraient envisager d’utiliser une stratégie personnalisée pour gérer son utilisation.

Les connexions de l’apiserver aux kubelets pourraient potentiellement transporter des données sensibles telles que des secrets et des clés. Il est donc important d’utiliser le chiffrement en transit pour toute communication entre l’apiserver et les kubelets.

L’apiserver, par défaut, ne s’authentifie pas auprès des points de terminaison HTTPS du kubelet. Les requêtes de l’apiserver sont traitées de manière anonyme. Vous devriez configurer l’authentification kubelet basée sur des certificats pour garantir que l’apiserver s’authentifie auprès des kubelets lors de l’envoi de requêtes.

Les connexions de l’apiserver au kubelet sont utilisées pour récupérer les journaux des pods, se connecter (via kubectl) aux pods en cours d’exécution et utiliser la fonctionnalité de transfert de port du kubelet. Ces connexions se terminent au point de terminaison HTTPS du kubelet. Par défaut, l’apiserver ne vérifie pas le certificat de service du kubelet, ce qui rend la connexion sujette aux attaques de type homme du milieu et dangereuse à exécuter sur des réseaux non fiables et/ou publics.

Le serveur API peut être configuré pour autoriser toutes les requêtes. Ce mode ne doit pas être utilisé sur un cluster de production.

Le mode d’autorisation des nœuds ne permet aux kubelets de lire que les objets Secret, ConfigMap, PersistentVolume et PersistentVolumeClaim associés à leurs nœuds.

Le contrôle d’accès en fonction du rôle (RBAC) permet un contrôle granulaire sur les opérations que différentes entités peuvent effectuer sur différents objets dans le cluster. Il est recommandé d’utiliser le mode d’autorisation RBAC.

L’utilisation du contrôle d’admission EventRateLimit impose une limite sur le nombre d’événements que le serveur API acceptera dans une tranche horaire donnée. Une charge de travail malveillante pourrait submerger et provoquer un déni de service du serveur API, le rendant indisponible. Cela s’applique particulièrement à un cluster multi-locataire, où il pourrait y avoir un petit pourcentage de locataires malveillants ayant un impact significatif sur la performance globale du cluster. Par conséquent, il est recommandé de limiter le taux d’événements que le serveur API acceptera.

Définir le plug-in de contrôle d’admission AlwaysAdmit permet toutes les demandes et ne filtre aucune demande.

Le contrôleur d’admission AlwaysAdmit n’est plus pris en charge depuis Kubernetes v1.13. Son comportement était équivalent à désactiver tous les contrôleurs d’admission.

Définir la stratégie de contrôle d’admission sur AlwaysPullImages oblige chaque nouveau pod à tirer les images requises à chaque fois. Dans un cluster multi-locataire, les utilisateurs peuvent être assurés que leurs images privées ne peuvent être utilisées que par ceux qui ont les identifiants pour les tirer. Sans cette politique de contrôle d’admission, une fois qu’une image a été tirée sur un nœud, n’importe quel pod d’un utilisateur peut l’utiliser simplement en connaissant le nom de l’image, sans aucune vérification d’autorisation concernant la propriété de l’image. Lorsque ce plug-in est activé, les images sont toujours tirées avant de démarrer les conteneurs, ce qui signifie que des identifiants valides sont requis.

SecurityContextDeny peut être utilisé pour fournir une couche de sécurité pour les clusters qui n’ont pas de PodSecurityPolicies activées.

Lorsque vous créez un pod, si vous ne spécifiez pas de compte de service, il se voit automatiquement attribuer le compte de service default dans le même espace de noms. Vous devez créer votre propre compte de service et laisser le serveur API gérer ses jetons de sécurité.

Définir la stratégie de contrôle d’admission sur NamespaceLifecycle garantit que les objets ne peuvent pas être créés dans des espaces de noms inexistants et que les espaces de noms en cours de terminaison ne sont pas utilisés pour créer de nouveaux objets. Cela est recommandé pour garantir l’intégrité du processus de terminaison des espaces de noms et également pour la disponibilité des nouveaux objets.

L’utilisation du plug-in NodeRestriction garantit que le kubelet est restreint aux objets Node et Pod qu’il peut modifier comme défini. Ces kubelets ne seront autorisés à modifier que leur propre objet API Node et à modifier uniquement les objets API Pod qui sont liés à leur nœud.

Le port sécurisé est utilisé pour servir https avec authentification et autorisation. Si vous le désactivez, aucun trafic https n’est servi et tout le trafic est servi sans cryptage.

Le profilage permet d’identifier des goulets d’étranglement de performance spécifiques. Il génère une quantité significative de données de programme qui pourraient potentiellement être exploitées pour découvrir des détails sur le système et le programme. Si vous ne rencontrez aucun goulet d’étranglement et n’avez pas besoin du profileur à des fins de dépannage, il est recommandé de le désactiver pour réduire la surface d’attaque potentielle.

L’audit du serveur API Kubernetes fournit un ensemble chronologique d’enregistrements pertinents pour la sécurité, documentant la séquence d’activités qui ont affecté le système par des utilisateurs individuels, des administrateurs ou d’autres composants du système. Bien que Kubernetes ne fournisse actuellement que des capacités d’audit de base, il devrait être activé. Vous pouvez l’activer en définissant le chemin du journal d’audit approprié.

Conserver les journaux pendant au moins 30 jours garantit que vous pouvez revenir en arrière et enquêter ou corréler des événements. Définissez votre période de conservation des journaux d’audit à 30 jours ou selon vos besoins commerciaux.

Kubernetes fait automatiquement la rotation des fichiers journaux. Conserver les anciens fichiers journaux garantit que vous disposerez de suffisamment de données pour effectuer toute enquête ou corrélation. Par exemple, si vous avez défini une taille de fichier de 100 Mo et le nombre d’anciens fichiers journaux à conserver à 10, vous disposeriez d’environ 1 Go de données de fichiers journaux que vous pourriez potentiellement utiliser pour votre analyse.

Kubernetes fait automatiquement la rotation des fichiers journaux. Conserver les anciens fichiers journaux garantit que vous disposerez de suffisamment de données de journaux pour mener toute enquête ou corrélation. Si vous avez défini une taille de fichier de 100 Mo et le nombre d’anciens fichiers journaux à conserver à 10, vous disposeriez d’environ 1 Go de données de fichiers journaux que vous pourriez potentiellement utiliser pour votre analyse.

Définir un délai d’attente global pour les requêtes permet d’étendre la limite de délai d’attente des requêtes du serveur API à une durée appropriée à la vitesse de connexion de l’utilisateur. Par défaut, il est défini sur 60 secondes, ce qui peut poser problème sur des connexions plus lentes, rendant les ressources du cluster inaccessibles une fois que le volume de données pour les requêtes dépasse ce qui peut être transmis en 60 secondes. Cependant, définir cette limite de délai d’attente trop élevée peut épuiser les ressources du serveur API, le rendant vulnérable aux attaques par déni de service. Par conséquent, il est recommandé de définir cette limite selon ce qui est approprié et de ne changer la limite par défaut de 60 secondes que si nécessaire.

Si --service-account-lookup n’est pas activé, l’apiserver vérifie uniquement que le jeton d’authentification est valide et ne valide pas que le jeton de compte de service mentionné dans la requête est effectivement présent dans etcd. Cela permet d’utiliser un jeton de compte de service même après la suppression du compte de service correspondant. Ceci est un exemple de problème de sécurité lié au temps de vérification et au temps d’utilisation.

Par défaut, si aucun --service-account-key-file n’est spécifié à l’apiserver, il utilise la clé privée du certificat TLS de service pour vérifier les jetons de compte de service. Pour garantir que les clés des jetons de compte de service peuvent être tournées si nécessaire, une paire de clés publique/privée distincte doit être utilisée pour signer les jetons de compte de service. Par conséquent, la clé publique doit être spécifiée à l’apiserver avec --service-account-key-file.

etcd est un magasin de valeurs clés hautement disponible utilisé par les déploiements Kubernetes pour le stockage persistant de tous ses objets API REST. Ces objets sont sensibles par nature et doivent être protégés par une authentification client. Cela nécessite que le serveur API s’identifie auprès du serveur etcd à l’aide d’un certificat et d’une clé client.

La communication du serveur API contient des paramètres sensibles qui doivent rester chiffrés en transit. Configurez le serveur API pour ne servir que le trafic HTTPS.

La communication du serveur API contient des paramètres sensibles qui doivent rester chiffrés en transit. Configurez le serveur API pour ne servir que le trafic HTTPS. Si l’argument --client-ca-file est défini, toute demande présentant un certificat client signé par l’une des autorités dans le client-ca-file est authentifiée avec une identité correspondant au CommonName du certificat client.

etcd est un magasin de valeurs clés hautement disponible utilisé par les déploiements Kubernetes pour le stockage persistant de tous ses objets API REST. Ces objets sont sensibles par nature et doivent être protégés par une authentification client. Cela nécessite que le serveur API s’identifie auprès du serveur etcd en utilisant un fichier d’autorité de certification SSL.

etcd est un magasin de valeurs clés hautement disponible utilisé par les déploiements Kubernetes pour le stockage persistant de tous ses objets API REST. Ces objets sont sensibles par nature et doivent être chiffrés au repos pour éviter toute divulgation.

Lorsque le chiffrement etcd est utilisé, il est important de s’assurer que l’ensemble approprié de fournisseurs de chiffrement est utilisé. Actuellement, les aescbc, kms et secretbox sont susceptibles d’être des options appropriées.

Les chiffrements TLS ont connu un certain nombre de vulnérabilités et de faiblesses connues, ce qui peut réduire la protection qu’ils offrent. Par défaut, Kubernetes prend en charge un certain nombre de suites de chiffrement TLS, y compris certaines qui présentent des problèmes de sécurité, affaiblissant la protection fournie.

La collecte des déchets est importante pour garantir une disponibilité suffisante des ressources et éviter une dégradation des performances et de la disponibilité. Dans le pire des cas, le système pourrait cesser de fonctionner ou devenir inutilisable pendant une longue période. Le paramètre actuel pour la collecte des déchets est fixé à 12 500 pods terminés, ce qui pourrait être trop élevé pour que votre système le supporte. En fonction de vos ressources système et des tests, choisissez une valeur de seuil appropriée pour activer la collecte des déchets.

Le profilage permet d’identifier des goulets d’étranglement de performance spécifiques. Il génère une quantité significative de données de programme qui pourraient potentiellement être exploitées pour découvrir des détails sur le système et le programme. Si vous ne rencontrez aucun goulet d’étranglement et n’avez pas besoin du profileur à des fins de dépannage, il est recommandé de le désactiver pour réduire la surface d’attaque potentielle.

Le gestionnaire de contrôleur crée un compte de service par contrôleur dans l’espace de noms kube-system, génère un identifiant pour celui-ci et construit un client API dédié avec cet identifiant de compte de service pour chaque boucle de contrôleur à utiliser. Définir le --use-service-account-credentials sur true exécute chaque boucle de contrôle au sein du gestionnaire de contrôleur en utilisant un identifiant de compte de service séparé. Lorsqu’il est utilisé en combinaison avec RBAC, cela garantit que les boucles de contrôle s’exécutent avec les autorisations minimales requises pour effectuer leurs tâches prévues.

Pour garantir que les clés pour les jetons de compte de service peuvent être tournées au besoin, une paire de clés publique/privée distincte doit être utilisée pour signer les jetons de compte de service. La clé privée doit être spécifiée au gestionnaire de contrôleur avec --service-account-private-key-file comme approprié.

Les processus s’exécutant dans des pods qui doivent contacter le serveur API doivent vérifier le certificat de service du serveur API. Le fait de ne pas le faire pourrait être sujet à des attaques de type homme du milieu.

Fournir le certificat racine pour le certificat de service du serveur API au gestionnaire de contrôleur avec l’argument --root-ca-file permet au gestionnaire de contrôleur d’injecter le bundle de confiance dans les pods afin qu’ils puissent vérifier les connexions TLS au serveur API.

RotateKubeletServerCertificate amène le kubelet à demander un certificat de service après avoir démarré ses informations d’identification client et à faire tourner le certificat à mesure que ses informations d’identification existantes expirent. Cette rotation périodique automatisée garantit qu’il n’y a pas de temps d’arrêt dus à des certificats expirés et aborde ainsi la disponibilité dans la triade de sécurité CIA.

Le service API du gestionnaire de contrôleur qui fonctionne sur le port 10252/TCP par défaut est utilisé pour les informations de santé et de métriques et est disponible sans authentification ni chiffrement. En tant que tel, il ne devrait être lié qu’à une interface hôte local, afin de minimiser la surface d’attaque du cluster.

Le profilage permet d’identifier des goulets d’étranglement de performance spécifiques. Il génère une quantité significative de données de programme qui pourraient potentiellement être exploitées pour découvrir des détails sur le système et le programme. Si vous ne rencontrez aucun goulet d’étranglement et n’avez pas besoin du profileur à des fins de dépannage, il est recommandé de le désactiver pour réduire la surface d’attaque potentielle.

Le service API du planificateur qui fonctionne sur le port 10251/TCP par défaut est utilisé pour les informations de santé et de métriques et est disponible sans authentification ni cryptage. En tant que tel, il ne devrait être lié qu’à une interface hôte local, afin de minimiser la surface d’attaque du cluster.

Avec tout mécanisme d’authentification, la capacité de révoquer des identifiants s’ils sont compromis ou ne sont plus nécessaires est un contrôle clé. L’authentification par certificat client Kubernetes ne permet pas cela en raison d’un manque de support pour la révocation des certificats.

La journalisation est un contrôle détecteur important pour tous les systèmes, afin de détecter un accès non autorisé potentiel.

Les journaux d’audit de sécurité doivent couvrir l’accès et la modification des ressources clés dans le cluster, afin de leur permettre de faire partie intégrante d’un environnement de sécurité efficace.

Le fichier de service kubelet contrôle divers paramètres qui définissent le comportement du service kubelet dans le nœud de travail. Vous devez restreindre ses permissions de fichier pour maintenir l’intégrité du fichier. Le fichier ne doit être modifiable que par les administrateurs du système.

Le fichier de service kubelet contrôle divers paramètres qui définissent le comportement du service kubelet dans le nœud de travail. Vous devez définir sa propriété de fichier pour maintenir l’intégrité du fichier. Le fichier doit appartenir à root:root.

Le kube-proxy fichier kubeconfig contrôle divers paramètres du kube-proxy service dans le nœud de travail. Vous devez restreindre ses permissions de fichier pour maintenir l’intégrité du fichier. Le fichier ne doit être modifiable que par les administrateurs du système.

Il est possible d’exécuter kube-proxy avec les paramètres kubeconfig configurés en tant que ConfigMap Kubernetes au lieu d’un fichier. Dans ce cas, il n’y a pas de fichier kubeconfig proxy.

Le fichier kubeconfig pour kube-proxy contrôle divers paramètres pour le kube-proxy service dans le nœud de travail. Vous devez définir sa propriété de fichier pour maintenir l’intégrité du fichier. Le fichier doit appartenir à root:root.

Le fichier kubelet.conf est le fichier kubeconfig pour le nœud et contrôle divers paramètres qui définissent le comportement et l’identité du nœud de travail. Vous devez restreindre ses permissions de fichier pour maintenir l’intégrité du fichier. Le fichier ne doit être modifiable que par les administrateurs du système.

Le fichier kubelet.conf est le fichier kubeconfig pour le nœud et contrôle divers paramètres qui définissent le comportement et l’identité du nœud de travail. Vous devez définir sa propriété de fichier pour maintenir l’intégrité du fichier. Le fichier doit appartenir à root:root.

Le fichier des autorités de certification contrôle les autorités utilisées pour valider les requêtes API. Vous devez restreindre ses permissions de fichier pour maintenir l’intégrité du fichier. Le fichier ne doit être modifiable que par les administrateurs du système.

Le fichier des autorités de certification contrôle les autorités utilisées pour valider les requêtes API. Vous devez définir sa propriété de fichier pour maintenir l’intégrité du fichier. Le fichier doit appartenir à root:root.

Le kubelet lit divers paramètres, y compris les paramètres de sécurité, à partir d’un fichier de configuration spécifié par --config l’argument. Si ce fichier est spécifié, vous devez restreindre ses permissions de fichier pour maintenir l’intégrité du fichier. Le fichier ne doit être modifiable que par les administrateurs du système.

Le kubelet lit divers paramètres, y compris les paramètres de sécurité, à partir d’un fichier de configuration spécifié par --config l’argument. Si ce fichier est spécifié, vous devez restreindre ses permissions de fichier pour maintenir l’intégrité du fichier. Le fichier doit appartenir à root:root.

Lorsque activé, les requêtes qui ne sont pas rejetées par d’autres méthodes d’authentification configurées sont traitées comme des requêtes anonymes. Ces requêtes sont ensuite servies par le serveur Kubelet. Vous devez vous fier à l’authentification pour autoriser l’accès et interdire les requêtes anonymes.

Les Kubelets, par défaut, autorisent toutes les requêtes authentifiées (même anonymes) sans nécessiter de vérifications d’autorisation explicites de la part de l’apiserver. Vous devez restreindre ce comportement et n’autoriser que les requêtes explicitement autorisées.

Les connexions de l’apiserver au kubelet sont utilisées pour récupérer les journaux des pods, se connecter (via kubectl) aux pods en cours d’exécution et utiliser la fonctionnalité de redirection de port du kubelet. Ces connexions se terminent au point de terminaison HTTPS du kubelet. Par défaut, l’apiserver ne vérifie pas le certificat de service du kubelet, ce qui rend la connexion sujette à des attaques de type homme du milieu et dangereuse à exécuter sur des réseaux non fiables et/ou publics. L’activation de l’authentification par certificat Kubelet garantit que l’apiserver peut authentifier le Kubelet avant de soumettre des requêtes.

Le processus Kubelet fournit une API en lecture seule en plus de l’API principale Kubelet. Un accès non authentifié est fourni à cette API en lecture seule qui pourrait potentiellement récupérer des informations sensibles sur le cluster.

Définir des délais d’inactivité garantit que vous êtes protégé contre les attaques par déni de service, les connexions inactives et le manque de ports éphémères.

Les paramètres du noyau Linux sont généralement ajustés et durcis par les administrateurs système avant de mettre les systèmes en production. Ces paramètres protègent le noyau Linux et le système. Les valeurs par défaut de votre kubelet qui dépendent de tels paramètres doivent être correctement définies pour correspondre à l’état sécurisé souhaité du système. Ignorer cela pourrait potentiellement conduire à l’exécution de pods avec un comportement du noyau Linux indésirable.

Les kubelets peuvent gérer automatiquement les changements nécessaires aux iptables en fonction de la manière dont vous choisissez vos options de mise en réseau pour les pods. Il est recommandé de laisser les kubelets gérer les changements aux iptables. Cela garantit que la configuration des iptables reste synchronisée avec la configuration de mise en réseau des pods. Configurer manuellement les iptables avec des changements dynamiques de configuration des pods pourrait entraver la communication entre les pods/conteneurs et le monde extérieur. Vous pourriez avoir des règles iptables trop restrictives ou trop ouvertes.

Le remplacement des noms d’hôtes pourrait potentiellement perturber la configuration TLS entre le kubelet et l’apiserver. De plus, avec des noms d’hôtes remplacés, il devient de plus en plus difficile d’associer les journaux à un nœud particulier et de les traiter pour l’analyse de sécurité. Par conséquent, vous devez configurer vos nœuds kubelet avec des FQDN résolvables et éviter de remplacer les noms d’hôtes par des adresses IP.

Il est important de capturer tous les événements et de ne pas restreindre la création d’événements. Les événements sont une source importante d’informations et d’analyses de sécurité qui garantissent que votre environnement est constamment surveillé à l’aide des données d’événements.

La communication du kubelet contient des paramètres sensibles qui doivent rester chiffrés en transit. Configurez les Kubelets pour ne servir que le trafic HTTPS.

Le paramètre --rotate-certificates fait en sorte que le kubelet fasse tourner ses certificats clients en créant de nouvelles CSR à mesure que ses identifiants existants expirent. Cette rotation périodique automatisée garantit qu’il n’y a pas de temps d’arrêt dû à des certificats expirés, assurant ainsi la disponibilité dans la triade de sécurité CIA.

RotateKubeletServerCertificate amène le kubelet à demander un certificat de service après avoir initialisé ses identifiants clients et à faire tourner le certificat à mesure que ses identifiants existants expirent. Cette rotation périodique automatisée garantit qu’il n’y a pas de temps d’arrêt dû à des certificats expirés, assurant ainsi la disponibilité dans la triade de sécurité CIA.

Les chiffrements TLS ont eu un certain nombre de vulnérabilités et de faiblesses connues, ce qui peut réduire la protection qu’ils offrent. Par défaut, Kubernetes prend en charge un certain nombre de suites de chiffrement TLS, y compris certaines qui présentent des préoccupations de sécurité, affaiblissant ainsi la protection fournie.

Kubernetes fournit un ensemble de rôles par défaut où RBAC est utilisé. Certains de ces rôles, tels que cluster-admin, offrent des privilèges étendus qui ne devraient être appliqués que lorsque cela est absolument nécessaire. Des rôles tels que cluster-admin permettent un accès super-utilisateur pour effectuer toute action sur n’importe quelle ressource. Lorsqu’il est utilisé dans un ClusterRoleBinding, il donne un contrôle total sur chaque ressource dans le cluster et dans tous les espaces de noms. Lorsqu’il est utilisé dans un RoleBinding, il donne un contrôle total sur chaque ressource dans l’espace de noms du rôle, y compris l’espace de noms lui-même.

Un accès inapproprié aux secrets stockés dans le cluster Kubernetes peut permettre à un attaquant d’obtenir un accès supplémentaire au cluster Kubernetes ou à des ressources externes dont les identifiants sont stockés en tant que secrets.

Le principe du moindre privilège recommande que les utilisateurs ne reçoivent que l’accès nécessaire à leur rôle et rien de plus. L’utilisation de droits de caractères génériques est susceptible de fournir des droits excessifs à l’API Kubernetes.

La capacité de créer des pods dans un cluster ouvre des possibilités d’escalade de privilèges et doit être restreinte, si possible.

Kubernetes fournit un compte de service par défaut qui est utilisé par les charges de travail du cluster lorsque aucun compte de service spécifique n’est assigné au pod.

Lorsque l’accès à l’API Kubernetes depuis un pod est requis, un compte de service spécifique doit être créé pour ce pod, et des droits doivent être accordés à ce compte de service.

Le compte de service par défaut doit être configuré de manière à ne pas fournir de token de compte de service et ne doit avoir aucune attribution de droits explicite.

Monter des jetons de compte de service à l’intérieur des pods peut fournir une voie pour des attaques d’escalade de privilèges où un attaquant est capable de compromettre un seul pod dans le cluster.

Éviter de monter ces jetons supprime cette voie d’attaque.

Le groupe system:masters a un accès illimité à l’API Kubernetes codé en dur dans le code source du serveur API. Un utilisateur authentifié qui fait partie de ce groupe ne peut pas se voir diminuer ses droits, même si toutes les liaisons et toutes les liaisons de rôle de cluster qui le mentionnent sont supprimées.

Lorsqu’il est combiné avec l’authentification par certificat client, l’utilisation de ce groupe peut permettre l’existence de privilèges de niveau administrateur de cluster irrévocables pour un cluster.

Le privilège d’imitation permet à un sujet d’imiter d’autres utilisateurs en acquérant leurs droits sur le cluster. Le privilège de liaison permet au sujet d’ajouter une liaison à un rôle de cluster ou à un rôle qui augmente ses permissions effectives dans le cluster. Le privilège d’escalade permet à un sujet de modifier les rôles de cluster auxquels il est lié, augmentant ainsi ses droits à ce niveau.

Sans un mécanisme de contrôle de stratégie actif, il n’est pas possible de limiter l’utilisation de conteneurs ayant accès aux nœuds de cluster sous-jacents, via des mécanismes tels que des conteneurs privilégiés, ou l’utilisation de montages de volumes hostPath.

Un conteneur s’exécutant dans l’espace de noms PID de l’hôte peut inspecter les processus s’exécutant en dehors du conteneur. Si le conteneur a également accès aux capacités ptrace, cela peut être utilisé pour escalader les privilèges en dehors du conteneur.

Il devrait y avoir au moins une PodSecurityPolicy (PSP) définie qui ne permet pas aux conteneurs de partager l’espace de noms PID de l’hôte.

Si vous devez exécuter des conteneurs nécessitant hostPID, cela doit être défini dans une PSP séparée et vous devez vérifier attentivement les contrôles RBAC pour vous assurer que seuls des comptes de service et des utilisateurs limités sont autorisés à accéder à cette PSP.

Un conteneur s’exécutant dans l’espace de noms PID de l’hôte peut inspecter les processus s’exécutant en dehors du conteneur. Si le conteneur a également accès aux capacités ptrace, cela peut être utilisé pour escalader les privilèges en dehors du conteneur.

Il devrait y avoir au moins une stratégie de contrôle d’admission définie qui ne permet pas aux conteneurs de partager l’espace de noms PID de l’hôte.

Si vous devez exécuter des conteneurs nécessitant hostPID, cela doit être défini dans une stratégie séparée et vous devez vérifier attentivement pour vous assurer que seuls des comptes de service et des utilisateurs limités ont la permission d’utiliser cette stratégie.

Un conteneur s’exécutant dans l’espace de noms IPC de l’hôte peut utiliser IPC pour interagir avec des processus en dehors du conteneur.

Il devrait y avoir au moins une stratégie de contrôle d’admission définie qui ne permet pas aux conteneurs de partager l’espace de noms IPC de l’hôte.

Si vous devez exécuter des conteneurs nécessitant hostIPC, cela doit être défini dans une stratégie séparée et vous devez vérifier attentivement pour vous assurer que seuls des comptes de service et des utilisateurs limités ont la permission d’utiliser cette stratégie.

Un conteneur s’exécutant dans l’espace de noms réseau de l’hôte pourrait accéder au périphérique de boucle locale et pourrait accéder au trafic réseau vers et depuis d’autres pods.

Il devrait y avoir au moins une stratégie de contrôle d’admission définie qui ne permet pas aux conteneurs de partager l’espace de noms réseau de l’hôte.

Si vous devez exécuter des conteneurs nécessitant l’accès aux espaces de noms réseau de l’hôte, cela doit être défini dans une stratégie séparée et vous devez vérifier attentivement pour vous assurer que seuls des comptes de service et des utilisateurs limités ont la permission d’utiliser cette stratégie.

Un conteneur s’exécutant avec le drapeau allowPrivilegeEscalation défini sur true peut avoir des processus qui peuvent obtenir plus de privilèges que leur parent.

Il devrait y avoir au moins une stratégie de contrôle d’admission définie qui ne permet pas aux conteneurs d’autoriser l’escalade de privilèges. L’option existe (et est par défaut à true) pour permettre l’exécution de binaires setuid.

Si vous devez exécuter des conteneurs utilisant des binaires setuid ou nécessitant une escalade de privilèges, cela doit être défini dans une stratégie séparée et vous devez vérifier attentivement pour vous assurer que seuls des comptes de service et des utilisateurs limités ont la permission d’utiliser cette stratégie.

Les conteneurs peuvent s’exécuter en tant que n’importe quel utilisateur Linux. Les conteneurs qui s’exécutent en tant qu’utilisateur root, bien qu’ils soient contraints par les fonctionnalités de sécurité de l’environnement d’exécution de conteneur, ont toujours une probabilité accrue de rupture de conteneur.

Idéalement, tous les conteneurs devraient s’exécuter en tant qu’utilisateur défini non-UID 0.

Il devrait y avoir au moins une stratégie de contrôle d’admission définie qui ne permet pas les conteneurs root.

Si vous devez exécuter des conteneurs root, cela devrait être défini dans une stratégie séparée et vous devez vérifier attentivement pour vous assurer que seuls des comptes de service et des utilisateurs limités sont autorisés à utiliser cette stratégie.

Les conteneurs s’exécutent avec un ensemble par défaut de capacités assignées par l’environnement d’exécution de conteneur. Par défaut, cela peut inclure des capacités potentiellement dangereuses. Avec Docker comme environnement d’exécution de conteneur, la capacité NET_RAW est activée, ce qui peut être mal utilisé par des conteneurs malveillants.

Idéalement, tous les conteneurs devraient abandonner cette capacité.

Il devrait y avoir au moins une stratégie de contrôle d’admission définie qui ne permet pas les conteneurs avec la capacité NET_RAW.

Si vous devez exécuter des conteneurs avec cette capacité, cela devrait être défini dans une stratégie séparée et vous devez vérifier attentivement pour vous assurer que seuls des comptes de service et des utilisateurs limités sont autorisés à utiliser cette stratégie.

Les conteneurs s’exécutent avec un ensemble par défaut de capacités assignées par l’environnement d’exécution de conteneur. Des capacités en dehors de cet ensemble peuvent être ajoutées aux conteneurs, ce qui pourrait les exposer à des risques d’attaques de rupture de conteneur.

Il devrait y avoir au moins une stratégie définie qui empêche le lancement de conteneurs avec des capacités au-delà de l’ensemble par défaut.

Si vous devez exécuter des conteneurs avec des capacités supplémentaires, cela doit être défini dans une stratégie distincte et vous devez vérifier attentivement pour vous assurer que seuls des comptes de service et des utilisateurs limités sont autorisés à utiliser cette stratégie.

Les conteneurs s’exécutent avec un ensemble par défaut de capacités assignées par l’environnement d’exécution de conteneur. Les capacités sont des parties des droits généralement accordés sur un système Linux à l’utilisateur root.

Dans de nombreux cas, les applications s’exécutant dans des conteneurs ne nécessitent aucune capacité pour fonctionner, donc du point de vue du principe du moindre privilège, l’utilisation des capacités doit être minimisée.

Les conteneurs s’exécutent avec un ensemble par défaut de capacités assignées par l’environnement d’exécution de conteneur. Les capacités sont des parties des droits généralement accordés sur un système Linux à l’utilisateur root.

Dans de nombreux cas, les applications s’exécutant dans des conteneurs ne nécessitent aucune capacité pour fonctionner, donc du point de vue du principe du moindre privilège, l’utilisation des capacités doit être minimisée.

Un conteneur qui monte un volume hostPath dans le cadre de sa spécification aura accès au système de fichiers du nœud de cluster sous-jacent. L’utilisation de volumes hostPath peut permettre aux conteneurs d’accéder à des zones privilégiées du système de fichiers du nœud.

Il devrait y avoir au moins une stratégie de contrôle d’admission définie qui n’autorise pas les conteneurs à monter des volumes hostPath.

Si vous devez exécuter des conteneurs qui nécessitent des volumes hostPath, cela doit être défini dans une stratégie distincte et vous devez vérifier attentivement pour vous assurer que seuls des comptes de service et des utilisateurs limités sont autorisés à utiliser cette stratégie.

Les ports hôtes connectent directement les conteneurs au réseau de l’hôte. Cela peut contourner des contrôles tels que la politique réseau.

Il devrait y avoir au moins une stratégie de contrôle d’admission définie qui n’autorise pas les conteneurs nécessitant l’utilisation de HostPorts.

Si vous devez exécuter des conteneurs qui nécessitent des HostPorts, cela doit être défini dans une stratégie distincte et vous devez vérifier attentivement pour vous assurer que seuls des comptes de service et des utilisateurs limités sont autorisés à utiliser cette stratégie.

Les politiques réseau Kubernetes sont appliquées par le plugin CNI en cours d’utilisation. Il est donc important de s’assurer que le plugin CNI prend en charge à la fois les politiques réseau Ingress et Egress.

Exécuter différentes applications sur le même cluster Kubernetes crée un risque qu’une application compromise attaque une application voisine. La segmentation du réseau est importante pour garantir que les conteneurs ne peuvent communiquer qu’avec ceux avec lesquels ils sont censés communiquer. Une stratégie réseau est une spécification de la manière dont des sélections de pods sont autorisées à communiquer entre elles et avec d’autres points de terminaison réseau.

Les stratégies réseau sont limitées à l’espace de noms. Lorsqu’une stratégie réseau est introduite dans un espace de noms donné, tout le trafic non autorisé par la stratégie est refusé. Cependant, s’il n’y a pas de stratégies réseau dans un espace de noms, tout le trafic sera autorisé à entrer et sortir des pods de cet espace de noms.

Il est raisonnablement courant que le code de l’application consigne son environnement (particulièrement en cas d’erreur). Cela inclura toutes les valeurs secrètes passées en tant que variables d’environnement, de sorte que les secrets peuvent facilement être exposés à tout utilisateur ou entité ayant accès aux journaux.

Kubernetes prend en charge les secrets en tant qu’objets de première classe, mais il faut veiller à ce que l’accès aux secrets soit soigneusement limité. Utiliser un fournisseur de secrets externe peut faciliter la gestion de l’accès aux secrets, en particulier lorsque les secrets sont utilisés à la fois dans des environnements Kubernetes et non Kubernetes.

Kubernetes prend en charge l’intégration de règles de provenance pour accepter ou rejeter les images dans vos déploiements. Vous pouvez configurer de telles règles pour garantir que seules les images approuvées sont déployées dans le cluster.

Limiter la portée des autorisations des utilisateurs peut réduire l’impact des erreurs ou des activités malveillantes. Un espace de noms Kubernetes vous permet de partitionner les ressources créées en groupes logiquement nommés. Les ressources créées dans un espace de noms peuvent être cachées des autres espaces de noms. Par défaut, chaque ressource créée par un utilisateur dans le cluster Kubernetes s’exécute dans un espace de noms par défaut, appelé default. Vous pouvez créer des espaces de noms supplémentaires et y attacher des ressources et des utilisateurs. Vous pouvez utiliser des plugins d’autorisation Kubernetes pour créer des politiques qui séparent l’accès aux ressources des espaces de noms entre différents utilisateurs.

Seccomp (mode de calcul sécurisé) est utilisé pour restreindre l’ensemble des appels système que les applications peuvent effectuer, permettant aux administrateurs de cluster un meilleur contrôle sur la sécurité des charges de travail exécutées dans le cluster. Kubernetes désactive les profils seccomp par défaut pour des raisons historiques. Vous devriez l’activer pour garantir que les charges de travail disposent d’actions restreintes disponibles dans le conteneur.

Un contexte de sécurité définit les paramètres de sécurité du système d’exploitation (uid, gid, capacités, rôle SELinux, etc.) appliqués à un conteneur. Lors de la conception de vos conteneurs et pods, assurez-vous de configurer le contexte de sécurité pour vos pods, conteneurs et volumes. Un contexte de sécurité est une propriété définie dans le fichier yaml de déploiement. Il contrôle les paramètres de sécurité qui seront assignés au pod/conteneur/volume. Il existe deux niveaux de contexte de sécurité : le contexte de sécurité au niveau du pod et le contexte de sécurité au niveau du conteneur.

Les ressources dans un cluster Kubernetes doivent être séparées par espace de noms, afin de permettre l’application de contrôles de sécurité à ce niveau et de faciliter la gestion des ressources.