Comment démarrer avec Kubernetes RBAC
Le contrôle d’accès basé sur les rôles (RBAC) est un mécanisme permettant de définir les actions que les comptes d’utilisateurs peuvent effectuer au sein de votre cluster Kubernetes. L’activation de RBAC réduit le risque associé au vol d’informations d’identification et à la prise de contrôle de compte. Accorder à chaque utilisateur l’ensemble minimum d’autorisations dont il a besoin empêche les comptes de devenir trop privilégiés.
Les distributions Kubernetes les plus populaires commencent avec un seul compte d’utilisateur qui accorde un accès superutilisateur au cluster. L’authentification en tant que ce compte vous permet d’effectuer n’importe quelle action, mais peut poser un risque de sécurité substantiel.
Dans cet article, nous allons montrer comment activer et configurer l’API Kubernetes RBAC afin que vous puissiez définir avec précision les capacités des utilisateurs. il est courant que certains utilisateurs créent et répertorient uniquement des pods tandis que les administrateurs peuvent également supprimer des éléments. Vous pouvez configurer et appliquer ces politiques à l’aide du système RBAC.
Sommaire
Activer RBAC dans Kubernetes
RBAC est une fonctionnalité facultative de Kubernetes, mais la plupart des distributions majeures sont livrées avec elle activée par défaut, y compris celles des fournisseurs de cloud gérés. Vous pouvez vérifier si RBAC est disponible dans votre cluster en exécutant la commande suivante avec Kubectl :
$ kubectl api-versions | grep rbac.authorization.k8s rbac.authorization.k8s.io/v1
La commande doit émettre rbac.authorization.k8s.io/v1 comme sortie si RBAC est activé. RBAC est désactivé si la commande ne produit aucune sortie. Vous pouvez l’activer en démarrant le serveur d’API Kubernetes avec le --authorization-mode=RBAC drapeau:
$ kube-apiserver --authorization-mode=RBAC
Reportez-vous à la documentation de votre distribution Kubernetes si vous ne savez pas comment personnaliser les arguments de démarrage du serveur d’API.
Objets RBAC Kubernetes
L’implémentation Kubernetes RBAC s’articule autour de quatre types d’objets différents. Vous pouvez gérer ces objets à l’aide de Kubectl, de la même manière que d’autres ressources Kubernetes telles que les pods, les déploiements et les ConfigMaps.
- Rôle – Un rôle est un ensemble de règles de contrôle d’accès qui définissent les actions que les utilisateurs peuvent effectuer.
- Liaison de rôle – Une « liaison » est un lien entre un rôle et un ou plusieurs sujets, qui peuvent être des utilisateurs ou des comptes de service. La liaison permet aux sujets d’effectuer n’importe laquelle des actions incluses dans le rôle ciblé.
Les rôles et les RoleBindings sont des objets à espace de noms. Ils doivent exister dans un espace de noms particulier et ils contrôlent l’accès aux autres objets qu’il contient. RBAC est appliqué aux ressources au niveau du cluster – telles que les nœuds et les espaces de noms eux-mêmes – en utilisant Rôles de cluster et ClusterRoleBindingsClusterRoleBindings. Celles-ci fonctionnent de la même manière que les rôles et les liaisons de rôle, mais ciblent des objets sans espace de noms.
Création d’un compte de service
Un compte de service Kubernetes est un type d’utilisateur géré par l’API Kubernetes. Chaque compte de service possède un jeton unique qui est utilisé comme identifiant. Vous ne pouvez pas ajouter d’utilisateurs normaux via l’API Kubernetes. Nous utiliserons donc un compte de service pour ce didacticiel.
Utilisez Kubectl pour créer un nouveau compte de service :
$ kubectl create serviceaccount demo
Cela produit un nouveau compte appelé demo. Ensuite, vous devez récupérer le jeton que vous utiliserez pour vous authentifier en tant que compte. Trouvez d’abord le nom du secret qui stocke le jeton :
$ kubectl describe serviceaccount demo Name: demo Namespace: default Labels: <none> Annotations: <none> Image pull secrets: <none> Mountable secrets: demo-token-w543b Tokens: demo-token-w543b Events: <none>
Le jeton de ce compte de service est stocké dans le secret appelé demo-token-w543b. Vous pouvez récupérer le jeton en obtenant la valeur du secret avec cette commande :
$ TOKEN=$(kubectl describe secret demo-token-w543b | grep token: | awk '{print $2}')
Le jeton est maintenant stocké dans le TOKEN variable dans votre shell. Vous pouvez utiliser cette variable pour ajouter un nouveau contexte Kubectl qui vous permettra de vous authentifier en tant que compte de service :
$ kubectl config set-credentials demo --token=$TOKEN User "demo" set. $ kubectl config set-context demo --cluster=default --user=demo Context "demo" created.
Vous devriez changer la valeur de --cluster flag pour correspondre au nom de votre connexion de cluster Kubectl active. C’est généralement default ou le nom de votre contexte actuellement sélectionné. Vous pouvez vérifier le contexte sélectionné en exécutant kubectl config current-context.
Basculez vers votre nouveau contexte pour vous authentifier en tant que votre demo compte de services. Notez d’abord le nom de votre contexte actuellement sélectionné, afin de pouvoir revenir ultérieurement à votre compte de superutilisateur.
$ kubectl config current-context default $ kubectl config use-context demo Switched to context "demo".
Les commandes Kubectl s’authentifieront désormais en tant que demo compte de services. Essayez de récupérer la liste des pods de votre cluster :
$ kubectl get pods Error from server (Forbidden): pods is forbidden: User "system:serviceaccount:default:demo" cannot list resource "pods" in API group "" in the namespace "default"
L’opération a été interdite parce que le demo le compte de service n’a pas de rôle lui permettant d’accéder aux pods.
Ajouter un rôle
Les rôles sont créés de la même manière que tout autre objet Kubernetes. Vous écrivez un fichier YAML qui définit le rôle et les autorisations qu’il fournit. Chaque rôle contient une ou plusieurs règles qui permettent d’effectuer des actions spécifiques sur un ensemble de ressources. Voici un rôle simple qui permet à un utilisateur de récupérer les détails des pods existants :
apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: namespace: default name: demo-role rules: - apiGroups: [""] resources: ["pods"] verbs: ["get", "list"]
La get et list verbes appliqués aux pods signifie que vous pourrez exécuter des commandes telles que get pod et describe pod. Essayer de créer un nouveau Pod, ou d’en supprimer un existant, sera interdit car le create et delete les verbes sont omis du rôle.
Revenez à votre contexte Kubectl d’origine afin de pouvoir ajouter le rôle à votre cluster à l’aide de votre compte administrateur :
$ kubectl config use-context default Switched to context "default".
Ajoutez maintenant le rôle :
$ kubectl apply -f role.yaml role.rbac.authorization.k8s.io/demo-role created
Associer des rôles aux utilisateurs et aux comptes de service
Vous pouvez maintenant associer votre rôle à votre demo compte de service en créant un nouveau RoleBinding. Créez le fichier YAML suivant pour définir votre liaison :
apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: namespace: default name: demo-role-binding subjects: - kind: ServiceAccount name: demo apiGroup: "" roleRef: kind: Role name: demo-role apiGroup: ""
Les RoleBindings doivent inclure un ou plusieurs sujets qui identifient les utilisateurs et les comptes de service ciblés par la liaison. La roleRef Le champ fait référence au rôle que vous souhaitez attribuer à chacun de ces utilisateurs.
Le rôle et le RoleBinding doivent exister dans le même espace de noms. Utilisez plutôt un ClusterRole et un ClusterRoleBinding pour les ressources sans espace de noms.
Prochaine exécution kubectl apply pour ajouter le RoleBinding à votre cluster. Il entrera en vigueur immédiatement, accordant au demo compte de service les capacités déclarées dans le demo-role Rôle:
$ kubectl apply -f role-binding.yaml rolebinding.rbac.authorization.k8s.io/demo-role-binding created
Test de votre règle RBAC
Testez votre implémentation RBAC simple en rebasculant vers le nouveau contexte Kubectl que vous avez créé pour le demo Compte:
$ kubectl config use-context demo Switched to context "demo".
Répétez maintenant la get pods commande antérieure :
$ kubectl get pods No resources found in default namespace.
Cette fois, la commande a réussi. La demo le compte de service est désormais autorisé à récupérer des listes de pods, car il est lié au demo-role Rôle. Une erreur Interdit s’affichera toujours si vous essayez de créer un nouveau pod, car cette opération n’est incluse dans aucun rôle lié au compte :
$ kubectl run nginx --image=nginx Error from server (Forbidden): pods is forbidden: User "system:serviceaccount:default:demo" cannot create resource "pods" in API group "" in the namespace "default"
Vous pouvez résoudre ce problème en attribuant à l’utilisateur un autre rôle qui inclut le create verbe pour le pods Ressource. Vous pouvez également modifier le fichier YAML de votre rôle existant et appliquer la version modifiée à votre cluster :
apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: namespace: default name: demo-role rules: - apiGroups: [""] resources: ["pods"] verbs: ["create", "get", "list"]
Vous pouvez également ajouter des règles supplémentaires à votre rôle pour créer différentes combinaisons de groupes de ressources et d’actions autorisées.
Sommaire
RBAC vous permet de définir les fonctionnalités logicielles disponibles pour les comptes d’utilisateurs individuels. Le système Kubernetes RBAC fournit des contrôles très précis pour limiter les types de ressources auxquelles les comptes peuvent accéder et les actions qu’ils sont autorisés à effectuer.
L’adoption de RBAC renforce la sécurité autour de votre cluster et crée un environnement d’exploitation moins risqué. Cependant, vous devez toujours garder à l’esprit les meilleures pratiques pour éviter d’introduire de nouveaux problèmes. Vous devez régulièrement auditer votre cluster pour identifier les comptes surprivilégiés et nettoyer les rôles redondants. Cela aidera à éviter toute confusion et vous permettra d’avoir une image claire des actions qui peuvent être prises par chaque compte.
Les implémentations RBAC efficaces doivent être basées sur le plus petit nombre possible de rôles, chaque rôle ayant l’ensemble minimum d’actions nécessaires pour son domaine de fonctionnalité spécifique. L’attribution d’un trop grand nombre de privilèges à chaque compte annule les avantages du RBAC. Il est donc utile de prendre le temps de planifier les besoins de chaque utilisateur avant de commencer à créer des rôles et des liaisons.
