Appliquer le principe du moindre privilège à Kubernetes avec RBAC

Lorsqu’il est correctement configuré, un utilisateur non autorisé ne peut ni accéder aux fonctionnalités restreintes d’une application ni changer de rôle. Il ne peut pas non plus accéder à certaines données, comme des fichiers ou des secrets d’API, sauf si cela est nécessaire pour accomplir une tâche qui lui a été attribuée. Cela contribue à protéger les systèmes contre les conséquences, intentionnelles ou non, d’actions non autorisées.

Dans les locaux d’une entreprise, l’accès à certaines zones, comme les salles de serveurs, est réservé aux employés autorisés à y travailler. Certains espaces critiques ne sont accessibles qu’aux membres expérimentés ou seniors des équipes concernées.

La même logique s’applique au PoLP. Par exemple, dans un logiciel de gestion du personnel, les dossiers des employés ne seraient probablement accessibles qu’aux responsables des ressources humaines. De même, certaines actions, comme le déploiement de versions d’une application en production, peuvent être réservées aux ingénieurs seniors.

Le PoLP s’applique également aux applications SaaS (logiciel en tant que service), dans lesquelles les utilisateurs disposent de rôles différents selon les tâches qu’ils doivent effectuer.

La protection des systèmes logiciels exige de trouver un équilibre : le système ne doit pas être trop restrictif pour les parties prenantes, ni trop vulnérable aux acteurs malveillants. Le PoLP nous aide à atteindre cet équilibre en assurant la sécurité du système tout en réduisant les contraintes liées aux accès.

De plus, le PoLP contribue à préserver l’efficacité et la fiabilité des opérations. Les systèmes sont moins exposés aux interruptions causées par des attaques par des logiciels malveillants ou par des activités risquées des utilisateurs, comme la mise en production de code non sécurisé ou la modification des mots de passe administrateur.

Dans cet article, nous verrons comment Kubernetes (K8s) applique le PoLP grâce au contrôle d’accès basé sur les rôles.

Appliquer le principe du moindre privilège aux accès Kubernetes

Kubernetes orchestre les charges de travail conteneurisées. Cette plateforme permet aux organisations et aux développeurs d’automatiser le déploiement, la gestion et la mise à l’échelle des applications conteneurisées. Les membres des équipes de développement, d’exploitation et informatiques doivent donc accéder à l’environnement Kubernetes pour créer ou maintenir les applications déployées.

Pour garantir une sécurité optimale et protéger leurs ressources, les organisations doivent appliquer le PoLP lorsqu’elles utilisent Kubernetes, quelle que soit l’étape de production. Heureusement, Kubernetes intègre des mécanismes d’authentification et d’autorisation qui permettent de contrôler les accès. Les équipes doivent définir explicitement qui peut accéder à quelles ressources opérationnelles et avec quelles autorisations lors des interactions avec l’API Kubernetes. Les organisations doivent également désactiver les accès non authentifiés, qu’ils soient effectués par des personnes ou des comptes de service.

Comment Kubernetes gère les accès avec RBAC

Le contrôle d’accès basé sur les rôles (RBAC) est une méthode utilisée dans de nombreux systèmes pour définir les autorisations sur les ressources en fonction des rôles des personnes dans l’environnement. Kubernetes dispose d’un mécanisme RBAC natif complet, qui permet de configurer les autorisations définissant la manière dont un utilisateur ou un groupe d’utilisateurs peut interagir avec les objets Kubernetes d’un cluster. Utiliser ce cadre RBAC est une première étape pour sécuriser un cluster et ses applications conteneurisées.

Les objets Kubernetes sont des entités persistantes qui précisent quelles applications conteneurisées sont exécutées, quelles ressources elles utilisent et quelles règles régissent leur fonctionnement. En somme, ils définissent l’état souhaité du cluster. Nous pouvons créer, modifier ou supprimer des objets avec l’API Kubernetes.

Dans Kubernetes, il existe deux types de comptes : les comptes utilisateur et les comptes de service. Les comptes utilisateur sont destinés aux personnes qui utilisent le système, tandis que les comptes de service sont associés aux processus qui accèdent à l’API Kubernetes. RBAC dans Kubernetes contrôle l’accès de ces comptes aux ressources, notamment aux pods, aux secrets, aux contrôleurs et aux définitions de ressources personnalisées (CRD).

