Sécuriser le cluster Kubernetes est une chose, mais maintenir la sécurité reste un défi. Cependant, de nouveaux outils ont été ajoutés à Kubernetes: il est désormais beaucoup plus facile de faire les deux.
Kubernetes (à partir de la version 1.6) a introduit le concept de contrôle d'accès basé sur les rôles (RBAC), qui permet aux administrateurs de définir des politiques de restriction pour les utilisateurs du cluster. Autrement dit, vous créez un utilisateur avec un accès limité: limitez l'accès des utilisateurs aux ressources comme les secrets ou à certains espaces de noms.
Dans cet article, nous ne comprendrons pas comment implémenter RBAC. Il existe suffisamment de sources décentes où ce sujet est discuté de et vers:
Il est préférable de vous concentrer sur la façon de vous assurer que les exigences de votre entreprise sont remplies et de voir si les objets RBAC en cours d'exécution doivent être vérifiés pour voir s'ils remplissent leurs fonctions.
Notre script
Certaines organisations acceptent plusieurs groupes pour travailler avec le nouveau cluster Kubernetes. Il y a une exigence: vous ne pouvez pas interférer dans le déploiement d'un groupe voisin, afin qu'il n'y ait pas de problèmes ou de temps d'arrêt intergroupes imprévus.
Ainsi, le propriétaire du cluster a déployé RBAC dans le cluster, limitant ainsi l'accès à un espace de noms spécifique. La première vérification a montré que les groupes ne peuvent pas se voir les uns les autres dans l'espace de noms.
Une semaine s'est écoulée. Le propriétaire du cluster a remarqué qu'un utilisateur d'un espace de noms isolé lit les secrets d'un autre espace de noms. Comment ça? Il a utilisé RBAC!
Je l'ai appliqué, mais, comme pour travailler avec du code, la conformité du système avec le résultat souhaité doit être testée. Il est bon que l' kubectl kubectl CLI Kubernetes fournit un ensemble d'outils pour vérifier la configuration RBAC. kubectl auth can-i
Puis-je? ("Puis-je?")
can-i utilisant l'API vérifie simplement si une certaine action peut être effectuée. Il utilise les paramètres suivants: kubectl auth can-i VERB [TYPE | TYPE/NAME | NONRESOURCEURL] kubectl auth can-i VERB [TYPE | TYPE/NAME | NONRESOURCEURL] kubectl auth can-i VERB [TYPE | TYPE/NAME | NONRESOURCEURL] . L'utilisateur actuel peut maintenant vérifier si une action spécifique lui est disponible. C'est parti:
kubectl auth can-i create pods
Cela devrait retourner une réponse «oui» ou «non» avec le code de sortie approprié.
Cependant, lorsque nous essayons de vérifier les droits d'un autre utilisateur, nous rencontrons un problème: l'utilisateur sous lequel nous sommes autorisés dans le cluster est spécifié dans le fichier de configuration ./kube/config , et il n'est pas pratique d'avoir des configurations distinctes pour tester des utilisateurs individuels. Heureusement, Kubernetes vient à la rescousse: il est capable de simuler des utilisateurs en utilisant les étiquettes --as= et --as-group= .
Mettez à jour la commande, utilisez la simulation d'un autre utilisateur:
kubectl auth can-i create pods --as=me
Nous devons voir qu'avec le code de sortie 1 , la réponse «non» est retournée.
Et c'est formidable, car nous avons maintenant un ensemble de commandes qui nous permettent de vérifier si un utilisateur ou un groupe d'utilisateurs a accès à l'une des ressources de Kubernetes - de l'affichage des pods à la suppression des secrets.
Automatisation
Cependant, il est trop tôt pour arrêter: nous pouvons maintenant implémenter une séquence de test qui décrira la liste des exigences et l'exécutera dans le cadre du pipeline de CD. Pour la cause!
Il y a beaucoup de choix, il y a suffisamment de langages à implémenter: en commençant par Ava et Mocha en JavaScript et en terminant par Rspec. Dans ce cas, j'implémente le cadre de test purement Bash Bats .
Voici un exemple d'exécution d'un test. Il vérifie le fonctionnement des règles RBAC qui permettent à un utilisateur d'un groupe de modifier le nombre de foyers en cours d'exécution dans l'espace de noms. Il est exécuté si l'attribut «exécutable» a été défini. Ou - en utilisant le bats filename .
#!/usr/bin/env bats @test "Team namespaces can scale deployments within their own namespace" { run kubectl auth can-i update deployments.apps --subresource="scale" --as-group="$group" --as="$user" -n $ns [ "$status" -eq 0 ] [ "$output" == "yes" ] done }
Les commandes --as et --as-group nécessitent l'utilisation des règles RBAC suivantes:
rules: - apiGroups: - authorization.k8s.io resources: - selfsubjectaccessreviews - selfsubjectrulesreviews verbs: - create
Voici une méthode simple pour implémenter des contrôles sur vos règles RBAC dans Kubernetes. En l'intégrant au pipeline Kubernetes, nous renforcerons considérablement la politique de RBAC. La méthode a été testée dans la pratique: la capture des modifications qui violent les politiques d'accès est beaucoup plus rapide!
Merci d'avoir pris le temps de lire cet article!