De la sécurité des images à celle des workloads
31 octobre 2019
0 minutes de lectureVoici la troisième partie d’une série en quatre volets consacrée à la création d’une stratégie AppSec pour Kubernetes. Retrouvez la première partie ici et la deuxième partie ici.
Dans l’un de nos précédents articles, nous avons évoqué le transfert du packaging des applications aux développeurs, à mesure que les entreprises adoptent les conteneurs. Mais le packaging n’est pas le seul domaine qui passe de l’administration système au développement : c’est aussi le cas de la gestion de la configuration.
Kubernetes et les défis de la configuration
L’API Kubernetes est une abstraction puissante pour créer des systèmes cloud natifs. Mais cette API riche a eu pour conséquence inattendue d’amener les développeurs à rédiger manuellement de grandes quantités de configuration, principalement en YAML. Prenons par exemple cette description d’un déploiement Kubernetes :
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.7.9
ports:
- containerPort: 80
Ces fichiers de configuration sont souvent stockés dans des systèmes de gestion de code source, parfois avec le code de l’application, parfois séparément. À eux seuls, GitHub en héberge publiquement plus de 1,5 million.
Une configuration non sécurisée par défaut
Malheureusement, l’étendue des options de configuration de Kubernetes ouvre la voie à plusieurs problèmes de sécurité. La présentation The Path Less Travelled d’Ian Coldwater et Duffie Cooley résume bien certains problèmes liés aux paramètres par défaut de Kubernetes du point de vue de la sécurité. Voici quelques propriétés de configuration courantes qui restent souvent non configurées :
Limites de CPU et de mémoire | Définir des limites de CPU et de mémoire adaptées présente des avantages opérationnels et de sécurité. Dans le contexte de la sécurité, il s’agit de limiter l’impact potentiel des attaques par déni de service sur l’application, plutôt que sur le nœud, voire sur l’ensemble du cluster. |
runAsNonRoot | Par défaut, les conteneurs s’exécutent en tant qu’utilisateur root. Cette propriété l’empêche au niveau du runtime du conteneur. Ainsi, si un attaquant parvient à exécuter une commande dans le contexte du conteneur, ses permissions restent limitées. |
readOnlyRootFilesystem | Par défaut, le système de fichiers monté pour le conteneur est accessible en écriture. Un attaquant qui compromet le conteneur peut donc également écrire sur le disque, ce qui facilite certaines attaques. Si vos conteneurs sont sans état, vous n’avez pas besoin d’un système de fichiers accessible en écriture. |
Capacités | Les capacités Linux contrôlent à bas niveau les actions des processus dans le conteneur, de l’écriture sur le disque à la communication sur le réseau. Il est possible de supprimer toutes les capacités, puis d’ajouter celles qui sont nécessaires, mais cela suppose de bien connaître la liste des capacités. |
Ces propriétés de configuration ne sont pas des vulnérabilités en soi, mais elles facilitent généralement l’exploitation d’une vulnérabilité dans une image. En cas d’exploitation, elles peuvent amplifier les dégâts. Votre niveau de risque ne dépend pas uniquement des vulnérabilités présentes, mais aussi du contexte dans lequel elles se trouvent.
La configuration tout au long du SDLC
À mesure que les responsabilités en matière de sécurité passent aux développeurs, comme c’est le cas pour les vulnérabilités des images, il est intéressant d’examiner les défis liés à la sécurisation de la configuration à travers le prisme du SDLC.
Étape | Description | Retour d’information | Exhaustivité |
En local | Outils locaux aidant à rédiger une configuration sécurisée, de l’intégration aux workflows de tests unitaires aux suggestions dans les IDE. Ils résolvent toutefois des problèmes individuels plutôt que ceux d’une équipe ou d’une organisation. | Rapide | Faible |
CI/CD | Échouer rapidement lors du build si des fichiers de configuration sont potentiellement non sécurisés ou ne respectent pas certaines règles internes. Il faut toutefois mettre en place cette vérification dans tous les pipelines concernés. | Rapide | Variable |
Dépôt | La configuration est aujourd’hui principalement stockée dans un système de gestion de code source (à noter toutefois que Helm 3 permet de stocker des images dans des registres OCI compatibles). Comment aider les développeurs à rédiger une configuration sécurisée entre l’envoi des pull requests et la création des branches ? | Moyen | Moyen |
Admission | Les contrôleurs d’admission Kubernetes bloquent les requêtes API et permettent d’empêcher les configurations non sécurisées interdites. Les clusters peuvent toutefois appliquer des règles différentes, et cela concerne les nouvelles requêtes, pas les workloads existants. | Lent | Élevé |
Production | L’API Kubernetes représente la configuration en cours d’exécution : c’est là qu’il faut accorder le plus d’attention à la configuration. Mais les problèmes à ce stade peuvent affecter des workloads réels, et les cycles de retour d’information nécessaires pour les corriger peuvent être longs. | Lent | Élevé |
Comme pour les tests des images de conteneurs, les compromis varient selon les étapes. Tester à une seule étape peut permettre d’obtenir rapidement un retour d’information, mais avec moins de contrôle, ou inversement. De même, comme pour les vulnérabilités des images, un processus de sécurité moderne et mature implique probablement de tester la configuration à plusieurs étapes.
Conclusion
Nos applications ne se limitent pas aux images utilisées pour les packager : elles comprennent aussi la configuration nécessaire à leur exécution. Jusqu’ici, nous avons considéré ces deux domaines comme distincts en matière de sécurité. Pourtant, dans la plupart des cas, les discussions sur la sécurité des conteneurs pour les développeurs se sont concentrées exclusivement sur les vulnérabilités des images. À mesure que la responsabilité de la sécurité des applications passe aux équipes de développement, il devient de plus en plus important de comprendre le lien entre les vulnérabilités des images et la configuration, et de disposer d’outils pour sécuriser les deux.
Lancez-vous dans les compétitions Capture The Flag
Apprenez à résoudre des défis Capture The Flag en regardant à la demande notre atelier virtuel d’initiation.
