Guide de renforcement de la sécurité CIS

Ce document fournit des conseils prescriptifs pour le renforcement d’une installation de production de SUSE® Rancher Prime: RKE2. Il décrit les configurations et les contrôles nécessaires pour répondre aux contrôles de référence Kubernetes du Center for Internet Security (CIS).

Pour plus de détails sur l’évaluation d’un cluster renforcé par rapport à la référence CIS officielle, veuillez consulter le guide d’auto-évaluation CIS approprié :

RKE2 est conçu pour être "renforcé par défaut" et passer la majorité des contrôles CIS Kubernetes sans modification. Il existe quelques exceptions notables qui nécessitent une intervention manuelle pour passer pleinement la référence CIS :

  1. RKE2 ne modifiera pas le système d’exploitation hôte. Par conséquent, vous, l’opérateur, devez effectuer quelques modifications au niveau de l’hôte.

  2. Certains contrôles CIS pour les politiques réseau et les normes de sécurité des pods (ou les politiques de sécurité des pods (PSP) sur les versions RKE2 antérieures à v1.25) limiteront la fonctionnalité du cluster. Vous devez choisir de laisser RKE2 configurer cela pour vous. Pour aider à garantir que ces exigences sont respectées, RKE2 peut être démarré avec le drapeau profile défini sur cis ou cis-1.23 selon la version de RKE2.

Ce guide suppose que RKE2 a été installé, mais n’est pas encore en cours d’exécution. Si vous avez déjà démarré RKE2, vous devrez interrompre le service RKE2.

Exigences au niveau de l’hôte

Il existe trois domaines d’exigences au niveau de l’hôte : les paramètres du kernel, la protection des valeurs par défaut du kubelet et la configuration du processus/répertoire etcd. Ceci est décrit dans cette section.

Paramètres du kernel

La référence CIS nécessite la configuration de certains paramètres spécifiques du noyau Linux. Lorsque RKE2 est installé, il crée un fichier de configuration sysctl pour définir les paramètres requis de manière appropriée. Cependant, il ne configure pas automatiquement l’hôte pour utiliser cette configuration. Vous devez le faire manuellement. L’emplacement du fichier de configuration dépend de la méthode d’installation utilisée.

Si RKE2 a été installé via RPM, YUM ou DNF (la méthode par défaut sur les systèmes d’exploitation utilisant des RPM, comme CentOS), exécutez les commandes suivantes :

sudo cp -f /usr/share/rke2/rke2-cis-sysctl.conf /etc/sysctl.d/60-rke2-cis.conf
sudo systemctl restart systemd-sysctl

Si RKE2 a été installé via l’archive tar (la méthode par défaut sur les systèmes d’exploitation qui n’utilisent pas de RPM, comme Ubuntu), exécutez les commandes suivantes :

sudo cp -f /usr/local/share/rke2/rke2-cis-sysctl.conf /etc/sysctl.d/60-rke2-cis.conf
sudo systemctl restart systemd-sysctl

Si votre système manque du répertoire systemd-sysctl.service et/ou du répertoire /etc/sysctl.d, vous voudrez vous assurer que les sysctls sont appliqués au démarrage en exécutant la commande suivante lors du démarrage :

sudo sysctl -p /usr/local/share/rke2/rke2-cis-sysctl.conf

Veuillez effectuer cette étape uniquement sur des installations fraîches, avant d’utiliser réellement RKE2 pour déployer Kubernetes. De nombreux composants Kubernetes, y compris les plugins CNI, configurent leurs propres sysctls. Redémarrer le service systemd-sysctl sur un cluster Kubernetes en cours d’exécution peut entraîner des effets secondaires inattendus.

Le paramètre Kubelet protect-kernel-defaults est défini sur true

C’est un drapeau kubelet qui fera quitter le kubelet si les paramètres du noyau requis ne sont pas définis ou sont définis sur des valeurs différentes des valeurs par défaut du kubelet.

RKE2 définira automatiquement le drapeau sur true lorsque le drapeau profile est défini.

protect-kernel-defaults est exposé comme un drapeau de niveau supérieur pour RKE2. Si vous avez défini profile sur cis-1.XX et protect-kernel-defaults sur false explicitement, RKE2 abandonnera avec une erreur.

