Sécuriser votre cluster Kubernetes est une chose, le garder sécurisé est une lutte acharnée continue. Cependant, avec l’introduction de nouvelles fonctionnalités dans Kubernetes, il devient beaucoup plus facile de faire les deux et surtout teste les rbac .
Kubernetes (à partir de la version 1.6) a introduit le concept de ( RBAC ), permet aux administrateurs de définir des politiques pour restreindre les actions des utilisateurs de votre cluster.
Cela signifie qu’il est possible de créer un utilisateur avec un accès limité, vous permettant de restreindre l’accès à des ressources telles que Secrets, ou en limitant l’accès à un namespace.
Cet article de blog n’examinera pas comment les mettre en œuvre, car il existe de nombreuses sources d’informations qui le couvrent en détail:
https://www.cncf.io/blog/2018/08/01/demystifying-rbac-in-kubernetes/
https://docs.bitnami.com/kubernetes/how-to/configure-rbac-in-your-kubernetes-cluster/
https://kubernetes.io/docs/reference/access-authn-authz/rbac/
https://digicactus.com/openshift-role-based-access-control-rbac/
En conséquence, nous allons nous concentrer sur la manière de garantir le respect de la conformité et des exigences de notre entreprise et de nous assurer que nous devons tester nos objets rbac appliqués sur Kubernetes pour nous assurer qu’ils font ce que nous avons l’intention de leur faire.
Scénario pour tester vos RBAC Kubernetes
Chez un client on vient d’installer des nouveaux clusters Kubernetes,et on doit commencer à intégrer les équipes sur ces clusters .
Une exigence pour que ces équipes soient intégrées aux clusters était que chaque équipe ne soit pas autorisée à modifier le déploiement d’une autre et provoque des problèmes inter-équipes imprévus .
L’équipe qui s’occupe de l’administration de la plateforme Kubernetes a récemment déployé des RBAC sur le cluster, limitant l’accès des membres d’une équipe à un Namespace.
les premières équipes connectée teste et n’affiche que les pods de leurs namespaces .
Une semaine plupart, l’équipe de la plateforme commence à remarquer qu’un utilisateur d’un namespace restreint a lu des secrets d’autres.
Mais comment est-il possible? N’ont-ils pas mis en œuvre des RBAC? Eh bien, ils l’ont fait, mais comme pour le code, nous devons tester notre système par rapport au résultat souhaité. Heureusement, l’outil CLI de Kubernetes kubectl nous fournit des outils qui nous permettent de tester notre configuration RBAC.
kubectl auth can-i
Can-I?
can-i vérifie simplement cela avec l’API pour voir si une action peut être effectuée. Il peut prendre les options suivantes
kubectl auth can-i VERB [TYPE | TYPE/NAME | NONRESOURCEURL].
Et maintenant, il est possible pour l’utilisateur actuel de vérifier s’il ne peut pas effectuer une action.
Essayons ceci:
kubectl auth can-i create pods
Cela devrait renvoyer un «Yes» ou un «No» avec un code de sortie correspondant.
Mais dès qu’on essaie de tester l’autorisation pour un autre utilisateur, on tombe sur une pierre d’achoppement, avec la commande ci-dessus on ne peut tester qu’en utilisant le contexte actuellement chargé ./kube/config, il est tout à fait déraisonnable d’avoir un fichier par type d’utilisateur!
Mais heureusement, Kubernetes vient à nouveau à la rescousse avec la possibilité d’usurper l’identité des utilisateurs avec –as= et –as-group= .
Mettons à jour notre commande pour utiliser l’emprunt d’identité d’un autre utilisateur:
kubectl auth can-i create pods --as=me
Nous devrions voir que nous obtenons maintenant un «No» retourné avec un code de sortie d’ 1être retourné.
C’est une excellente nouvelle, nous avons maintenant un ensemble de commandes qui nous permettent de tester si un utilisateur ou un groupe on accès à des ressources Kubernetes.
Automatiser vos Teste RBAC Kubernetes
Nous ne devons pas nous arrêter là, nous avons maintenant ouvert la voie à la mise en œuvre d’une suite de tests qui peut décrire la liste des exigences et avoir la possibilité de l’exécuter dans le cadre de notre pipeline de livraison continue.
Nous avons tellement de choix et de langues pour implémenter cela, Dans notre cas, nous allons utiliser une implémentation pure Ansible .
Vous trouverez ci-dessous un exemple qui test si un utilisateur peut mettre à l’échelle des déploiements dans son propre espace de noms.
Il peut être exécuté comme n’importe quel role ansible dans un playbook.
# tasks file for test rbac - name: Création des groupes shell: "kubectl auth can-i update deployments.apps --subresource="scale" --as-group="{{ product.name }}-{{ group }}" -n{{ product.name }}-{{ item }}" register: result changed_when: "'unchanged' not in result.stdout"
Et comme ça, nous disposant d’une méthode simple pour mettre en œuvre des teste pour vos règles RBAC dans Kubernetes.
Avec cela dans le cadre de notre pipeline de livraison continue de Kubernetes,
nous devrions maintenant avoir une application de stratégie RBAC beaucoup plus robuste qui a été testée pour fonctionner.
Merci d’avoir pris le temps de lire!
