Admission à la sécurité des pods

L'admission à la sécurité des pods met en œuvre les normes de sécurité des pods Kubernetes qui limitent le comportement des pods, en fournissant des messages d'avertissement et des événements d'audit kube-apiserver pour les pods qui violent la politique de profil de sécurité des pods configurée pour l'espace de noms concerné.

Red Hat OpenShift on IBM Cloud la version 4.11 et les versions ultérieures prennent en charge l'admission à la sécurité du pod Kubernetes. Pour plus d'informations, voir Pod Security Admission et Pod Security Standards dans la documentation Kubernetes.

Pod Security Admission est toujours activé pour Red Hat OpenShift on IBM Cloud version 4.11 et suivantes. Les versions antérieures de Kubernetes utilisent des politiques de sécurité de type "pod".

Comprendre les profils de sécurité

Les normes de sécurité du pod Kubernetes définissent les trois profils suivants.

Privilégié
La configuration de sécurité par défaut du pod applique globalement le profil de sécurité du pod privileged Kubernetes, qui n'est pas limité et permet des escalades de privilèges connues, et génère des avertissements et des événements d'audit basés sur les politiques définies par le profil restricted.
Ligne de base
Le profil baseline est un profil restrictif qui empêche les escalades de privilèges connues. Permet d'utiliser la configuration par défaut (spécification minimale) du pod.
Restreint
Le profil restricted est très restreint et suit les meilleures pratiques actuelles en matière de durcissement des pods.

Pour plus d'informations sur les profils de sécurité des pods, voir Détails des profils dans la documentation Kubernetes.

Le module d'admission à la sécurité contient trois modes qui définissent les mesures prises par le plan de contrôle en cas de détection d'une violation potentielle.

imposer
Les violations de la politique entraînent le rejet du pod.
audit
Les violations de la politique déclenchent l'ajout d'une annotation d'audit à l'événement enregistré dans le journal d'audit, mais sont par ailleurs autorisées.
warn
Les violations de la politique déclenchent un avertissement à l'intention de l'utilisateur, mais sont par ailleurs autorisées.

Lorsque les normes de sécurité ou les implémentations de profils changent pour prendre en compte de nouvelles fonctionnalités, vous pouvez configurer Pod Security Admission pour qu'il utilise une version spécifique des rôles. Les versions suivantes sont prises en charge.

  • Une version de Kubernetes major.minor (par exemple, v1.25)
  • latest

Et si l'admission à la sécurité du Pod n'est pas le bon choix pour moi?

L'admission de la sécurité du pod est toujours activée, mais il peut s'agir d'un contrôleur d'admission parmi d'autres. Vous pouvez configurer des contrôleurs d'admission tiers Kubernetes pour mettre en œuvre d'autres modèles de politique de sécurité adaptés à votre cas d'utilisation.

Si vous configurez l'admission à la sécurité des pods pour appliquer, avertir et auditer à l'aide du profil privileged, le plan de contrôle permet à tous les pods de fonctionner. Vous pouvez ensuite configurer d'autres contrôleurs d'admission pour qu'ils les rejettent.

Vous pouvez installer un contrôleur d'admission tiers à condition qu'il ne prenne aucune des mesures suivantes.

  • Il n'installe pas ses propres politiques de sécurité des pods (PSP).
  • Elle ne s'appuie pas sur les PSP pour appliquer certaines parties de la politique.

Configuration des étiquettes d'espace de noms pour l'admission à la sécurité des pods

Vous pouvez définir le mode de contrôle d'admission que vous souhaitez utiliser pour la sécurité des pods dans chaque espace de noms. Kubernetes définit un ensemble d'étiquettes que vous pouvez utiliser pour définir le profil prédéfini de la norme de sécurité Pod que vous souhaitez utiliser pour un espace de noms. L'étiquette que vous sélectionnez définit l'action que le plan de contrôle entreprend si une violation potentielle est détectée.

Par défaut, Red Hat OpenShift on IBM Cloud ajoute les étiquettes privileged Pod Security aux espaces de noms suivants. Ces espaces de noms sont étiquetés enforce, audit, et warn en utilisant le profil privileged.

  • kube-system
  • ibm-system
  • ibm-operators
  • calico-system
  • tigera-operator
  • calico-apiserver (Version 4.16 et suivantes)

Ne supprimez pas et ne modifiez pas les étiquettes de ces espaces de noms ou de tout autre espace de noms openshift-*.

Un espace de noms peut être étiqueté pour définir le profil de sécurité du pod pour tout ou partie de l'admission à la sécurité du pod modes.

Par exemple, vous pouvez étiqueter un espace de noms pour appliquer le profil privileged en plus d'utiliser warn ou audit en utilisant le profil baseline.

Cette étiquette permet aux administrateurs et aux développeurs d'applications de tester les applications en recherchant uniquement les avertissements et les enregistrements d'audit par rapport au profil baseline sans rejeter les pods. Vous pouvez ensuite apporter les modifications nécessaires à vos charges de travail avant de changer le mode d'exécution en baseline.