RKE2 vérifiera également les mêmes paramètres du noyau que le kubelet et abandonnera avec une erreur en suivant les mêmes règles que le kubelet. Cela est fait par commodité pour aider l’opérateur à identifier plus rapidement et facilement quels paramètres du noyau violent les valeurs par défaut du kubelet.

etcd est configuré correctement

Le CIS Benchmark exige que le répertoire de données etcd soit possédé par l’utilisateur et le groupe etcd. Cela nécessite implicitement que le processus etcd s’exécute en tant qu’utilisateur etcd au niveau de l’hôte. Pour y parvenir, RKE2 prend plusieurs mesures lorsqu’il est démarré avec un profil cis ou cis-1.XX valide :

  1. Vérifiez que l’utilisateur et le groupe etcd existent sur l’hôte. S’ils n’existent pas, abandonnez avec une erreur.

  2. Créez le répertoire de données d’etcd avec etcd comme propriétaire utilisateur et groupe.

  3. Assurez-vous que le processus etcd est exécuté en tant qu’utilisateur et groupe etcd en configurant correctement le SecurityContext du pod statique etcd.

Sur certaines distributions Linux, la commande useradd ne créera pas de groupe. Le drapeau -U est inclus ci-dessous pour tenir compte de cela. Ce drapeau indique à useradd de créer un groupe portant le même nom que l’utilisateur.

sudo useradd -r -c "etcd user" -s /sbin/nologin -M etcd -U

L’utilisateur et le groupe etcd doivent être définis dans les fichiers de base de données traditionnels à /etc/passwd et /etc/group. Le package os/user de la bibliothèque standard de Golang ne prend pas en charge les bases de données utilisateurs externes telles que NSS ou systemd userdb (varlink).

Configuration RKE2

  • v1.29 et versions ultérieures

  • v1.25 - v1.28

  • v1.24 et versions antérieures

profile: "cis"
# For cis-1.11 only, not needed on cis-1.9/cis-1.10
kube-apiserver-arg:
  - 'service-account-extend-token-expiration=false'

Configuration CIS générique

profile: "cis"

L’utilisation du profil générique cis garantira que le cluster passe le benchmark CIS (rke2-cis-1.XX-profile-hardened) associé à la version de Kubernetes que RKE2 exécute. Par exemple, RKE2 v1.26.XX avec le profile: cis passera le rke2-cis-1.8-profile-hardened dans Rancher.

L’utilisation du profil générique cis garantit que les mises à jour de RKE2 ne nécessitent pas de modification de la configuration existante. Tous les changements nécessaires pour passer le benchmark CIS applicable seront appliqués automatiquement.

Une correspondance approximative des versions RKE2 aux versions de benchmark CIS est la suivante :

Versions mineures de RKE2

Benchmark CIS applicable

Drapeau de profil

1.27-1.28

1.9

cis

1.26

1.8

cis-1.23, cis

1.25

1.7

cis-1.23, cis

1.24

1.24

cis-1.23

1.23

1.23

cis-1.23

1.19-1.22

1.6

cis-1.6

 
profile: "cis-1.23"

Le fichier de configuration doit être nommé config.yaml et placé dans /etc/rancher/rke2. Le répertoire doit être créé avant d’installer RKE2.

Lorsque le drapeau profile est activé, il fait ce qui suit :

  • v1.25 et versions ultérieures

  • v1.24 et versions antérieures

  1. Vérifie que les exigences au niveau de l’hôte ont été satisfaites. Si ce n’est pas le cas, RKE2 se terminera avec une erreur fatale décrivant les exigences non satisfaites.

  2. Configure le pod statique etcd pour s’exécuter en tant qu’utilisateur et groupe etcd, comme expliqué dans le guide de renforcement de la sécurité etcd.

  3. Applique des politiques réseau qui permettent au cluster de passer les contrôles associés.

  4. Applique des permissions de fichier plus restrictives (600 contre 644) aux manifestes d’agent et à d’autres fichiers de configuration.

  5. Configure le contrôleur d’admission de sécurité des pods pour appliquer le mode restreint dans tous les espaces de noms, à l’exception des espaces de noms kube-system, cis-operator-system et tigera-operator. Ces espaces de noms sont exemptés pour permettre aux pods système de s’exécuter sans restrictions, ce qui est nécessaire pour le bon fonctionnement du cluster. Pour plus d’informations sur la configuration du PSA, voir les configurations par défaut de l’admission de sécurité des pods. Pour plus d’informations sur les normes de sécurité des pods, veuillez vous référer à la documentation officielle.

  1. Vérifie que les exigences au niveau de l’hôte ont été satisfaites. Si ce n’est pas le cas, RKE2 se terminera avec une erreur fatale décrivant les exigences non satisfaites.

  2. Applique des politiques réseau qui permettent au cluster de passer les contrôles associés.

  3. Configure des politiques de sécurité des pods d’exécution qui permettent au cluster de passer les contrôles associés.

