0Pricing
DevOps Bootcamp · Leçon

Normes de sécurité des Pods

Appliquez les normes de sécurité des Pods afin d’imposer les bonnes pratiques de sécurité au niveau des Pods.

Normes de sécurité des Pods est une leçon DevOps Bootcamp gratuite sur CoddyKit. Ceci est la leçon 3 sur 4. Tu peux lire la leçon complète ci-dessous gratuitement — puis la pratiquer en direct dans le navigateur avec un éditeur de code intégré et un tuteur IA 24/7. Elle fait partie du parcours d'apprentissage DevOps Bootcamp, et ta progression se synchronise sur le web et l'application CoddyKit. Le cours DevOps Bootcamp comprend 4 leçons au total.

Que sont les PSS ?

Les normes de sécurité des pods Kubernetes (PSS) constituent un ensemble de recommandations et de contrôles visant à appliquer les bonnes pratiques de sécurité à vos pods.

Elles contribuent à protéger votre cluster contre les failles de sécurité courantes et les attaques par élévation de privilèges en limitant les actions que les pods peuvent effectuer.

Considérez-les comme une liste de contrôle de sécurité pour vos pods !

Trois niveaux de sécurité

Les PSS définissent trois niveaux de sécurité distincts, offrant chacun un degré de protection différent :

  • Privileged : sans restriction, donc le moins sécurisé.
  • Baseline : empêche les élévations de privilèges connues.
  • Restricted : impose des bonnes pratiques de sécurité renforcées.

Ces niveaux sont cumulatifs : Restricted inclut toutes les protections de Baseline, et Baseline inclut toutes celles de Privileged (ou plutôt, n’impose aucune restriction).

Privileged : accès sans restriction

Le niveau PSS Privileged propose une stratégie de sécurité sans restriction.

Cela signifie que les pods exécutés avec cette stratégie peuvent demander n’importe quelle capacité et disposer d’un accès complet aux ressources et aux espaces de noms de l’hôte, comme s’ils s’exécutaient en tant que root sur la machine hôte.

Ce niveau est généralement considéré comme très dangereux et ne devrait être utilisé que pour les charges de travail système qui nécessitent absolument un tel accès.

Baseline : empêcher les exploitations

Le niveau PSS Baseline vise à empêcher les élévations de privilèges connues.

C’est un bon point de départ pour la plupart des applications définies par les utilisateurs.

Ses principales restrictions sont les suivantes :

  • Aucun conteneur privilégié.
  • Aucun volume hostPath (sauf certains types considérés comme sûrs).
  • Aucun réseau de l’hôte ni partage de l’espace de noms PID.
  • Capacités limitées.

Ce niveau contribue à atténuer de nombreux vecteurs d’attaque courants.

Restricted : sécurité renforcée

Le niveau PSS Restricted impose des bonnes pratiques de sécurité renforcées.

Il est conçu pour les applications très sensibles sur le plan de la sécurité et exige que les pods s’exécutent avec un minimum de privilèges.

En plus des restrictions de Baseline, Restricted impose les mesures suivantes :

  • Exécution avec un utilisateur autre que root.
  • Suppression de toutes les capacités Linux et ajout des seules capacités requises.
  • Obligation d’utiliser des profils seccomp et AppArmor.

C’est le niveau PSS le plus sûr et le plus strict.

Appliquer les PSS avec l’admission

Les standards de sécurité des Pods sont appliqués à l’aide d’une fonctionnalité Kubernetes appelée Pod Security Admission.

Ce contrôleur d’admission intercepte les demandes de création de Pods et les vérifie par rapport au niveau PSS configuré pour l’espace de noms du Pod.

Vous appliquez les niveaux PSS aux espaces de noms en leur ajoutant des étiquettes spécifiques. Par exemple :

kubectl label namespace <namespace-name> pod-security.kubernetes.io/enforce=restricted

Contrôler la sécurité des Pods

Pour rendre vos Pods conformes aux PSS, vous utiliserez souvent le champ securityContext dans la définition de votre Pod.

Ce champ vous permet de définir les paramètres de privilèges et de contrôle d’accès pour un Pod ou pour les conteneurs individuels qu’il contient.