Les étiquettes de l'espace de noms Pod Security Admission sont de la forme pod-security.kubernetes.io/<MODE>: <LEVEL> et pod-security.kubernetes.io/<MODE>-version: <VERSION>.

  • pod-security.kubernetes.io/enforce
  • pod-security.kubernetes.io/enforce-version
  • pod-security.kubernetes.io/audit
  • pod-security.kubernetes.io/audit-version
  • pod-security.kubernetes.io/warn
  • pod-security.kubernetes.io/warn-version

Pour étiqueter un espace de noms afin d'appliquer le profil privileged et de générer des avertissements et des événements d'audit en cas de violation du profil baseline, utilisez les étiquettes suivantes.

  • pod-security.kubernetes.io/enforce: privileged
  • pod-security.kubernetes.io/enforce-version: latest
  • pod-security.kubernetes.io/audit: baseline
  • pod-security.kubernetes.io/audit-version: latest
  • pod-security.kubernetes.io/warn: baseline
  • pod-security.kubernetes.io/warn-version: latest

Configuration par défaut du plug-in Pod Security Admission

Red Hat OpenShift on IBM Cloud utilise par défaut le site PodSecurityConfiguration suivant.

apiVersion: pod-security.admission.config.k8s.io/v1
kind: PodSecurityConfiguration
defaults:
  enforce: "privileged"
  enforce-version: "latest"
  audit: "privileged"
  audit-version: "latest"
  warn: "privileged"
  warn-version: "latest"
exemptions:
  usernames: []
  runtimeClasses: []
  namespaces: []

Configuration de l'admission à la sécurité des pods

Vous pouvez configurer le comportement de sécurité du pod au niveau de l'espace de noms avec des étiquettes de sécurité prédéfinies. Pour plus d'informations sur la configuration, voir Controlling pod security admission synchronization dans la documentation Red Hat OpenShift. Notez que les étapes varient pour chaque version de cluster, assurez-vous donc que vous visualisez les étapes pour la bonne version.

Pour plus d'informations sur la configuration des journaux apiserver pour Red Hat OpenShift on IBM Cloud, voir Kubernetes Journaux d'audit du serveur API.

L'admission à la sécurité des pods permet d'appliquer, d'avertir et de générer des événements d'audit pour les pods qui ne respectent pas les profils de sécurité. Dans OpenShift 4.11, la configuration par défaut applique le profil privilégié, tout en générant des avertissements et des événements d'audit basés sur le profil restricted. Ce comportement peut être contrôlé au niveau de l'espace de noms grâce à l'utilisation d'étiquettes de sécurité prédéfinies sur les espaces de noms. Lorsque les profils de sécurité du Pod sont appliqués, des avertissements peuvent apparaître, comme dans l'exemple suivant.

`Warning: would violate PodSecurity "restricted:latest": host namespaces (hostNetwork=true, hostPID=true), privileged (container "container-00" must not set securityContext.privileged=true), allowPrivilegeEscalation != false (container "container-00" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (container "container-00" must set securityContext.capabilities.drop=["ALL"]), restricted volume types (volume "host" uses restricted volume type "hostPath"), runAsNonRoot != true (pod or container "container-00" must set securityContext.runAsNonRoot=true), runAsUser=0 (container "container-00" must not set runAsUser=0), seccompProfile (pod or container "container-00" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost")`

Dans cet exemple, le pod est toujours créé et peut fonctionner tant que le compte de service est autorisé à un profil SecurityContextConstraint. L'avertissement indique que des modifications du profil securityContext du module et du conteneur sont nécessaires pour que le module s'exécute sous le profil de sécurité du module spécifié, par exemple en définissant l'option allowPrivilegeEscalation=false, ou qu'un profil de sécurité du module autorisant ces capacités doit être utilisé.

Red Hat OpenShift comprend également un contrôleur qui applique des étiquettes d'espace de noms en fonction des autorisations SCC des comptes de service dans un espace de noms donné. L'admission à la sécurité du pod et les CSC sont tous deux appliqués. Vous pouvez utiliser principalement des SCC et utiliser le contrôleur de synchronisation des admissions à la sécurité des pods pour ajuster l'étiquette de sécurité des pods sur l'espace de noms. Vous pouvez également utiliser principalement des profils de sécurité de pods avec une liaison de rôle d'espace de noms qui permet à tous les comptes de service de l'espace de noms d'utiliser un SCC équivalent (ou plus privilégié). Ne définissez pas de liaisons de rôles ou de liaisons de rôles de cluster qui s'appliquent globalement, comme tous les utilisateurs autorisés ou tous les comptes de service dans tous les espaces de noms, car ces liaisons peuvent affecter les composants Red Hat OpenShift qui s'attendent à être exécutés sous un SCC particulier.

Autres ressources