Contextes de sécurité des pods

Les politiques de sécurité des pods (PSP) et les normes de sécurité des pods (PSS) sont deux principaux moyens de renforcer la sécurité dans Kubernetes. Notez qu'il PodSecurityPolicy est obsolète depuis la version 1.21 de Kubernetes et qu'il sera supprimé dans la version 1.25. Pod Security Standard (PSS) est l'approche recommandée par Kubernetes pour renforcer la sécurité à l'avenir.

Une politique de sécurité des pods (PSP) est une solution native de Kubernetes pour implémenter des politiques de sécurité. La PSP est une ressource au niveau du cluster qui contrôle les aspects sensibles à la sécurité de la spécification Pod. À l'aide de la politique de sécurité des pods, vous pouvez définir un ensemble de conditions que les pods doivent remplir pour être acceptés par le cluster. La fonctionnalité PSP est disponible depuis les débuts de Kubernetes et est conçue pour empêcher la création de pods mal configurés sur un cluster donné.

Pour plus d'informations sur les politiques de sécurité des pods, veuillez consulter la documentation Kubernetes. Selon la politique de dépréciation de Kubernetes, les anciennes versions ne seront plus prises en charge neuf mois après la dépréciation de la fonctionnalité.

D'autre part, les normes de sécurité des pods (PSS), qui constituent l'approche de sécurité recommandée et généralement mises en œuvre à l'aide de contextes de sécurité, sont définies dans le cadre des spécifications des pods et des conteneurs dans le manifeste du pod. PSS est la norme officielle que l'équipe du projet Kubernetes a définie pour définir les meilleures pratiques en matière de sécurité pour les Pods. Il définit des politiques telles que les politiques de base (minimalement restrictives, par défaut), privilégiées (non restrictives) et restreintes (les plus restrictives).

Nous vous recommandons de commencer par le profil de référence. Le profil de base PSS fournit un équilibre solide entre la sécurité et les frictions potentielles, nécessitant une liste minimale d'exceptions, il constitue un bon point de départ pour la sécurité de la charge de travail. Si vous utilisez actuellement des PSP, nous vous recommandons de passer au PSS. Vous trouverez plus de détails sur les politiques PSS dans la documentation Kubernetes. Ces politiques peuvent être appliquées à l'aide de plusieurs outils, notamment ceux de l'OPA et de https://kyverno.io/ Kyverno. Par exemple, Kyverno fournit la collection complète des politiques PSS ici. https://kyverno.io/policies/

Les paramètres de contexte de sécurité permettent d'accorder des privilèges à des processus sélectionnés, d'utiliser des profils de programme pour restreindre les fonctionnalités à des programmes individuels, d'autoriser l'augmentation des privilèges, de filtrer les appels système, entre autres choses.

Les pods Windows de Kubernetes présentent certaines limites et se différencient des Linux-based charges de travail standard en ce qui concerne les contextes de sécurité.

Windows utilise un objet Job par conteneur avec un filtre d'espace de noms système pour contenir tous les processus d'un conteneur et fournir une isolation logique par rapport à l'hôte. Il est impossible d'exécuter un conteneur Windows sans le filtrage des espaces de noms en place. Cela signifie que les privilèges système ne peuvent pas être affirmés dans le contexte de l'hôte et que les conteneurs privilégiés ne sont donc pas disponibles sous Windows.

Les seules options de contexte de sécurité Windows documentées windowsOptions sont les suivantes, les autres étant des options générales de contexte de sécurité.

Pour obtenir la liste des attributs de contexte de sécurité pris en charge entre Windows et Linux, veuillez consulter la documentation officielle ici.

Les paramètres spécifiques au Pod sont appliqués à tous les conteneurs. Si elles ne sont pas spécifiées, les options de PodSecurityContext seront utilisées. Si elle est définie à la fois dans SecurityContext et PodSecurityContext, la valeur spécifiée dans SecurityContext est prioritaire.

Par exemple, le AsUserName paramètre d'exécution pour les pods et les conteneurs, qui est une option Windows, est un équivalent approximatif du AsUser paramètre d' Linux-specific exécution et, dans le manifeste suivant, le contexte de sécurité spécifique aux pods est appliqué à tous les conteneurs

apiVersion: v1
kind: Pod
metadata:
  name: run-as-username-pod-demo
spec:
  securityContext:
    windowsOptions:
      runAsUserName: "ContainerUser"
  containers:
  - name: run-as-username-demo

  nodeSelector:
    kubernetes.io/os: windows

Alors que dans ce qui suit, le contexte de sécurité au niveau du conteneur remplace le contexte de sécurité au niveau du pod.

apiVersion: v1
kind: Pod
metadata:
  name: run-as-username-container-demo
spec:
  securityContext:
    windowsOptions:
      runAsUserName: "ContainerUser"
  containers:
  - name: run-as-username-demo
    ..
    securityContext:
        windowsOptions:
            runAsUserName: "ContainerAdministrator"
  nodeSelector:
    kubernetes.io/os: windows

Exemples de valeurs acceptables pour le AsUserName champ d'exécution : ContainerAdministrator ContainerUser, NT AUTHORITY \ NETWORK SERVICE, NT AUTHORITY \ LOCAL SERVICE

C'est généralement une bonne idée d'exécuter vos conteneurs avec ContainerUser des pods Windows. Les utilisateurs ne sont pas partagés entre le conteneur et l' ContainerAdministrator hôte, mais ils disposent de privilèges supplémentaires dans le conteneur. Notez qu'il existe des limites de nom d'utilisateur à connaître.

Un bon exemple d'utilisation ContainerAdministrator est de définir PATH. Vous pouvez utiliser la directive USER pour ce faire, comme suit :

USER ContainerAdministrator
RUN setx /M PATH "%PATH%;C:/your/path"
USER ContainerUser

Notez également que les secrets sont écrits en texte clair sur le volume du nœud (par rapport à tmpfs/in -memory sous Linux). Cela signifie que vous devez faire deux choses