1. Introduction
Présentation des concepts de sécurité en Kubernetes
Kubernetes, en tant que plateforme de gestion de conteneurs, facilite le déploiement et l’orchestration des applications tout en garantissant une isolation des services. Cependant, comme pour tout environnement multi-tenant, la sécurité est un aspect fondamental pour protéger les ressources partagées et garantir l’intégrité des applications et des systèmes sous-jacents.
Dans Kubernetes, l’isolation des conteneurs repose principalement sur des technologies comme les Security Contexts et les Control Groups (cgroups). Cependant, bien que ces mécanismes assurent une isolation de base, ils ne garantissent pas une protection complète contre les comportements malveillants ou les attaques sophistiquées.
C’est là que le contrôle d’accès et le confinement entrent en jeu. Le contrôle d’accès vise à limiter les actions que les processus au sein des conteneurs peuvent effectuer, tandis que le confinement cherche à restreindre leurs interactions avec le système hôte. Des outils comme Seccomp et AppArmor sont utilisés dans Kubernetes pour renforcer cette sécurité, en limitant les appels système autorisés et en restreignant l’accès aux ressources du système.
Importance du contrôle d’accès et du confinement des processus
Le contrôle d’accès et le confinement des processus sont essentiels pour minimiser les risques de sécurité dans Kubernetes. En réduisant la surface d’attaque, ces mécanismes empêchent les applications malveillantes ou compromises d’accéder à des ressources sensibles ou d’exécuter des actions non autorisées, comme des appels système dangereux, qui pourraient compromettre l’hôte ou d’autres conteneurs.
- Contrôle d’accès : Cela garantit que les processus ne peuvent effectuer que les actions explicitement autorisées. Par exemple, un conteneur qui ne doit pas interagir avec des périphériques système ne pourra pas faire d’appels système liés à ces périphériques.
- Confinement : L’objectif est de limiter l’accès du conteneur aux ressources système. Cela inclut des restrictions sur les fichiers, les réseaux, les ressources système et les appels système que le conteneur peut utiliser, afin d’éviter l’exploitation de vulnérabilités dans l’application ou le conteneur.
Objectifs du guide
Ce guide se concentrera sur deux technologies essentielles pour le contrôle d’accès et le confinement dans Kubernetes : Seccomp et AppArmor. L’objectif est de fournir une compréhension approfondie de ces technologies, de leur installation, configuration, et utilisation dans un environnement Kubernetes. Vous apprendrez également comment appliquer ces outils pour protéger vos applications conteneurisées, avec des exemples concrets et des cas d’utilisation.
2. Contexte et Définition
Définition du contrôle d’accès et du confinement
Dans le contexte de Kubernetes et des conteneurs, le contrôle d’accès et le confinement sont des mécanismes qui visent à limiter ce qu’un processus ou un conteneur peut faire dans l’environnement. Ces technologies permettent de renforcer la sécurité en restreignant les privilèges des conteneurs et en empêchant l’exécution d’opérations non sécurisées ou dangereuses.
- Contrôle d’accès : Cela fait référence à la gestion des permissions, en définissant ce qu’un processus dans un conteneur peut faire et quels services ou ressources il peut accéder. Par exemple, un conteneur peut être autorisé à lire un fichier mais pas à l’écrire ou à exécuter certains appels système spécifiques. Le contrôle d’accès est une méthode préventive qui garantit que seuls les comportements explicitement autorisés sont possibles.
- Confinement : Il vise à restreindre ce qu’un conteneur peut voir ou interagir avec, limitant ainsi son impact si une vulnérabilité est exploitée. Le confinement empêche un conteneur de dépasser certaines limites imposées, même s’il est compromis. Cela inclut des restrictions sur les systèmes de fichiers, les processus du système, et l’accès réseau. Par exemple, un conteneur peut être configuré pour ne pas pouvoir accéder aux périphériques physiques de l’hôte ou à certaines parties sensibles du système d’exploitation.
Explication du rôle de Seccomp et d’AppArmor dans la sécurité des conteneurs
- Seccomp (Secure Computing Mode)Seccomp est un mécanisme de sécurité Linux qui permet de restreindre les appels système qu’un conteneur peut faire. Lorsqu’un conteneur exécute une commande, il peut interagir avec le noyau Linux à travers des appels système. Seccomp permet de créer des profils qui définissent un ensemble limité de ces appels système autorisés, rejetant ceux qui sont jugés non nécessaires ou dangereux pour l’application.
- Rôle dans la sécurité des conteneurs : En limitant les appels système, Seccomp protège l’hôte contre les attaques exploitant des appels système vulnérables ou inutiles. Cela réduit la surface d’attaque d’un conteneur en restreignant ses interactions avec le noyau.
- AppArmor (Application Armor)AppArmor est un autre mécanisme de sécurité basé sur des profils qui restreint les actions d’un programme ou d’un processus. Contrairement à Seccomp, qui se concentre sur les appels système, AppArmor contrôle les ressources que les programmes peuvent lire, écrire, et exécuter, en se basant sur un ensemble de règles spécifiques à chaque programme.
- Rôle dans la sécurité des conteneurs : AppArmor permet de restreindre l’accès des conteneurs aux fichiers, aux sockets, et aux autres ressources systèmes. En imposant des restrictions strictes sur les chemins de fichiers et les ressources réseau qu’un conteneur peut utiliser, AppArmor fournit une couche supplémentaire de sécurité en limitant les capacités d’accès du conteneur à l’hôte et aux autres services.
Différences entre Seccomp et AppArmor
Bien que Seccomp et AppArmor partagent l’objectif de renforcer la sécurité en limitant les privilèges des processus, ils agissent à des niveaux différents et offrent des protections complémentaires :
- Seccomp se concentre uniquement sur les appels système. Il limite ce que le conteneur peut demander au noyau de faire, en réduisant la surface d’attaque de l’hôte et en limitant les actions potentiellement dangereuses, mais il n’est pas capable de restreindre l’accès aux ressources du système, comme les fichiers ou les périphériques.
- AppArmor, de son côté, offre un contrôle plus large en imposant des restrictions sur les fichiers, les périphériques, et d’autres ressources du système. AppArmor est donc plus complet en termes de confinement des processus, mais il nécessite des profils plus complexes et détaillés pour couvrir l’ensemble des cas d’usage.
En résumé, Seccomp et AppArmor sont deux outils complémentaires : Seccomp restreint les appels système, tandis qu’AppArmor limite les accès aux ressources du système. L’utilisation conjointe de ces deux technologies dans Kubernetes permet de renforcer considérablement la sécurité des conteneurs.
3. Installation et prérequis
Préparation de l’environnement Kubernetes
Avant de configurer Seccomp et AppArmor dans Kubernetes, il est essentiel de s’assurer que l’environnement Kubernetes est correctement configuré pour supporter ces mécanismes de sécurité. Voici les étapes à suivre pour préparer votre cluster Kubernetes.
- Vérification des versions KubernetesAssurez-vous que votre cluster Kubernetes est à jour et compatible avec les mécanismes de sécurité que vous souhaitez mettre en place. Seccomp et AppArmor sont supportés par Kubernetes depuis plusieurs versions, mais des versions récentes offrent un meilleur support et des fonctionnalités avancées.Vous pouvez vérifier la version de Kubernetes avec la commande suivante :
Prérequis pour Seccomp et AppArmor :kubectl version --short
- Kubernetes 1.12 ou plus récent pour Seccomp.
- Kubernetes 1.14 ou plus récent pour AppArmor.
- Vérification des configurations du noyauSeccomp et AppArmor nécessitent une configuration spécifique du noyau Linux. Vérifiez que les modules nécessaires sont activés sur tous les nœuds de votre cluster.
- Seccomp : Le support de Seccomp doit être activé dans le noyau. La commande suivante permet de vérifier si Seccomp est activé :
zcat /proc/config.gz | grep CONFIG_SECCOMP
Vous devriez voirCONFIG_SECCOMP=y
. - AppArmor : AppArmor doit être activé sur votre noyau. Vérifiez l’état d’AppArmor avec :
sudo apparmor_status
Cette commande vous indiquera si AppArmor est actif et les profils qui sont appliqués.
- Seccomp : Le support de Seccomp doit être activé dans le noyau. La commande suivante permet de vérifier si Seccomp est activé :
- Préparation des nœuds KubernetesPour que Seccomp et AppArmor fonctionnent correctement dans Kubernetes, assurez-vous que tous les nœuds de votre cluster sont configurés pour supporter ces mécanismes.
- AppArmor : Vérifiez que l’agent AppArmor est installé et activé sur les nœuds. Sur Ubuntu, vous pouvez installer AppArmor avec :
sudo apt-get install apparmor apparmor-utils
- Seccomp : Sur la plupart des distributions Linux modernes, Seccomp est activé par défaut, mais vous devrez peut-être ajuster certaines configurations dans votre cluster Kubernetes pour activer pleinement les profils Seccomp.
- AppArmor : Vérifiez que l’agent AppArmor est installé et activé sur les nœuds. Sur Ubuntu, vous pouvez installer AppArmor avec :
Installation et configuration de Seccomp
- Activer Seccomp dans KubernetesSeccomp peut être activé dans Kubernetes en configurant le kubelet avec un profil par défaut. Assurez-vous que le paramètre
--seccomp-profile-root
est défini dans le fichier de configuration du kubelet (souvent/etc/kubernetes/kubelet.conf
).Voici un exemple de configuration pour le kubelet :--seccomp-profile-root=/var/lib/kubelet/seccomp
- Création de profils Seccomp personnalisésUn profil Seccomp définit quels appels système sont autorisés ou rejetés pour un conteneur. Kubernetes permet de spécifier ces profils au niveau des pods en utilisant l’annotation
seccomp.security.kubernetes.io/pod
dans le manifeste du pod.Exemple de profil Seccomp dans un manifeste de pod :
Le profilmy-seccomp-profile
doit être créé dans le répertoire spécifié par--seccomp-profile-root
. - Validation du fonctionnement de SeccompUne fois le profil Seccomp configuré et appliqué, vous pouvez tester son application avec des outils comme
kubectl describe pod
pour vérifier que le profil est correctement associé au pod et que les restrictions sont en place.
Installation et configuration d’AppArmor
- Activer AppArmor dans KubernetesComme pour Seccomp, vous devez vous assurer qu’AppArmor est activé sur tous les nœuds du cluster Kubernetes. Sur les distributions basées sur Ubuntu, AppArmor est généralement activé par défaut. Cependant, si nécessaire, vous pouvez activer AppArmor avec les commandes suivantes :
sudo systemctl enable apparmor
sudo systemctl start apparmor - Création de profils AppArmor personnalisésLes profils AppArmor pour Kubernetes sont généralement placés dans
/etc/apparmor.d/
. Pour créer un profil AppArmor, vous devez d’abord rédiger un fichier de profil qui définit les permissions d’accès aux fichiers, périphériques et autres ressources du système.Exemple de profil AppArmor (nommémy-apparmor-profile
):
Vous pouvez ensuite charger ce profil dans AppArmor avec la commande :sudo apparmor_parser -r /etc/apparmor.d/my-apparmor-profile
- Appliquer le profil AppArmor sur un pod KubernetesVous pouvez spécifier un profil AppArmor dans le manifeste d’un pod Kubernetes à l’aide de l’annotation
apparmor.security.beta.kubernetes.io/pod
. Exemple de manifeste de pod avec un profil AppArmor : - Validation du fonctionnement d’AppArmorVérifiez si le profil AppArmor est correctement appliqué à un pod en utilisant la commande
kubectl describe pod
et en cherchant les annotations correspondantes. De plus, vous pouvez inspecter les logs d’AppArmor pour tout avertissement ou erreur de configuration.
4. Configuration de Seccomp
Explication des profils Seccomp
Seccomp fonctionne en utilisant des profils qui spécifient quels appels système un conteneur est autorisé à effectuer. Ces profils peuvent être créés de manière générale ou personnalisée en fonction des besoins spécifiques de l’application. Chaque profil Seccomp définit une liste blanche ou une liste noire des appels système, permettant ainsi de limiter les interactions avec le noyau Linux pour une application donnée.
Les profils Seccomp sont des fichiers JSON ou des chemins relatifs à un fichier qui spécifient les actions à entreprendre pour chaque appel système. Les actions possibles sont :
- Allow : L’appel système est autorisé.
- Kill : Le conteneur est tué si l’appel système est effectué.
- Errno : L’appel système échoue et retourne une erreur spécifique.
- Trace : L’appel système est tracé sans qu’une action immédiate soit prise.
- Notify : Un appel système est autorisé, mais une notification est envoyée.
Seccomp peut être utilisé en mode strict (où seuls quelques appels système sont autorisés) ou en mode plus permissif. L’objectif est de réduire la surface d’attaque en autorisant uniquement les appels système nécessaires à l’exécution de l’application dans le conteneur.
Configuration des profils Seccomp dans Kubernetes
Les profils Seccomp dans Kubernetes peuvent être spécifiés à différents niveaux, y compris au niveau du pod ou du conteneur. Kubernetes permet également de définir un profil Seccomp par défaut qui s’applique à tous les conteneurs dans un pod.
- Définir un profil Seccomp au niveau du podPour définir un profil Seccomp pour un pod, vous pouvez utiliser l’annotation
seccomp.security.kubernetes.io/pod
dans le manifeste du pod. Cela permet d’appliquer un profil spécifique à l’ensemble du pod.
Exemple de manifeste avec un profil Seccomp spécifié :
Dans cet exemple, le profilmy-seccomp-profile
sera appliqué à tous les conteneurs du podexample-pod
. - Définir un profil Seccomp au niveau du conteneurVous pouvez également spécifier un profil Seccomp pour un conteneur individuel dans un pod. Cela peut être utile lorsque vous souhaitez appliquer des restrictions différentes à chaque conteneur du même pod.Exemple de manifeste avec un profil Seccomp spécifique pour un conteneur :
Ici, le conteneurexample-container
aura un profil Seccomp spécifique, tandis que d’autres conteneurs du même pod peuvent avoir des profils différents ou pas de profil du tout.
Application des profils Seccomp sur des pods
Une fois que les profils Seccomp sont créés et associés aux pods ou aux conteneurs, Kubernetes applique ces profils lorsque les conteneurs sont lancés. Kubernetes va faire respecter les restrictions définies dans les profils Seccomp, ce qui signifie que les appels système non autorisés par le profil seront bloqués.
- Exécution d’un pod avec un profil SeccompVous pouvez vérifier si le profil Seccomp est bien appliqué en examinant les logs du conteneur ou en utilisant la commande
kubectl describe pod
. Vous devriez voir l’annotation ou le contexte de sécurité associé au profil Seccomp.Exemple de commande pour vérifier les annotations :bashCopy codekubectl describe pod example-pod
Cette commande renverra les détails du pod, y compris les annotations, et vous pourrez vérifier si le profil Seccomp est bien appliqué. - Validation de la configurationPour tester l’efficacité du profil Seccomp, vous pouvez tenter d’exécuter des appels système interdits dans le conteneur. Par exemple, si le profil bloque l’accès à un périphérique, vous pourriez essayer d’accéder à ce périphérique depuis un conteneur et vérifier qu’il échoue.Exemple de test d’appel système non autorisé :
docker run --rm -it --security-opt seccomp=localhost/my-seccomp-profile nginx
Cela permettra de tester si le profil Seccomp personnalisé bloque l’accès aux appels système non autorisés.
Cas d’usage : Créer un profil Seccomp personnalisé
Imaginons que vous ayez une application qui nécessite des appels systèmes standards comme read()
, write()
, et open()
, mais vous souhaitez interdire les appels dangereux tels que ptrace()
ou mmap()
. Vous pouvez créer un profil Seccomp personnalisé pour restreindre l’accès uniquement aux appels nécessaires et bloquer le reste.
Voici un exemple d’un profil Seccomp personnalisé qui autorise les appels système read()
, write()
, et open()
, tout en bloquant ptrace()
et mmap()
:
Dans ce profil :
- Tous les appels systèmes sont par défaut rejetés (
SCMP_ACT_ERRNO
). - Seuls
read()
,write()
, etopen()
sont autorisés. - Les appels système
ptrace()
etmmap()
sont explicitement bloqués (SCMP_ACT_KILL
).
Ce profil peut être enregistré sur le nœud Kubernetes et utilisé dans un pod en suivant les étapes décrites précédemment.
Debugging et validation de la configuration Seccomp
Lorsque vous appliquez un profil Seccomp, il est important de valider que le profil fonctionne comme prévu. Voici quelques étapes de debugging à suivre :
- Vérification des erreurs : Si un appel système est bloqué, Kubernetes ou le conteneur peut générer des messages d’erreur dans les logs. Vous pouvez utiliser la commande
kubectl logs
pour examiner ces erreurs. - Test avec un profil moins strict : Si vous avez des problèmes d’exécution, essayez de modifier temporairement le profil pour le rendre moins restrictif, puis réappliquez-le.
- Utilisation de
seccomp
en mode trace : Vous pouvez activer le mode de traçage dans Seccomp pour surveiller les appels système bloqués sans tuer le conteneur.
5. Configuration d’AppArmor
Présentation des profils AppArmor
Les profils AppArmor sont utilisés pour limiter ce qu’un programme ou un processus peut faire sur un système Linux. Ils fonctionnent en spécifiant des règles de sécurité sur les fichiers, les périphériques et les autres ressources qu’un programme peut accéder. Contrairement à Seccomp, qui se concentre sur les appels système, AppArmor impose des restrictions sur les interactions avec le système de fichiers et les autres ressources système, offrant ainsi un confinement plus complet.
Les profils AppArmor sont généralement définis pour des programmes ou des services spécifiques, comme un serveur web ou une application conteneurisée. Chaque profil peut contenir des règles concernant les fichiers et répertoires que le programme peut lire ou écrire, ainsi que des restrictions sur l’exécution d’autres programmes ou la communication avec le réseau.
Les actions possibles dans un profil AppArmor sont les suivantes :
- allow : Autorise l’accès à une ressource.
- deny : Refuse l’accès à une ressource.
- audit : Enregistre les tentatives d’accès à une ressource sans les autoriser.
- profile : Déclare un profil pour un programme ou une ressource spécifique.
Configuration des profils AppArmor dans Kubernetes
- Créer un profil AppArmorLes profils AppArmor sont généralement stockés dans le répertoire
/etc/apparmor.d/
. Un profil simple pourrait ressembler à ceci :
Ce profil limite l’accès à certains fichiers et périphériques pour l’application concernée. Par exemple, le fichier/etc/hosts
est bloqué en écriture, mais/home/*
est autorisé en écriture. - Charger le profil AppArmor
Après avoir créé le profil, vous devez le charger dans le système avec la commande suivante :sudo apparmor_parser -r /etc/apparmor.d/my-apparmor-profile
Cela applique le profil à l’ensemble du système. Si vous avez plusieurs profils, vous pouvez également les charger ensemble ou au moment du démarrage.
Application des profils AppArmor sur des pods
Une fois le profil AppArmor créé et chargé, vous pouvez l’appliquer à des conteneurs ou des pods dans Kubernetes. Kubernetes permet d’appliquer les profils AppArmor au niveau du pod ou du conteneur via des annotations.
- Définir un profil AppArmor pour un podVous pouvez appliquer un profil AppArmor à un pod Kubernetes en utilisant l’annotation
apparmor.security.beta.kubernetes.io/pod
. Voici un exemple d’un manifeste de pod avec l’application d’un profil AppArmor personnalisé :
Dans cet exemple, le profilmy-apparmor-profile
sera appliqué au podexample-pod
et à tous ses conteneurs. Cela permettra de restreindre l’accès aux ressources définies dans le profil AppArmor. - Définir un profil AppArmor pour un conteneur spécifiqueSi vous souhaitez appliquer un profil AppArmor à un conteneur spécifique au sein d’un pod, vous pouvez utiliser la section
securityContext
dans le manifeste du conteneur. Voici un exemple où un profil AppArmor est appliqué uniquement au conteneurexample-container
:
Ici, le profilmy-apparmor-profile
est appliqué uniquement àexample-container
et non à d’autres conteneurs dans le pod.
Cas d’usage : Créer un profil AppArmor personnalisé
Imaginons que vous souhaitiez créer un profil AppArmor pour une application web. Cette application doit avoir un accès en lecture au répertoire /var/www
, mais elle ne doit pas pouvoir modifier les fichiers de configuration du système, tels que ceux dans /etc
. De plus, elle ne doit pas pouvoir interagir avec des périphériques.
Voici un exemple de profil AppArmor pour ce cas :
Ce profil garantit que l’application web peut lire son répertoire /var/www
, mais qu’elle est restreinte des fichiers de configuration sensibles et des périphériques système. De plus, il permet l’écriture dans /tmp
mais bloque les écritures ailleurs.
Debugging et validation de la configuration AppArmor
Une fois qu’un profil AppArmor est appliqué à un pod ou un conteneur, il est important de vérifier son bon fonctionnement et de déboguer tout problème éventuel. Voici quelques techniques pour cela :
- Vérifier les logs AppArmorLes logs AppArmor peuvent fournir des informations utiles en cas d’erreur. Sur Ubuntu, les logs sont généralement disponibles dans
/var/log/syslog
ou/var/log/kern.log
. Vous pouvez rechercher des messages relatifs à AppArmor avec la commande suivante :grep apparmor /var/log/syslog
- Tester les accès et interactionsTestez si les restrictions imposées par le profil AppArmor fonctionnent en tentant d’accéder aux ressources interdites par le profil. Par exemple, si vous avez interdit l’accès à
/etc
, tentez d’y accéder depuis le conteneur et vérifiez que l’opération échoue comme prévu. - Utiliser le mode de traçage (audit)Si vous voulez auditer les tentatives d’accès qui sont bloquées sans nécessairement les tuer, vous pouvez utiliser l’action
audit
dans le profil AppArmor pour surveiller les accès refusés.
6. Use Cases pour Seccomp et AppArmor
Dans cette section, nous allons explorer deux cas d’utilisation pratiques pour Seccomp et AppArmor, afin de mieux comprendre comment ces mécanismes peuvent être utilisés pour renforcer la sécurité des conteneurs dans Kubernetes.
Cas d’usage 1 : Restriction des appels système dans un pod avec Seccomp
Scénario : Imaginons que vous ayez un conteneur exécutant une application qui n’a pas besoin de faire certains appels système, comme ptrace
ou mmap
, qui peuvent être utilisés pour l’exploitation de vulnérabilités. Vous souhaitez limiter les appels système autorisés dans le conteneur pour réduire la surface d’attaque.
Solution : Vous allez créer un profil Seccomp personnalisé qui autorise uniquement les appels système nécessaires au bon fonctionnement de l’application et bloque tous les autres appels, en particulier les appels risqués.
- Créer le profil Seccomp personnalisé
Voici un exemple de profil Seccomp qui permet uniquement les appels systèmesread()
,write()
, etopen()
tout en bloquant des appels commeptrace()
etmmap()
: - Appliquer le profil Seccomp au pod
Vous pouvez appliquer ce profil à un pod en utilisant l’annotation suivante dans le manifeste du pod : - Validation du profil Seccomp
Une fois le pod déployé, vous pouvez vérifier que le profil est bien appliqué avec la commande :kubectl describe pod secure-app-pod
Ensuite, vous pouvez tester si les appels système interdits, commeptrace()
, échouent comme prévu.
Bénéfices :
- Limitation de la surface d’attaque en bloquant les appels système inutiles.
- Protection accrue contre les attaques utilisant des appels système malveillants ou vulnérables.
Cas d’usage 2 : Confinement d’un conteneur avec AppArmor pour limiter l’accès aux ressources du système
Scénario : Supposons que vous ayez un conteneur qui exécute une application web. Vous ne voulez pas que ce conteneur ait accès à des fichiers sensibles sur l’hôte, comme les fichiers de configuration système dans /etc
ou l’accès aux périphériques comme /dev/tty
. Vous souhaitez également restreindre l’écriture uniquement à des répertoires spécifiques, comme /tmp
.
Solution : Vous allez créer un profil AppArmor qui restreint l’accès du conteneur aux ressources sensibles et permet seulement l’accès en écriture aux répertoires spécifiques.
- Créer le profil AppArmor personnalisé
Voici un profil AppArmor qui restreint l’accès aux ressources et aux fichiers du système : - Appliquer le profil AppArmor au pod
Vous pouvez appliquer ce profil au pod de l’application web dans Kubernetes à l’aide de l’annotation suivante dans le manifeste du pod : - Validation du profil AppArmor
Une fois le pod déployé, vous pouvez vérifier que le profil AppArmor est appliqué correctement en utilisant la commande :kubectl describe pod webapp-pod
Ensuite, testez l’accès aux répertoires interdits comme/etc
ou/dev
. Les tentatives d’accès devraient échouer.
Bénéfices :
- Renforcement du confinement des conteneurs en limitant l’accès aux ressources sensibles de l’hôte.
- Prévention des modifications non autorisées dans des répertoires sensibles comme
/etc
et des périphériques comme/dev
.
Comparaison des deux approches
- Seccomp est plus orienté vers les appels système et permet de restreindre les interactions d’un conteneur avec le noyau Linux. Il est efficace pour limiter la surface d’attaque en empêchant l’exécution d’appels système non autorisés.
- AppArmor offre un confinement plus large, agissant sur l’accès aux fichiers, périphériques et autres ressources du système. Il permet de définir des règles d’accès détaillées et spécifiques pour chaque programme ou conteneur.
En fonction du scénario, il peut être utile d’utiliser Seccomp pour limiter les appels système dans les conteneurs, tout en utilisant AppArmor pour gérer l’accès aux ressources système et assurer un confinement plus strict.
7. Meilleures pratiques
Dans cette section, nous aborderons les meilleures pratiques à suivre pour la gestion de la sécurité avec Seccomp et AppArmor dans Kubernetes. L’objectif est de garantir que ces mécanismes sont utilisés de manière efficace et sûre, tout en minimisant les risques de configuration incorrecte.
Bonnes pratiques pour la gestion de la sécurité avec Seccomp
- Utiliser des profils Seccomp stricts par défaut
Lorsque cela est possible, il est recommandé d’utiliser des profils Seccomp stricts pour tous vos conteneurs. En appliquant un profil Seccomp par défaut, vous vous assurez que seuls les appels système nécessaires sont autorisés, réduisant ainsi la surface d’attaque.- Utilisez le profil
runtime/default
de Docker comme point de départ. Ce profil permet de limiter les appels système au strict nécessaire tout en permettant à l’application de s’exécuter correctement. - Pour des applications plus sensibles ou pour des conteneurs exécutant des logiciels à haut risque, vous pouvez créer des profils personnalisés plus restrictifs.
- Utilisez le profil
- Appliquer des profils Seccomp au niveau du pod
Si un profil Seccomp doit être appliqué à l’ensemble d’un pod, définissez-le dans l’annotationseccomp.security.kubernetes.io/pod
. Cela garantit que tous les conteneurs du pod respectent la même politique de sécurité.
Exemple de manifeste avec profil Seccomp pour un pod complet : - Réévaluation continue des profils Seccomp
Les profils Seccomp doivent être réévalués régulièrement pour garantir qu’ils sont toujours adaptés aux besoins de l’application. Les mises à jour des applications peuvent entraîner des changements dans les appels système utilisés, nécessitant une mise à jour des profils Seccomp. - Utiliser
Seccomp
en mode trace lors du développement
Pendant le développement d’une application ou lors de la mise en place de nouveaux profils Seccomp, vous pouvez activer le mode de traçage (SCMP_ACT_TRACE
) pour observer les appels système effectués par un conteneur sans les bloquer immédiatement. Cela peut vous aider à affiner le profil avant de le rendre plus restrictif.Exemple de profil avec mode trace pour observer les appels système :
Bonnes pratiques pour la gestion de la sécurité avec AppArmor
- Utiliser des profils AppArmor pour chaque application spécifique
Chaque application dans un conteneur doit avoir un profil AppArmor spécifique. Cela permet de garantir que les applications ne peuvent pas interagir avec des ressources non autorisées, même si elles sont dans le même pod.- Créez des profils AppArmor dédiés pour les applications ayant des besoins en matière d’accès système différents.
- Assurez-vous que les profils sont suffisamment restrictifs pour minimiser l’impact d’une éventuelle compromission de l’application.
- Limiter les permissions d’accès aux fichiers système
Dans un profil AppArmor, évitez d’accorder des permissions d’accès trop larges à des fichiers sensibles. Limitez l’accès en lecture ou en écriture aux fichiers systèmes ou aux répertoires non nécessaires pour l’application.Exemple de profil AppArmor pour limiter l’accès aux fichiers système : - Utiliser
audit
pour surveiller les violations de sécurité
Utilisez l’actionaudit
dans les profils AppArmor pour enregistrer les tentatives d’accès qui sont refusées. Cela peut être utile pour identifier des comportements anormaux ou des tentatives d’exploitation sur des ressources sensibles.Exemple de profil AppArmor avec actionaudit
pour surveiller l’accès aux ressources interdites : - Vérifier les logs d’AppArmor
Après l’application des profils, surveillez les logs d’AppArmor pour toute tentative d’accès non autorisé. Les logs peuvent fournir des informations précieuses pour ajuster les profils en cas de failles ou de configurations erronées.Vous pouvez vérifier les logs avec la commande :bashCopy codegrep apparmor /var/log/syslog
- Testez les profils AppArmor avec des environnements isolés
Avant de déployer des profils AppArmor sur des applications en production, testez-les dans un environnement de test ou dans un environnement isolé pour valider qu’ils n’interfèrent pas avec le bon fonctionnement de l’application.
Stratégies de mise à jour et de maintenance des profils
- Versionner les profils Seccomp et AppArmor
Comme les profils Seccomp et AppArmor peuvent évoluer en fonction des mises à jour des applications, il est important de versionner les profils. Cela permet de suivre les modifications apportées et de revenir à une version antérieure si nécessaire. - Automatiser l’application des profils
Utilisez des outils d’automatisation (comme Helm, Kustomize ou des pipelines CI/CD) pour appliquer les profils Seccomp et AppArmor aux ressources Kubernetes. Cela vous permet de maintenir une gestion cohérente des profils à travers votre infrastructure. - Tester les changements de profils dans des environnements non critiques
Lors de l’ajout ou de la modification de profils Seccomp et AppArmor, testez d’abord dans des environnements de développement ou de staging avant de les appliquer en production.
Gestion des erreurs et des alertes de sécurité
- Configurer des alertes sur les violations de sécurité
En cas de violation des règles de sécurité définies dans les profils Seccomp ou AppArmor, configurez des alertes pour vous avertir de toute tentative d’accès non autorisée. Cela permet de réagir rapidement en cas d’incident de sécurité. - Revue régulière des logs de sécurité
Il est essentiel de revoir régulièrement les logs d’AppArmor et Seccomp pour détecter des tentatives d’exploitation potentielles. Cela peut être fait à l’aide de solutions de monitoring comme Prometheus ou Loki qui collectent et analysent les logs de sécurité.
8. Conclusion
Dans ce guide, nous avons exploré les mécanismes de sécurité Seccomp et AppArmor pour renforcer le contrôle d’accès et le confinement dans un environnement Kubernetes. Ces outils permettent de limiter la surface d’attaque des conteneurs et d’assurer une isolation robuste des applications, réduisant ainsi les risques de compromission du système hôte ou d’autres conteneurs.
Récapitulatif des points clés :
- Seccomp : Cette technologie se concentre sur la limitation des appels système qu’un conteneur peut effectuer. En appliquant des profils Seccomp, vous pouvez interdire des appels système spécifiques, ce qui réduit les possibilités d’exploitation des vulnérabilités au niveau du noyau. Nous avons abordé la création et l’application de profils Seccomp, ainsi que les meilleures pratiques pour leur gestion.
- AppArmor : Contrairement à Seccomp, AppArmor se concentre sur le contrôle des accès aux fichiers, périphériques et autres ressources du système. Il permet de définir des profils spécifiques pour chaque application ou conteneur, garantissant ainsi que les conteneurs n’accèdent pas à des ressources sensibles. Nous avons vu comment créer des profils AppArmor et les appliquer dans Kubernetes, ainsi que les meilleures pratiques pour leur utilisation.
- Comparaison et complémentarité : Seccomp et AppArmor sont des outils complémentaires qui se concentrent sur des aspects différents de la sécurité des conteneurs. Tandis que Seccomp bloque certains appels système, AppArmor restreint l’accès aux ressources du système. Leur utilisation conjointe permet de renforcer la sécurité des applications et des ressources.
- Meilleures pratiques : Nous avons souligné l’importance d’utiliser des profils stricts par défaut, de surveiller et de maintenir ces profils au fil du temps, et de tester les changements dans des environnements non critiques avant de les déployer en production. La gestion des erreurs et des alertes est également cruciale pour réagir rapidement aux tentatives de violation de sécurité.
Conseils pour aller plus loin :
- Automatisation : L’automatisation de l’application des profils Seccomp et AppArmor dans vos pipelines CI/CD et via des outils comme Helm ou Kustomize est fortement recommandée pour garantir la cohérence et la conformité à travers votre environnement Kubernetes.
- Surveillance : Intégrer des outils de monitoring et de logging, comme Prometheus et Loki, pour suivre l’application des profils et détecter toute violation ou comportement suspect dans les conteneurs.
- Mises à jour régulières : Étant donné que les applications évoluent, il est important de revoir et mettre à jour les profils Seccomp et AppArmor régulièrement pour garantir qu’ils restent adaptés aux nouveaux besoins de sécurité.
En appliquant Seccomp et AppArmor dans vos environnements Kubernetes, vous créez une couche de sécurité supplémentaire qui peut jouer un rôle essentiel dans la prévention des exploits et la réduction des risques de compromission.