Admission de la sécurité de pod

La gestion des accès de sécurité des pods met en œuvre les normes de sécurité des pods de l’ Kubernetes, qui restreignent le comportement des pods, en générant des messages d’avertissement et des événements d’audit kube-apiserver pour les pods qui enfreignent la politique de profil de sécurité des pods configurée pour l’espace de noms concerné.

IBM Cloud Kubernetes Service version 1.25 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.

La fonctionnalité Pod Security Admission est toujours activée pour la version 1.25 et les versions ultérieures d' IBM Cloud Kubernetes Service. Les versions antérieures d' Kubernetes utilisaient des politiques de sécurité de pod.

Description des profils de sécurité

Les normes de sécurité des pods de l' 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, IBM Cloud Kubernetes Service 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 (version 1.29 et ultérieure)
tigera-operator (version 1.29 et ultérieure)
calico-apiserver (Version 1.31 )

Ne supprimez pas ou ne modifiez pas les libellés de ces espaces de nom.

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

IBM Cloud Kubernetes Service 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: []

Personnalisation de la configuration du plug-in Pod Security Admission

La configuration du plug-in d'admission de la sécurité de pod à l'échelle du cluster définit le comportement enforce, audit et warn pour tous les espaces de nom qui n'ont pas de libellés de sécurité de pod ou d'exemptions.

Pour les clusters d' Kubernetes1.24, le doit apiVersion être pod-security.admission.config.k8s.io/v1beta. La version 1.25 et les versions ultérieures pod-security.admission.config.k8s.io/v1 sont préférables, mais la version API v1beta peut toujours être utilisée.

Créez un fichier YAML contenant une ressource PodSecurityConfiguration. Vous pouvez utiliser la configuration par défaut pour démarrer.

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: []

Effectuez les personnalisations que vous souhaitez utiliser. Passez en revue les informations suivantes sur chaque section de la configuration.

defaults

La section defaults de la configuration définit les valeurs par défaut à l'échelle du cluster pour les espaces de nom qui n'ont pas de libellés de sécurité de pod. Les zones peuvent avoir les mêmes valeurs que les libellés d'espace de nom correspondants.

exemptions

La section exemptions de la configuration vous permet de créer des pods qui sont autrement interdits en raison de la politique associée à un espace de nom spécifique. Les dimensions d'exemption incluent les cas suivants.

  - Noms d'utilisateur: les demandes des utilisateurs avec un nom d'utilisateur authentifié (ou simulé) exempté sont ignorées. Les noms d'utilisateur sont généralement des utilisateurs IAM ou des comptes de service. Par exemple,`usernames: [ "IAM#user@example.com" ]`. Vous pouvez également exempter le nom d'utilisateur associé à un certificat client `admin kubeconfig`. Si vous souhaitez spécifier un certificat `admin kubeconfig`, le nom d'utilisateur est le composant `CN` du certificat client en cours.

      ```sh {: pre}
      kubectl config view --minify -o jsonpath='{.users[0].user.client-certificate}'
      /home/user/.bluemix/plugins/container-service/clusters/mycluster-cheku1620qbs90gq6mdg-admin/admin.pem
      ```
      Dans l'exemple suivant, le nom d'utilisateur est `IBMid-27000xxxxx-admin-2023-05-12`. Si vous obtenez un nouveau `admin kubeconfig`, le nom d'utilisateur peut être différent.

      ```sh {: pre}
      openssl x509 -in <client-certificate> -subject -noout`
      subject=C = US, ST = San Francisco, L = CA, O = ibm-admins, CN = IBMid-27000xxxxx-admin-2023-05-12
      ```
  - RuntimeClassNames: Les modules et les ressources de charge de travail spécifiant un nom de classe d'exécution exempt sont ignorés.
  - Espaces de nom: les pods et les ressources de charge de travail dans un espace de nom exempt sont ignorés.

Sauvegardez votre fichier YAML de personnalisation.

Exécutez la commande ibmcloud ks cluster master pod-security set.

ibmcloud ks cluster master pod-security set --cluster CLUSTER --config-file CONFIG-FILE

Lorsque vous exécutez la commande ibmcloud ks cluster master pod-security set, l'admission de la sécurité du pod est réinitialisée à la configuration par défaut si vous ne spécifiez pas de fichier de configuration.