Exigences d’exécution de Kubernetes

Les exigences d’exécution pour passer le CIS Benchmark sont centrées sur la sécurité des pods et les politiques réseau. La plupart de cela est automatiquement géré par RKE2 lors de l’utilisation d’un profil cis-1.XX valide, mais une intervention supplémentaire de l’opérateur est requise.

Sécurité des Pods

RKE2 fonctionne toujours avec un certain niveau de sécurité des pods.

  • v1.25 et versions ultérieures

  • v1.24 et versions antérieures

Sur v1.25 et versions ultérieures, Admission de Sécurité des Pods (PSA) sont utilisés pour la sécurité des pods. Un fichier de configuration par défaut pour l’Admission de Sécurité des Pods sera ajouté au cluster au démarrage comme suit :

Avec le profil cis/cis-1.23 :

  • RKE2 appliquera une norme de sécurité des pods restreinte via un fichier de configuration qui imposera le mode restricted dans tout le cluster, à l’exception des espaces de noms kube-system, cis-operator-system et tigera-operator pour garantir le bon fonctionnement des pods système.

Sans le profil cis/cis-1.23 :

  • RKE2 appliquera une norme de sécurité des pods non restreinte via un fichier de configuration qui imposera le mode privileged dans tout le cluster, ce qui permet un mode complètement non restreint pour tous les pods dans le cluster. Voir la page Politiques de Sécurité des Pods pour plus de détails.

Sur v1.24 et versions antérieures, le contrôleur d’admission PodSecurityPolicy est toujours activé. Une stratégie est appliquée en fonction du profil passé à RKE2.

Avec le cis-1.6 profil:

  • RKE2 mettra en place un ensemble de stratégies beaucoup plus restrictives. Ces stratégies répondent aux exigences décrites dans la section 5.2 du CIS Benchmark.

Sans le profil cis-1.6 :

  • RKE2 mettra en place une stratégie non restreinte qui permet à Kubernetes de fonctionner comme si le contrôleur d’admission PodSecurityPolicy n’était pas activé. Voir la page Politiques de Sécurité des Pods pour plus de détails.

Les composants du plan de contrôle Kubernetes et les ajouts critiques tels que CNI, DNS et Ingress sont exécutés en tant que pods dans l’espace de noms kube-system. Par conséquent, cet espace de noms aura une politique moins restrictive afin que ces composants puissent fonctionner correctement.

Politiques Réseau

Lorsqu’il est exécuté avec un profil valide "cis-1.XX", RKE2 mettra en place NetworkPolicies qui respecte le CIS Benchmark pour les espaces de noms intégrés de Kubernetes. Ces espaces de noms sont : kube-system, kube-public et default.

Le NetworkPolicy utilisé ne permettra qu’aux pods du même espace de noms de communiquer entre eux. Il y a quelques exceptions notables à cela, car cela permet de résoudre les requêtes DNS.

  • Les requêtes DNS sont autorisées à atteindre le serveur DNS

  • Les requêtes HTTP/s sont autorisées à atteindre le service ingress-nginx

  • Les requêtes HTTPs sont autorisées à atteindre le metrics-server

  • Les requêtes vers le webhook ingress-nginx sur le pod spécifié par le pod ingress-nginx (normalement 8443)

  • Les requêtes HTTPs vers le rke2-snapshot-validation-webhook

Intervention de l’opérateur requise

Les opérateurs doivent gérer les stratégies réseau normalement pour les espaces de noms supplémentaires qui sont créés.