Dans Kubernetes, les autorisations sont définies avec des objets Role ou ClusterRole. Les autorisations ainsi définies sont ensuite attribuées sous forme de règles à l’aide des objets RoleBinding et ClusterRoleBinding. L’API RBAC déclare les quatre types d’objets Kubernetes suivants :

• Role — gère les autorisations qui s’appliquent aux ressources d’un espace de noms donné

• ClusterRole — gère les autorisations qui s’appliquent à l’ensemble d’un cluster

• RoleBinding — attribue un Role à un compte ou à un groupe dans un espace de noms donné

• ClusterRoleBinding — attribue un ClusterRole à un compte ou à un groupe dans tous les espaces de noms du cluster

Dans les deux sections suivantes, nous verrons comment les règles RBAC appliquent le PoLP pour limiter l’accès aux ressources des clusters.

Définir les autorisations

Pour définir correctement les autorisations, vous devez configurer Kubernetes afin qu’il reflète le rôle de chaque membre de l’équipe, en tenant compte du PoLP. Les objets Role et ClusterRole sont un moyen particulièrement efficace d’y parvenir. Les objets Role s’appliquent aux ressources d’un seul espace de noms, tandis que les objets ClusterRole s’appliquent aux ressources de l’ensemble du cluster.

Dans cette section, nous verrons comment restreindre l’accès à certaines parties d’un système avec les objets Role et ClusterRole.

Prenons l’exemple d’une entreprise qui vient d’embaucher un ingénieur DevOps senior. Celui-ci doit pouvoir consulter toutes les variables d’environnement et les autres secrets, contrairement aux membres de son équipe. En outre, en tant que membre de l’équipe d’exploitation, cet ingénieur peut avoir besoin de consulter les pods créés pour les charges de travail applicatives de l’entreprise afin de surveiller l’état des conteneurs qui hébergent les applications côté client.

Pour cela, commencez par définir les objets Role et ClusterRole dans votre fichier YAML. Voici un exemple de définition d’un objet Role permettant d’accéder en lecture aux secrets de l’espace de noms development :

1apiVersion: rbac.authorization.k8s.io/v1
2kind: Role
3metadata:
4  namespace: development
5  name: secret-reader
6rules:
7- apiGroups: [""]
8  resources: ["secrets"]
9  verbs: ["get", "watch", "list"]

Le code ci-dessus indique la version de l’API. RBAC utilise le groupe d’API rbac.authorization.k8s.io pour configurer les règles d’autorisation via l’API Kubernetes. Il précise ensuite le type de définition (Role), puis l’espace de noms auquel elle s’applique : development. Cela suppose que development est l’espace de noms des ressources utilisées par l’équipe de développement. Enfin, le Role est nommé secretpod-reader.

La section rules contient les ressources concernées par la règle, ainsi que les actions que le Role peut effectuer sur ces ressources. Elle inclut également des verbes de règle. Kubernetes utilise des verbes comme write, watch, read et delete pour gérer les autorisations par grandes catégories.

Voici comment définir un ClusterRole pour autoriser l’accès en lecture aux pods front-end du cluster :

