Le guide complet du RBAC sur Kubernetes

Introduction au RBAC

Qu’est-ce que le RBAC sur Kubernetes ?

Le RBAC est un système de gestion des permissions se basant sur des rôles définis, ces rôles déterminent l’accès aux ressources. Un utilisateur lambda ayant le rôle « user » aura, par exemple, accès à moins de ressources qu’un administrateur ayant le rôle « admin ».

Pour Kubernetes, ces rôles peuvent être attribués à :

• Des utilisateurs
• Des groupes
• Des comptes de service (service account)

Comment fonctionne le RBAC sur Kubernetes ?

Pour activer le RBAC, le serveur API Kubernetes doit être démarré avec l’option --authorization-mode incluant RBAC. Le RBAC repose sur les objets Kubernetes suivants :

• Role
• ClusterRole
• RoleBinding
• ClusterRoleBinding

Ces objets définissent les permissions au niveau d’un namespace, du cluster entier, et leur association avec des utilisateurs ou des groupes.

Le RBAC contrôle l’accès aux API Kubernetes tandis que les Network Policies régulent le trafic réseau entre les pods. Ces deux systèmes fonctionnent en parallèle pour sécuriser les clusters.

Le RBAC peut affecter les performances de votre système si un grand nombre de règles ou de role bindings sont appliquées. Néanmoins, les impacts sont souvent minimes et les bénéfices en termes de sécurité sont immenses.

Vous souhaitez efficacement automatiser la gestion de vos conteneurs ? Notre formation Kubernetes en inter et intraentreprise vous enseignera les meilleures pratiques.

L’équipe Ambient IT

Le RBAC en profondeur

Quels sont les composants principaux du RBAC sur Kubernetes ?

Les composants clés du RBAC :

• Le Role et le ClusterRole définissent les actions autorisées sur un ensemble de ressources
• Le RoleBinding et le ClusterRoleBinding lient les rôles aux sujets (utilisateurs, groupes, comptes de service)

Comment définir ses politiques d’accès avec le RBAC ?

Pour définir ses policies, veuillez suivre ces étapes :

1. En créant des objets Role ou ClusterRole avec des règles spécifiant les verbes (get, watch, list, create…)
2. Spécifier les ressources (pods, secrets…)
3. Liés aux sujets à travers des RoleBindings ou ClusterRoleBindings

Les Différences entre les rôles et les clusterroles

• Role est un objet qui définit les permissions au sein d’un namespace spécifique.
• Contrairement au Role, ClusterRole est un objet qui définit les permissions à l’échelle du cluster entier ou sur un ensemble de namespaces.
• RoleBinding lie un Role à des sujets dans un namespace particulier, conférant les permissions définies dans ce Role aux sujets liés.
• ClusterRoleBinding fait de même, mais à l’échelle du cluster, permettant d’attribuer des permissions définies dans un ClusterRole sur l’ensemble des namespaces ou globalement au cluster.

Les bonnes pratiques du RBAC sur Kubernetes

La gestion granulaire des accès

Nous entendons par gestion granulaire, une politique d’accès des ressources restreintes, précises et adaptées. Comme seules les personnes habilitées auront les permissions d’accéder à de précises ressources informatiques, la sécurité de votre infrastructure est grandement renforcée.

Voici les bonnes pratiques pour une gestion granulaire des accès sur k8s :

• Séparer les préoccupations en créant des rôles spécifiques pour différentes fonctions au sein de l’organisation
• Utiliser les ClusterRoles agrégés pour regrouper des permissions communes
• Limiter les permissions importantes comme cluster-admin
• Éviter les astérisques pour les ressources et les verbes pour ne pas donner un accès trop important

Ces bonnes pratiques s’appliquent également dans un environnement multi-tenant.

auditer les permissions et détecter les sur-autorisations

L’audit des permissions peut être effectué :

• En utilisant des commandes comme kubectl auth can-i pour vérifier les permissions d’un sujet
• En inspectant les règles définies dans les rôles et les liaisons de rôles
• Grâce à des services tiers pour une analyse approfondie des politiques RBAC

Avant d’appliquer une configuration RBAC, il est possible d’utiliser kubectl auth reconcile avec l’option --dry-run pour visualiser ses changements. Ainsi, vous pourrez tester votre politique avant sa mise en production.

Ne pas impacter la disponibilité des services

Pour modifier des rôles sans affecter la disponibilité des services, tester ses changements dans un environnement de staging en s’assurant que les services ne dépendent pas de permissions qui seront modifiées ou supprimées.

Intégration et outils

Les commandes à connaître

• kubectl create role permet de créer un rôle avec une règle unique
• kubectl create rolebinding permet de créer un role binding pour un role ou un cluster role particulier
• kubectl create clusterrole permet de créer un cluster role
• kubectl create clusterrolebinding permet de créer un cluster role binding pour un cluster role particulier

La liste des meilleurs outils ou plugins tiers de RBAC sur Kubernetes

• kube-who-can montre les différentes permissions d’accès RBAC
• RBAC Lookup permet de facilement trouver les rôles de n’importe quel sujet sur un cluster
• Audit2rbac génère automatiquement des policies basées sur les logs Kubernetes
• Krane est un outil pour l’analyse et la visualisation de sa politique RBAC
• Helm et Kustomize peuvent automatiser le déploiement et la gestion des politiques RBAC

Comment intégrer son RBAC avec LDAP ou Active Directory ?

Pour intégrer son RBAC avec des systèmes d’authentification externes comme LDAP ou Active Directory, utilisez des connecteurs ou des proxies d’authentification pour transformer vos identités en sujets Kubernetes. Ces sujets sont ensuite utilisés dans les RoleBindings et ClusterRoleBindings.

Les erreurs courantes à éviter

Des permissions trop larges

N’oubliez pas de respecter le principe du moindre privilège en autorisant uniquement les accès nécessaires pour chaque groupe d’individus au sein de votre organisation. Ainsi, vous limitez les failles de sécurité.

Mal configurer des namespaces ou des api Groups

Pour les namespaces, il est important d’isoler son environnement de développement, de test et de production pour éviter qu’un environnement affecte les autres. Il faut également appliquer des politiques de sécurité à ce niveau pour contrôler le trafic du réseau.

Pour les API groups, activer l’audit au niveau du serveur API pour identifier les comportements anormaux. assurez-vous que votre cluster Kubernetes soit à jour et que vous utilisez des CRDs (Custom Resources Definition) sécurisés.

Oublier de supprimer des permissions

Il est courant d’oublier de supprimer les permissions d’un employé après son départ. Pour s’assurer de la modification de ses accès, il est préférable d’avoir recours à l’automatisation grâce à l’utilisation d’outil tiers comme Puppet ou de scripts personnalisés.

À retenir

La maîtrise du RBAC est un incontournable pour sécuriser vos clusters Kubernetes. Bien configuré, il assure que les utilisateurs, les groupes et les comptes de service disposent uniquement des permissions nécessaires.

Pour une bonne configuration de votre RBAC, vous devez vous assurer de respecter le principe du moindre privilège et auditer régulièrement votre configuration.

Pour rester informé des évolutions du RBAC sur Kubernetes, n’hésitez pas à suivre les notes de version de Kubernetes ainsi que les dernières innovations en termes de sécurité informatique.