Admission de la sécurité de pod

L'admission de sécurité de pod implémente les normes de sécurité de pod Kubernetes qui restreignent 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é de pod configurée pour l'espace de nom approprié.

Red Hat OpenShift on IBM Cloud version 4.11 et ultérieure inclut la prise en charge de l'admission de 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".

Description des 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é de pod par défaut impose globalement le profil de sécurité de pod privileged Kubernetes, qui est illimité et autorise les escalades de privilèges connues, et génère des avertissements et des événements d'audit en fonction des règles définies par le profil restricted.
Ligne de base: Le profil baseline est un profil restrictif qui empêche les escalades de privilèges connus. Autorise la configuration de pod par défaut (spécifiée au minimum).
Restreint: Le profil restricted est fortement restreint et suit les meilleures pratiques de renforcement des pods en cours.

Pour plus d'informations sur les profils de sécurité de pod, voir Profile details dans la documentation Kubernetes.

L'admission de sécurité de pod contient trois modes qui définissent l'action que le plan de contrôle effectue si une violation potentielle est détectée.

imposer: Les violations de politique entraînent le rejet du pod.
audit: Les violations de politique déclenchent l'ajout d'une annotation d'audit à l'événement enregistré dans le journal d'audit, mais sont autorisées.
warn: Les violations de règles déclenchent un avertissement lié à l'utilisateur, mais elles sont autorisées dans le cas contraire.

Au fur et à mesure que les normes de sécurité ou les implémentations de profils changent pour répondre aux nouvelles fonctions, vous pouvez configurer Pod Security Admission pour utiliser une version spécifique des rôles. Les versions suivantes sont prises en charge.

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

Et si Pod Security Admission n'est pas le bon choix pour moi?

Alors que l'admission de sécurité de pod est toujours activée, elle peut être l'une des multiples contrôleurs d'admission. Vous pouvez configurer des contrôleurs d'admission Kubernetes tiers pour implémenter d'autres modèles de politique de sécurité adaptés à votre cas d'utilisation.

Si vous configurez Pod Security Admission pour appliquer, avertir et auditer à l'aide du profil privileged, le plan de contrôle permet à tous les pods de s'exécuter. Vous pouvez ensuite configurer d'autres contrôleurs d'admission pour les rejeter.

Vous pouvez installer un contrôleur d'admission tiers tant qu'il n'effectue aucune des actions suivantes.

Il n'installe pas ses propres politiques de sécurité de pod (PSP).
Elle ne s'appuie pas sur les prestataires de services de paiement pour appliquer certaines parties de la politique.

Configuration des libellés d'espace de nom d'admission de la sécurité de pod

Vous pouvez définir le mode de contrôle d'admission à utiliser pour la sécurité de pod dans chaque espace de nom. Kubernetes définit un ensemble de libellés que vous pouvez définir pour définir les profils Pod Security Standard prédéfinis que vous souhaitez utiliser pour un espace de nom. Le libellé que vous sélectionnez définit l'action que le plan de contrôle effectue si une violation potentielle est détectée.

Par défaut, Red Hat OpenShift on IBM Cloud ajoute les libellés de sécurité de pod privileged aux espaces de nom suivants. Ces espaces de nom sont libellés dans enforce, audit et warn à l'aide du profil privileged.

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

Ne supprimez ni ne modifiez les libellés de ces espaces de nom ou de l'un des espaces de nom openshift-*.

Un espace de nom peut être libellé pour définir le profil de sécurité de pod pour tout ou partie de l' modes Pod Security Admission.

Par exemple, vous pouvez étiqueter un espace de nom pour imposer le profil privileged en plus d'utiliser warn ou audit à l'aide du profil baseline.

Ce libellé permet aux administrateurs et aux développeurs d'applications d'exécuter des applications à sec en recherchant uniquement les avertissements et les enregistrements d'audit dans le profil baseline sans rejeter les pods. Vous pouvez ensuite apporter les modifications nécessaires à vos charges de travail avant de changer le mode d'application en baseline.

Les libellés d'espace de nom Pod Security Admission sont au format 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 libeller un espace de nom afin d'appliquer le profil privileged et générer des avertissements et des événements d'audit pour les violations du profil baseline, utilisez les libellés suivants.

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 du plug-in Pod Security Admission par défaut

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

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 de la sécurité de pod

Vous pouvez configurer le comportement de sécurité de pod au niveau de l'espace de nom avec des libellés de sécurité de pod prédéfinis. Pour plus d'informations sur la configuration, voir Contrôle de la synchronisation des admissions de sécurité de pod dans la documentation Red Hat OpenShift. Notez que les étapes varient pour chaque version de cluster. Par conséquent, veillez à afficher les étapes correspondant à la version correcte.

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

L'admission de la sécurité des pods permet d'appliquer, d'avertir et de générer des événements d'audit pour les pods qui violent 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 nom via l'utilisation de libellés de sécurité de pod prédéfinis sur les espaces de nom. Lorsque les profils de sécurité de pod sont appliqués, des avertissements tels que ceux de l'exemple suivant peuvent s'afficher.

`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 s'exécuter tant que le compte de service est autorisé à accéder à un profil SecurityContextConstraint. L'avertissement indique que des modifications du profil securityContext du pod et du conteneur sont requises pour que le pod s'exécute sous le profil de sécurité de pod spécifié, par exemple la définition de l'option allowPrivilegeEscalation=false, ou qu'un profil de sécurité de pod qui autorise ces fonctions doit être utilisé.

Red Hat OpenShift inclut également un contrôleur qui applique des libellés d'espace de nom en fonction des droits SCC des comptes de service dans un espace de nom donné. L'admission de la sécurité de pod et les contraintes de contexte de sécurité sont appliquées. Vous pouvez utiliser principalement des contraintes de contexte de sécurité et utiliser le contrôleur de synchronisation d'admission de sécurité de pod pour ajuster le libellé de sécurité de pod sur l'espace de nom. Vous pouvez également utiliser principalement des profils de sécurité de pod avec une liaison de rôle d'espace de nom qui permet à tous les comptes de service de l'espace de nom d'utiliser un élément équivalent (ou plus privilégié) SCC. Ne définissez pas de liaisons de rôle ou de liaisons de rôle de cluster qui s'appliquent globalement, comme tous les utilisateurs autorisés ou tous les comptes de service dans tous les espaces de nom, car ces liaisons peuvent affecter les composants Red Hat OpenShift qui s'attendent à s'exécuter sous une contrainte de contexte de sécurité particulière.

Autres ressources

Présentation et gestion de l'admission de la sécurité de pod.
Droits d'accès à la sécurité du pod dans Red Hat OpenShift 4.11.
La rubrique Kubernetes explique comment configurer les journaux d'audit du serveur d'API dans le service Red Hat OpenShift on IBM Cloud.