kube-score se présente comme un outil d'analyse essentiel pour les objets Kubernetes, axé sur l'amélioration de la fiabilité et de la robustesse sécuritaire des déploiements. Ce document explore en détail la manière dont kube-score évalue les configurations de contexte de sécurité (Security Context) des conteneurs, offrant des recommandations pour minimiser les risques et renforcer la résilience de vos applications.
L'importance cruciale de la configuration du Contexte de Sécurité
Le Contexte de Sécurité (Security Context) dans Kubernetes constitue un pilier fondamental pour définir les attributs de sécurité au moment de l'exécution des conteneurs. Une configuraton judicieuse permet de restreindre les privilèges, d'isoler l'accès aux ressources et de prévenir les escalades de privilèges. Le module d'audit de sécurité de kube-score (score/security/security.go) effectue un examen exhaustif de ces paramètres cruciaux, garantissant l'application du principe du moindre privilège.
Dimensions clés de l'audit de contexte de sécurité par kube-score
1. Vérification du mode privilégié des conteneurs (Critique)
Un conteneur exécuté en mode privilégié dispose d'un accès quasi illimité au système hôte, ce qui représente l'une des configurations les plus dangereuses dans un environnement Kubernetes. La fonction containerSecurityContextPrivileged de kube-score (située dans score/security/security.go#L48-L64) effectue une vérification rigoureuse pour s'assurer que les conteneurs n'activent pas ce mode :
securityContext:
privileged: false # Indispensable pour désactiver les privilèges root sur l'hôte
Alerte de risque : Les conteneurs privilégiés peuvent interagir directement avec les périphériques de l'hôte et les fonctionnalités du noyau. Une compromission d'un tel conteneur peut entraîner la prise de contrôle complète du nœud. kube-score signale cette configuration avec une alerte de niveau Critical.
2. Configuration du système de fichiers racine en lecture seule (Critique)
Par défaut, le système de fichiers racine d'un conteneur est modifiable, ce qui ouvre une porte aux codes malveillants souhaitant altérer les fichiers système. L'inspection containerSecurityContextReadOnlyRootFilesystem de kube-score (dans score/security/security.go#L18-L46) s'assure que ce système de fichiers est configuré en lecture seule :
securityContext:
readOnlyRootFilesystem: true # Force le système de fichiers racine en lecture seule pour une sécurité accrue
Bonne pratique : Pour les données temporaires nécessitant une écriture, privilégiez l'utilisation de volumes emptyDir ou de volumes persistants, plutôt que de modifier directement le système de fichiers racine.
3. Plage sécurisée des identifiants utilisateur/groupe (Critique)
L'utilisation d'identifiants UID/GID faibles (inférieurs à 10000) peut potentiellement entrer en conflit avec les utilisateurs système de l'hôte, créant des risques de fuites de privilèges. La fonction containerSecurityContextUserGroupID de kube-score (accessible via score/security/security.go#L67-L109) applique des vérifications strictes :
securityContext:
runAsUser: 10001 # L'UID (User ID) doit être supérieur à 10000
runAsGroup: 10001 # Le GID (Group ID) doit être supérieur à 10000
fsGroup: 10001 # L'ID du groupe de fichiers doit également respecter cette exigence
Logique d'implémentation : kube-score examine les contextes de sécurité au niveau du Pod et du conteneur. Si aucune configuration n'est spécifiée au niveau du conteneur, celle du Pod est héritée, garantissant que tous les conteneurs utilisent des identifiants dans une plage élevée.
4. Configuration de la sécurité Seccomp (Avertissement)
Seccomp (Secure Computing Mode) offre un mécanisme pour limiter les appels système qu'un processus peut effectuer, réduisant ainsi la surface d'attaque du noyau. L'examen podSeccompProfile de kube-score (défini dans score/security/security.go#L112-L162) prend en charge les configurations via des annotations ou le bloc securityContext :
# Méthode 1 : Configuration du contexte de sécurité au niveau du Pod
securityContext:
seccompProfile:
type: RuntimeDefault # Utilise la politique seccomp par défaut de l'environnement d'exécution
# Méthode 2 : Via les annotations (pour la compatibilité avec les versions antérieures de Kubernetes)
annotations:
seccomp.security.alpha.kubernetes.io/defaultProfileName: runtime/default
Notes de priorité : La configuration du contexte de sécurité au niveau du Pod prime sur celle du conteneur. Il est recommandé de définir ces paramètres au niveau du Pod pour assurer une cohérence et une application uniforme de la politique Seccomp pour tous les conteneurs.
Configuration flexible des règles et migration
kube-score offre un contrôle granulaire sur ses vérifications. Depuis la version 1.10, la vérification unifiée container-security-context a été décomposée en trois audits distincts (détaillés dans README_SECURITYCONTEXT.md). Voici un exemple de commande pour activer ces vérifications spécifiques tout en ignorant l'ancienne :
kube-score score \
--ignore-test container-security-context \
--enable-optional-test container-security-context-privileged \
--enable-optional-test container-security-context-readonlyrootfilesystem \
--enable-optional-test container-security-context-user-group-id
Cette modularité permet aux utilisateurs d'activer sélectivement des vérifications spécifiques, par exemple, en relâchant temporairement les contraintes UID/GID dans certains scénarios, tout en maintenant une surveillance stricte sur le mode privilégié.
Conseils pratiques pour la gestion des conteneurs sécurisés
Gestion des conteneurs nécessitant une écriture temporaire
Lorsque des conteneurs requièrent un espace d'écriture temporaire, utilisez des volumes emptyDir plutôt que de rendre le système de fichiers racine inscriptible :
volumeMounts:
- name: cache-temporaire
mountPath: /var/cache/application
volumes:
- name: cache-temporaire
emptyDir: {}
Que faire si une image tierce ne permet pas de modifier l'UID ?
Si une image tierce ne permet pas de modifier l'UID, configurez runAsNonRoot: true pour garantir que le conteneur ne s'exécute pas avec l'utilisateur root. Cela offre une couche de protection fondamentale même si un UID bas est utilisé :
securityContext:
runAsNonRoot: true # Assure que le conteneur ne s'exécute pas en tant que root
Application à grande échelle des configurations de contexte de sécurité
Pour une application uniforme des configurations de sécurité à l'échelle du cluster, exploitez des webhooks de mutation (Mutating Admission Webhooks) ou des politiques Kubernetes, comme les Pod Security Standards ou des outils tels que Kyverno ou OPA Gatekeeper.
Conclusion : Établir une défense en profondeur pour la sécurité des conteneurs
Les audits de contexte de sécurité offerts par kube-score constituent une première ligne de défense indispensable pour les déploiements Kubernetes. En adhérant aux principes et pratiques détaillés ici, complétés par les exemples fournis dans les dépôts de tests de kube-score, vous pouvez renforcer la posture de sécurité de vos conteneurs :
- Principe du Moindre Privilège : Désactivez systématiquement le mode privilégié et configurez le système de fichiers racine en lecture seule.
- Isolation d'Identité : Utilisez des plages UID/GID élevées pour prévenir les conflits et les risques d'escalade de privilèges.
- Restriction des Appels Système : Implémentez des profils Seccomp pour réduire la surface d'attaque du noyau.
- Validation Continue : Intégrez kube-score dans votre pipeline CI/CD pour automatiser la vérification des configurations de sécurité.
Ces mesures conjointes contribuent à bâtir une fondation de sécurité robuste et à minimiser les risques inhérents à vos environnements Kubernetes.