Leçon 10 : Sécurité dans Kubernetes – RBAC, Network Policies, OPA et Pod Security

Comprendre et Maîtriser DevSecOps de A à Z – Cours et 202 questions pratiques (Copie 1)

Table des Matières

Objectifs et Présentation de la Leçon
Introduction à la Sécurité dans Kubernetes
2.1. Pourquoi sécuriser un cluster Kubernetes ?
2.2. Enjeux et risques spécifiques
Contrôle d’Accès avec RBAC
3.1. Concepts clés du RBAC
3.2. Exemples de configuration RBAC (Role, ClusterRole, RoleBinding)
Mise en Place des Network Policies
4.1. Principes et objectifs des Network Policies
4.2. Exemple de manifeste YAML pour restreindre le trafic
Sécurisation des Pods : Pod Security et Pod Security Standards
5.1. Approche et objectifs des Pod Security Policies
5.2. Exemples de configuration pour forcer l’exécution non-root
Gouvernance et Conformité avec OPA Gatekeeper
6.1. Introduction à OPA et Gatekeeper
6.2. Exemple de Constraint Template et Constraint
Intégration dans un Pipeline CI/CD
7.1. Automatisation de la validation des configurations Kubernetes
7.2. Exemples d’intégration via des scripts ou jobs CI/CD
Exercices Pratiques et Corrigés Détaillés
8.1. Exercice 1 : Définir et déployer un Role et RoleBinding
8.2. Exercice 2 : Rédiger une Network Policy restreignant l’accès à un service
8.3. Exercice 3 : Créer un Constraint Template avec OPA Gatekeeper
Quiz de Révision
Conclusion et Prévisualisation de la Leçon 11

1. Objectifs et Présentation de la Leçon

Objectifs :

Comprendre les impératifs de la sécurité d’un cluster Kubernetes.
Maîtriser le contrôle d’accès via RBAC (Role-Based Access Control).
Apprendre à définir et appliquer des Network Policies pour contrôler le trafic réseau entre les pods.
Découvrir comment renforcer la sécurité des pods avec des Pod Security Policies ou des Pod Security Standards.
Intégrer des règles de gouvernance et de conformité avec OPA Gatekeeper.
Savoir intégrer ces mécanismes dans des pipelines CI/CD pour automatiser la validation des configurations.

Présentation :
La sécurisation d’un cluster Kubernetes est cruciale pour protéger les applications déployées. Dans cette leçon, nous verrons comment restreindre les accès à l’aide de RBAC, contrôler les flux réseau entre pods avec des Network Policies, imposer des exigences de sécurité aux pods et déployer des règles de gouvernance avec OPA Gatekeeper. Des exemples concrets et des exercices pratiques vous guideront dans la mise en œuvre de ces concepts dans un environnement professionnel.

2. Introduction à la Sécurité dans Kubernetes

2.1. Pourquoi sécuriser un cluster Kubernetes ?

Surface d’attaque étendue : Un cluster Kubernetes comporte de multiples composants (API server, etcd, nodes, pods) susceptibles d’être exploités si non protégés.
Risque de propagation : Une compromission d’un pod peut potentiellement affecter l’ensemble du cluster.
Conformité et régulation : Les environnements sensibles (banques, santé) nécessitent des contrôles stricts pour respecter des normes comme PCI-DSS, HIPAA ou RGPD.

2.2. Enjeux et Risques Spécifiques

Contrôle d’accès inapproprié : Peut conduire à des accès non autorisés.
Trafic réseau non filtré : Risque d’interception ou d’exploitation malveillante entre pods.
Mauvaise configuration des pods : Par exemple, l’exécution en mode root ou l’exposition inutile de ports sensibles.
Non-conformité aux politiques internes ou réglementaires, pouvant entraîner des sanctions.

3. Contrôle d’Accès avec RBAC

3.1. Concepts Clés du RBAC

RBAC (Role-Based Access Control) permet de définir des rôles qui confèrent des permissions précises sur des ressources Kubernetes.
Principaux composants :
- Role : Appliqué dans un namespace spécifique.
- ClusterRole : Appliqué à l’ensemble du cluster.
- RoleBinding / ClusterRoleBinding : Lient des rôles à des utilisateurs ou groupes.

3.2. Exemples de Configuration RBAC

Exemple de Role et RoleBinding dans un namespace « production » :

Explication :
Le rôle production-read confère à l’utilisateur « alice » un accès en lecture sur les pods et services du namespace « production ».

4. Mise en Place des Network Policies

4.1. Principes et Objectifs

Les Network Policies permettent de contrôler le trafic réseau entre les pods, limitant ainsi l’exposition des services sensibles.
Elles définissent les règles d’ingress (trafic entrant) et d’egress (sortant) au sein d’un namespace.

4.2. Exemple de Manifeste YAML

Exemple : Limiter l’accès à un service de base de données uniquement aux pods ayant le label « role: backend » :

Explication :
Cette Network Policy s’applique aux pods labellisés « app: database » dans « production » et autorise uniquement le trafic TCP sur le port 5432 venant des pods avec le label « role: backend ».

5. Sécurisation des Pods : Pod Security et Pod Security Standards

5.1. Concepts et Importance

