Snyk @ Snyk : permettre aux développeurs de Snyk d’utiliser Kubernetes RBAC

Comme le disait un jour l’oncle Ben : « Un grand pouvoir implique de grandes responsabilités. » C’est aussi vrai pour l’API Kubernetes. Elle est très puissante et permet de créer des choses formidables, mais elle a un prix : un utilisateur malveillant peut aussi s’en servir pour faire du mal.

Voici Kubernetes RBAC (contrôle d’accès basé sur les rôles), qui permet d’utiliser l’API de manière contrôlée en n’accordant que les privilèges nécessaires, conformément au principe du moindre privilège.

Kubernetes permet aux utilisateurs de définir des rôles au sein des espaces de noms et des rôles de cluster en dehors des espaces de noms.

Mais cela ne fait que déplacer le problème : nous devons maintenant mettre en place de bonnes pratiques pour gérer les ressources RBAC, car une simple erreur de configuration RBAC pourrait avoir de graves conséquences sur la sécurité. Prenons l’exemple d’un développeur qui accorderait « par inadvertance » le rôle d’administrateur du cluster au compte de service par défaut dans l’espace de noms par défaut. Quelle horreur !

Photo de https://unsplash.com/@arnykoor

L’approche de la voie balisée pour sécuriser Kubernetes

Dans l’idéal, nous aimerions permettre à chaque développeur de créer les autorisations RBAC qu’il souhaite, tout en mettant en place des garde-fous pour assurer la protection et bloquer les éléments non sécurisés. Pour cela, on peut imposer une revue de code par l’équipe AppSec pour toute modification incluant des ressources RBAC. Cette approche pourrait fonctionner, mais elle présente quelques inconvénients :

• L’équipe AppSec devient un goulot d’étranglement et ralentit les développeurs.

• La sécurité devient une « magie » que seule l’équipe AppSec maîtrise, puisqu’aucune directive n’indique ce qu’elle recherche lors de l’examen de ces modifications.

• Nous renforçons les silos et empêchons les développeurs d’assumer leurs responsabilités en matière de sécurité, ce qui ne fait qu’aggraver le problème : l’équipe AppSec devient un goulot d’étranglement et ralentit les développeurs.

Liste de contrôle pour sécuriser Kubernetes RBAC

Chez Snyk, nous avons rencontré des problèmes similaires. Nous voulions donner plus d’autonomie à nos développeurs et leur permettre d’utiliser l’API Kubernetes sans les ralentir. Nous avons commencé par dresser une liste des exigences de sécurité applicables aux règles RBAC. Cette liste est assez courte et s’appuie principalement sur les benchmarks CIS Kubernetes :

• Pas de ressources ni de verbes génériques

• Pas de règles intégrées, car elles accordent trop d’autorisations

• Aucune liaison avec des comptes de service dans l’espace de noms par défaut (qui devrait être vide) ou dans l’espace de noms kube-system (qui héberge des charges de travail sensibles)

• Aucune liaison avec le compte de service par défaut

• Aucune autorisation dangereuse, comme la création de pods ou la lecture de secrets

Une fois notre liste établie, nous pouvons en faire plusieurs choses :

• La publier sous forme de directives internes et exiger que tous les objets RBAC respectent cette liste. Les critères ne relèvent alors plus de la « magie ».

• Demander à nos développeurs et ingénieurs en sécurité de documenter toute infraction à cette liste comme un risque de sécurité et d’en informer l’équipe AppSec.

• Solliciter des commentaires et inviter tous les développeurs à contribuer à la liste et à la mettre à jour afin de décloisonner les équipes.

• AUTOMATISATION. Après tout, une fois la liste établie, nous voulons rendre les tests incroyablement simples.

Automatiser les vérifications de configuration Kubernetes avec Snyk IaC

Fin 2020, Snyk a annoncé un nouveau produit : Snyk Infrastructure as Code (Snyk IaC). Snyk IaC intègre un ensemble de règles que nous pouvons utiliser pour tester notre code IaC, y compris les manifestes Kubernetes (et Terraform, mais ce sera pour un autre article). L’un des avantages de travailler chez Snyk, c’est d’avoir accès aux fonctionnalités en avant-première et, mieux encore, de pouvoir contribuer au produit.

Après avoir établi notre liste, nous avons donc contacté l’équipe Snyk IaC pour discuter de notre liste de contrôle Kubernetes RBAC. Et voilà ! Cinq nouvelles vérifications ont été ajoutées à Snyk IaC pour nous aider à automatiser nos contrôles de sécurité et à éviter que l’équipe AppSec ne devienne un goulot d’étranglement !

Rendre la sécurité IaC incroyablement simple pour les développeurs de Snyk

Snyk IaC peut effectuer des analyses via GitHub Actions et générer les résultats au format Sarif, qui peut être intégré à GitHub Security. Mais nous voulions aller plus loin et afficher directement les infractions dans nos PR, ce que Snyk IaC ne permet pas (encore). Notre équipe AppSec s’en est chargée en développant sa propre intégration GitHub : chaque modification de nos fichiers manifestes Kubernetes est automatiquement analysée par Snyk lors de sa validation et, en cas d’infraction, le développeur reçoit un avertissement bien visible dans la PR :

Désormais, tous nos développeurs peuvent modifier RBAC sans avoir à s’arrêter pour faire intervenir l’équipe AppSec. Et celle-ci peut dormir sur ses deux oreilles, sachant que Snyk veille au grain.

Vous souhaitez mettre en place quelque chose de similaire pour votre équipe ? Consultez l’exemple de dépôt ici et pensez à créer un compte Snyk : vous pouvez commencer gratuitement avec IaC !