Configurer le compte de service default

Définir automountServiceAccountToken à false pour default comptes de service.

Kubernetes fournit un compte de service default 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 default doit être configuré de manière à ne pas fournir de token et à ne pas avoir d’attributions de droits explicites.

Pour chaque espace de noms incluant default et kube-system sur une installation RKE2 standard, le compte de service default doit inclure cette valeur :

automountServiceAccountToken: false

RKE2 définira automatiquement la valeur correctement pour les espaces de noms kube-system, cis-operator-system, kube-node-lease et tigera-operator.

Intervention de l’opérateur requise

Pour les espaces de noms créés par l’opérateur de cluster, le script et le fichier de configuration suivants peuvent être utilisés pour configurer le compte de service default.

La configuration ci-dessous doit être enregistrée dans un fichier appelé account_update.yaml.

apiVersion: v1
kind: ServiceAccount
metadata:
  name: default
automountServiceAccountToken: false

Créer un fichier de script bash appelé account_update.sh. Assurez-vous de sudo chmod +x account_update.sh afin que le script ait les permissions d’exécution.

#!/bin/bash -e

for namespace in $(kubectl get namespaces -A -o=jsonpath="{.items[*]['metadata.name']}"); do
  echo -n "Patching namespace $namespace - "
  kubectl patch serviceaccount default -n ${namespace} -p "$(cat account_update.yaml)"
done

Exécutez ce script pour appliquer la configuration account_update.yaml au compte de service default dans tous les espaces de noms.

Configuration de l’audit du serveur API

Les exigences CIS 1.2.22 à 1.2.25 sont liées à la configuration des journaux d’audit pour le serveur API. Lorsque RKE2 est démarré avec le drapeau profile activé, il configurera automatiquement les paramètres --audit-log- renforcés dans le serveur API pour passer ces vérifications CIS.

La politique d’audit par défaut de RKE2 est configurée pour ne pas enregistrer les requêtes dans le serveur API. Cela est fait pour permettre aux opérateurs de cluster de personnaliser une politique d’audit qui répond à leurs exigences et besoins d’audit, car ceux-ci sont spécifiques à l’environnement et aux politiques de chaque utilisateur.

Une politique d’audit par défaut est créée par RKE2 lorsqu’il est démarré avec le drapeau profile activé. La politique est définie dans /etc/rancher/rke2/audit-policy.yaml.

apiVersion: audit.k8s.io/v1
kind: Policy
metadata:
  creationTimestamp: null
rules:
- level: None
Intervention de l’opérateur requise

Pour commencer à enregistrer les requêtes vers le serveur API, au moins le paramètre level doit être modifié, par exemple, en Metadata. Des informations détaillées sur la configuration de la stratégie pour le serveur API peuvent être trouvées dans la documentation Kubernetes.

Après avoir adapté la politique d’audit, RKE2 doit être redémarré pour charger la nouvelle configuration.

sudo systemctl restart rke2-server.service

Les journaux d’audit du serveur API seront écrits dans /var/lib/rancher/rke2/server/logs/audit.log.

Problèmes connus

Les contrôles suivants sont ceux que RKE2 par défaut ne passent actuellement pas. Chaque lacune sera expliquée et comment elle est traitée.

Contrôle 1.1.12

Assurez-vous que la propriété du répertoire de données etcd est définie sur etcd:etcd.

Utilisation

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 être la propriété de etcd:etcd.

Correction

Cela peut être remédié en créant un utilisateur et un groupe etcd comme décrit ci-dessus.

Contrôle 5.1.5

Assurez-vous que les comptes de service par défaut ne sont pas utilisés activement.

Utilisation

Kubernetes fournit un compte de service default 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 default doit être configuré de manière à ne pas fournir de token de compte de service et ne doit avoir aucune attribution de droits explicite.

Cela peut être remédié en mettant à jour le champ automountServiceAccountToken à false pour le compte de service default dans chaque espace de noms.

Conclusion

Si vous avez suivi ce guide, votre cluster RKE2 sera configuré pour passer le CIS Kubernetes Benchmark. Vous pouvez consulter nos guides d’auto-évaluation CIS pour comprendre comment nous avons vérifié chacun des benchmarks et comment vous pouvez faire de même sur votre cluster.