Pod Security Policies (PSP) (ou les standards actuels comme les Pod Security Standards) définissent les contraintes de sécurité pour les pods, par exemple pour exiger l’exécution en mode non-root.
Elles permettent de réduire l’impact d’une éventuelle compromission en restreignant les permissions du conteneur.

5.2. Exemple de Configuration de Sécurité pour un Pod

Explication :
Cette PSP interdit les privilèges élevés et impose l’exécution en tant qu’utilisateur non-root, renforçant la sécurité au niveau du pod.

6. Gouvernance avec OPA Gatekeeper

6.1. Introduction à OPA et Gatekeeper

OPA (Open Policy Agent) permet de définir des règles de sécurité en tant que code.
OPA Gatekeeper intègre ces règles dans Kubernetes et les applique lors de l’admission des ressources.

6.2. Exemple de Constraint Template et Constraint

Constraint Template pour imposer des labels obligatoires (« app » et « env ») :

yaml

apiVersion: templates.gatekeeper.sh/v1beta1

kind: ConstraintTemplate

metadata:

  name: k8srequiredlabels

spec:

  crd:

    spec:

      names:

        kind: K8sRequiredLabels

  targets:

  - target: admission.k8s.gatekeeper.sh

    rego: |

      package k8srequiredlabels



      violation[{"msg": msg, "details": {}}] {

        provided := {label | input.review.object.metadata.labels[label]}

        required := {"app", "env"}

        missing := required - provided

        count(missing) > 0

        msg := sprintf("Les labels requis %v sont manquants.", [missing])

      }

Constraint pour appliquer la règle :

Explication :
Ces manifestes imposent que toute ressource dans le cluster déploie les labels « app » et « env », sinon la création est rejetée.

7. Intégration dans un Pipeline CI/CD

7.1. Automatiser la Vérification des Configurations Kubernetes

Des jobs dans un pipeline CI/CD peuvent exécuter des scripts ou utiliser OPA pour valider la conformité des configurations (ex. rôle RBAC, Network Policies).

7.2. Exemple d’Intégration dans GitLab CI

Explication :
Ce pipeline inclut un job test_k8s qui utilise OPA pour vérifier que les ressources respectent la politique imposée par Gatekeeper.

8. Exercices Pratiques et Corrigés Détaillés

Exercice 1 : Définir et Déployer un Role et RoleBinding

Objectif : Créer un Role limitant l’accès aux ressources dans un namespace et lier ce rôle à un utilisateur.

Consigne :
Rédiger deux fichiers YAML pour créer un Role (lecture uniquement sur les pods) et un RoleBinding pour l’utilisateur « alice ».

Corrigé :

role.yaml :

rolebinding.yaml :

Exercice 2 : Rédiger une Network Policy

Objectif : Limiter l’accès au service « database » aux pods ayant le label « role: backend » dans le namespace « production ».

Consigne :
Créer un manifeste YAML pour une Network Policy répondant à cette exigence.

Corrigé :

Exercice 3 : Créer un Constraint Template avec OPA Gatekeeper

Objectif : Définir une politique qui impose l’utilisation des labels « app » et « env » pour toutes les ressources.

Consigne :
Créer un Constraint Template puis un Constraint qui applique cette règle dans le cluster.

Corrigé :
Référez-vous aux exemples présentés dans la section 6 ci-dessus.

9. Quiz de Révision

Qu’est-ce que le RBAC dans Kubernetes ?
A) Une méthode de gestion des conteneurs
B) Un système de contrôle d’accès basé sur des rôles
C) Un outil de monitoring
Quel est l’objectif principal d’une Network Policy ?
A) Déployer des mises à jour automatiques
B) Contrôler le trafic réseau entre les pods
C) Gérer les logs des applications
Que permet OPA Gatekeeper de faire dans un cluster Kubernetes ?
A) Analyser les logs
B) Appliquer des politiques de conformité automatiquement
C) Déployer des conteneurs
Pourquoi est-il essentiel d’exécuter les pods en mode non-root ?
A) Pour améliorer la performance
B) Pour limiter les risques en cas de compromission
C) Pour faciliter la gestion des images
Quelles sont les principales fonctions d’une Network Policy ?
A) Contrôler les flux entrants et sortants entre pods
B) Monitorer la performance du cluster
C) Gérer les mises à jour logicielles

10. Conclusion et Prévisualisation de la Leçon 11

Conclusion de la Leçon 10 :
Vous avez exploré en détail les mécanismes de sécurité dans Kubernetes :

La configuration de RBAC pour contrôler les accès au cluster.
La définition de Network Policies pour limiter le trafic réseau entre pods.
La sécurisation des pods via des Pod Security Policies ou Pod Security Standards.
L’utilisation d’OPA Gatekeeper pour imposer des politiques de conformité automatiquement.

Ces techniques vous permettent de renforcer la sécurité de l’environnement Kubernetes dans un contexte DevSecOps, garantissant que seules les ressources conformes et sécurisées sont déployées.

Prévisualisation de la Leçon 11 :
Dans la Leçon 11 (environ 50 pages), nous aborderons l’Intégration des Scans de Vulnérabilités dans les Pipelines. Vous apprendrez comment automatiser la détection des vulnérabilités dans les images conteneurisées et le code grâce à des outils comme Trivy, Clair et Grype, et comment configurer vos pipelines CI/CD pour que ces scans s’exécutent en continu.