Les paramètres courants comprennent :

  • runAsUser : indique l’ID utilisateur du processus du conteneur.
  • allowPrivilegeEscalation : empêche un processus d’obtenir davantage de privilèges que son parent.
  • capabilities : gère les capacités Linux.

Exemple de Pod non sécurisé

Examinons une définition de Pod qui enfreindrait les PSS de niveau Baseline en raison de son contexte de sécurité. Cette configuration est généralement dangereuse :

apiVersion: v1
kind: Pod
metadata:
  name: unsafe-pod
spec:
  containers:
  - name: my-container
    image: nginx
    securityContext:
      privileged: true
      # This allows the container to run with root capabilities
      # and access host devices directly.
      # Violates Baseline PSS.

Exemple de Pod conforme au niveau Baseline

Voici comment définir un Pod qui respecte le niveau PSS Baseline. Remarquez l’absence de privileged: true et des autres restrictions.

Pour une conformité Restricted encore plus stricte, vous ajouteriez runAsNonRoot: true, readOnlyRootFilesystem: true et supprimeriez toutes les capacités.

apiVersion: v1
kind: Pod
metadata:
  name: safe-pod
spec:
  containers:
  - name: my-container
    image: nginx
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop:
        - ALL
      # This Pod runs with minimal privileges and
      # adheres to the Baseline PSS.

Vérification rapide des PSS

Laquelle des affirmations suivantes concernant les standards de sécurité des Pods (PSS) est TRUE ?

Récapitulatif : standards de sécurité des Pods

Dans cette leçon, vous avez découvert les standards de sécurité des Pods Kubernetes (PSS) et leur importance pour sécuriser votre cluster.

  • Les PSS définissent trois niveaux : Privileged, Baseline et Restricted.
  • Baseline empêche les escalades de privilèges connues et convient à la plupart des applications.
  • Restricted impose une sécurité renforcée et exige un minimum de privilèges.
  • Le champ securityContext aide à configurer les Pods pour qu’ils soient conformes aux PSS.

L’application des PSS est une étape essentielle pour créer des environnements Kubernetes plus sécurisés !

Questions Fréquemment Posées

La leçon « Normes de sécurité des Pods » est-elle gratuite ?

Oui — le texte complet de « Normes de sécurité des Pods » est gratuit à lire ici sur le web. Pour la pratiquer de manière interactive (un éditeur de code intégré et un tuteur IA 24/7) et déverrouiller le reste du cours DevOps Bootcamp, passe à CoddyKit PRO. Le cours DevOps Bootcamp comprend 4 leçons au total.

Qu'est-ce que j'apprendrai dans « Normes de sécurité des Pods » ?

Appliquez les normes de sécurité des Pods afin d’imposer les bonnes pratiques de sécurité au niveau des Pods. Tu pratiques DevOps Bootcamp avec du code pratique que tu exécutes directement dans le navigateur, et un tuteur IA 24/7 répond à tes questions au fur et à mesure que tu avances dans la leçon.

Dois-je avoir de l'expérience pour commencer DevOps Bootcamp ?

Aucune expérience préalable n'est requise. DevOps Bootcamp sur CoddyKit est structuré pour les débutants jusqu'aux apprenants avancés, donc tu peux commencer ici ou depuis le début et avancer à ton rythme. Ceci est la leçon 3 sur 4.

Combien de temps prend la leçon « Normes de sécurité des Pods » ?

La plupart des leçons CoddyKit prennent environ 5–10 minutes. Chacune est courte et interactive, tu progresses régulièrement et tu repiques exactement où tu t'es arrêté sur le web et l'app.

Peux-tu écrire et exécuter du code dans cette leçon DevOps Bootcamp ?

Oui. Chaque leçon DevOps Bootcamp inclut un éditeur de code intégré, tu écris et exécutes du vrai code directement dans ton navigateur et tu reçois des retours IA instantanés — aucune configuration locale requise.

Toutes les leçons de ce cours

  1. Contrôle d’accès basé sur les rôles (RBAC)
  2. Politiques réseau pour l’isolation
  3. Normes de sécurité des Pods
  4. Comptes de service et identité des charges de travail
← Retour à DevOps Bootcamp