1apiVersion: rbac.authorization.k8s.io/v1
2kind: ClusterRole
3metadata:
4  name: pod-reader
5rules:
6- apiGroups: [""]
7  resources: ["pods"]
8  verbs: ["get", "watch", "list"

Remarquez que le code ci-dessus ne précise pas l’espace de noms dans les métadonnées. En effet, les ClusterRole ne sont pas associés à un espace de noms. Dans la section des métadonnées, vous avez donc uniquement indiqué le nom du ClusterRole : pod-reader.

Vous pouvez ensuite associer le Role au groupe de ressources de l’espace de noms development, et le ClusterRole au cluster. Votre équipe, et personne d’autre, peut alors consulter les secrets nécessaires dans les ressources de développement. Appliquer le PoLP de cette manière permet à votre équipe d’accéder aux éléments dont elle a besoin pour ses tâches de développement, tout en empêchant les autres membres de l’organisation d’accéder à ces pods et à ces ressources.

Vous avez créé un Role permettant à l’ingénieur DevOps d’accéder aux secrets, ainsi qu’un ClusterRole permettant à toute l’équipe DevOps de consulter les pods. Dans la section suivante, vous attribuerez les autorisations au Role et au ClusterRole.

Attribuer les autorisations

La liaison de rôle est utile, par exemple, lorsqu’un employé en particulier doit accéder aux clés secrètes utilisées dans la configuration d’une application. Il peut s’agir de paires de clés d’API ou de variables d’environnement.

De plus, nous devons utiliser une liaison de cluster pour accorder des autorisations à l’échelle d’un cluster. Une liaison de cluster peut permettre à n’importe quel utilisateur associé au rôle de cluster spécifié de lire les pods où qu’ils se trouvent dans le cluster, quel que soit leur espace de noms.

Si l’ingénieur DevOps est un utilisateur nommé Sola, vous pouvez attribuer à l’utilisateur sola le Role créé précédemment dans l’espace de noms development. Ainsi, sola pourra lire les secrets de cet espace de noms.

Notez que le nom sola est sensible à la casse. Voici la définition du RoleBinding :

1apiVersion: rbac.authorization.k8s.io/v1
2kind: RoleBinding
3metadata:
4  name: secret-reader
5  namespace: development
6subjects:
7- kind: User
8  name: sola
9  apiGroup: rbac.authorization.k8s.io
10roleRef:
11  kind: Role
12  name: secret-reader 
13  apiGroup: rbac.authorization.k8s.io

Dans le code ci-dessus, vous avez :

• Indiqué le type RoleBinding.

• Indiqué un Role nommé secret-reader et l’espace de noms development auquel le RoleBinding s’applique.

• Indiqué sola comme User dans la section subjects. Vous pouvez également préciser plusieurs sujets.

• Associé le Role correspondant à la liaison dans la section roleRef. N’oubliez pas qu’une fois la liaison créée, le Role ou le ClusterRole qui lui est associé dans la section roleRef ne peut plus être modifié.

L’exemple de RoleBinding ci-dessus convient aux cas où un membre de l’équipe de développement doit accéder aux clés secrètes utilisées dans la configuration d’une application, comme les paires de clés d’API et les variables d’environnement.

Pour accorder des autorisations à l’échelle d’un cluster, vous devez ensuite utiliser ClusterBinding. Dans l’exemple suivant, vous verrez comment ClusterBinding peut permettre à tout utilisateur du groupe ops de lire les pods dans n’importe quel espace de noms du cluster. Notez que le nom ops est sensible à la casse :

1apiVersion: rbac.authorization.k8s.io/v1
2kind: ClusterRoleBinding
3metadata:
4  name: read-pods-global
5subjects:
6- kind: Group
7  name: ops
8  apiGroup: rbac.authorization.k8s.io
9roleRef:
10  kind: ClusterRole
11  name: pod-reader
12  apiGroup: rbac.authorization.k8s.io

La liaison de cluster est utile dans les situations comme celle de l’exemple ci-dessus, où nous devons autoriser tous les membres de l’équipe à accéder à l’ensemble des pods du cluster. Une fois chaque autorisation définie correctement, les utilisateurs du groupe peuvent consulter les pods et évaluer leur état, afin de réaliser les rapports requis et d’assumer leurs responsabilités de surveillance. Dans le même temps, les définitions du ClusterRole garantissent que les utilisateurs ne peuvent pas modifier les pods ni les applications qu’ils contiennent.

Sécuriser vos configurations K8

Le contrôle d’accès basé sur les rôles joue un rôle important dans l’application du principe du moindre privilège. Heureusement, le cadre RBAC natif de Kubernetes offre de nombreuses fonctionnalités dans ce domaine. La possibilité de créer et d’associer des rôles est particulièrement efficace pour garantir que seul le nombre minimal d’utilisateurs dispose des accès nécessaires aux ressources requises. Cela réduit l’exposition aux acteurs malveillants sans entraver le travail des membres de l’équipe. Découvrez comment nous utilisons RBAC dans Kubernetes chez Snyk.

Pour en savoir plus sur la mise en œuvre correcte et sécurisée du PoLP dans votre environnement Kubernetes, rendez-vous sur Snyk et consultez les autres articles du blog Snyk.

Ressources Kubernetes :

• Sécurité Kubernetes

• Images Docker dans Kubernetes

• Guide de surveillance Kubernetes

• Paramètres securityContext de Kubernetes

• Opérateurs Kubernetes