Red Hat Summit Red Hat SummitSupportConsoleDéveloppeursCommencer un essaiContact

5.8. Conformité à l’admission de sécurité de pod

L’admission à la sécurité de Pod est une mise en œuvre des normes de sécurité des pod Kubernetes. L’admission à la sécurité de Pod limite le comportement des pods. Les pods qui ne sont pas conformes à l’admission de sécurité pod définie globalement ou au niveau de l’espace de noms ne sont pas admis au cluster et ne peuvent pas s’exécuter.

Dans le cas où votre projet Opérateur ne nécessite pas d’autorisations supplémentaires pour s’exécuter, vous pouvez vous assurer que vos charges de travail s’exécutent dans des espaces de noms définis au niveau de sécurité des pod restreint. Dans le cas où votre projet Opérateur nécessite des autorisations accrues pour s’exécuter, vous devez définir les configurations de contexte de sécurité suivantes:

  • Le niveau d’admission de sécurité de la pod autorisée pour l’espace de noms de l’opérateur
  • Les contraintes de contexte de sécurité autorisées (SCC) pour le compte de service de la charge de travail Pour plus d’informations, voir Comprendre et gérer l’admission à la sécurité des pod.
Important

La version prise en charge par Red Hat de l’outil Operator SDK CLI, y compris les outils d’échafaudage et de test connexes pour les projets Opérateur, est dépréciée et devrait être supprimée dans une future version de Red Hat OpenShift Service sur AWS. Le Red Hat fournira des corrections de bogues et une prise en charge de cette fonctionnalité pendant le cycle de vie de la version actuelle, mais cette fonctionnalité ne recevra plus d’améliorations et sera supprimée du futur service Red Hat OpenShift sur les versions AWS.

La version prise en charge par Red Hat du SDK de l’opérateur n’est pas recommandée pour la création de nouveaux projets d’opérateur. Les auteurs d’opérateurs avec des projets d’opérateur existants peuvent utiliser la version de l’outil Operator SDK CLI publié avec Red Hat OpenShift Service sur AWS 4 pour maintenir leurs projets et créer des versions d’opérateur ciblant de nouvelles versions de Red Hat OpenShift Service sur AWS.

Les images de base suivantes pour les projets d’opérateur ne sont pas dépréciées. Les fonctionnalités d’exécution et les API de configuration de ces images de base sont toujours prises en charge pour les corrections de bogues et pour l’adressage des CVE.

  • L’image de base pour les projets d’opérateurs basés sur Ansible
  • L’image de base pour les projets d’opérateur basé sur Helm

Afin d’obtenir de l’information sur la version non prise en charge et gérée par la communauté du SDK de l’opérateur, voir Operator SDK (Operator Framework).

5.8.1. À propos de l’admission à la sécurité de pod
Copier lien

Le service OpenShift Red Hat sur AWS inclut l’admission à la sécurité des pod Kubernetes. Les pods qui ne sont pas conformes à l’admission de sécurité pod définie globalement ou au niveau de l’espace de noms ne sont pas admis au cluster et ne peuvent pas s’exécuter.

À l’échelle mondiale, le profil privilégié est appliqué et le profil restreint est utilisé pour les avertissements et les audits.

Il est également possible de configurer les paramètres d’entrée de sécurité pod au niveau de l’espace de noms.

Important

Évitez d’exécuter des charges de travail ou de partager l’accès aux projets par défaut. Les projets par défaut sont réservés à l’exécution de composants de cluster de base.

Les projets par défaut suivants sont considérés comme hautement privilégiés: par défaut, kube-public, kube-system, openshift, openshift-infra, openshift-node, et d’autres projets créés par système qui ont l’étiquette openshift.io / run-level définie à 0 ou 1. La fonctionnalité qui repose sur des plugins d’admission, tels que l’admission de sécurité pod, les contraintes de contexte de sécurité, les quotas de ressources de cluster et la résolution de référence d’image, ne fonctionne pas dans des projets hautement privilégiés.

5.8.1.1. Les modes d’admission à la sécurité de Pod
Copier lien

Les modes d’admission de sécurité pod suivants peuvent être configurés pour un espace de noms:

Expand
Tableau 5.18. Les modes d’admission à la sécurité de Pod
Le modeÉtiquetteDescription

faire respecter

accueil > Pod-security.kubernetes.io/enforce

Il rejette un pod d’admission s’il ne se conforme pas au profil défini

audit

accueil > Pod-security.kubernetes.io/audit

Enregistre les événements d’audit si un pod ne se conforme pas au profil défini

avertissez

accueil > Pod-security.kubernetes.io/warn

Affiche les avertissements si un pod ne se conforme pas au profil défini

5.8.1.2. Les profils d’admission à la sécurité de Pod
Copier lien

Chacun des modes d’admission à la sécurité de pod peut être défini sur l’un des profils suivants:

Expand
Tableau 5.19. Les profils d’admission à la sécurité de Pod
Le profilDescription

les privilégiés

La politique la moins restrictive; permet une escalade connue des privilèges

base de données

La politique minimalement restrictive; empêche les escalades de privilèges connues

limité

La politique la plus restrictive; suit les meilleures pratiques actuelles de durcissement de la pod

5.8.1.3. Espaces de noms privilégiés
Copier lien

Les espaces de noms système suivants sont toujours définis sur le profil d’admission de sécurité de pod privilégié:

  • défaut par défaut
  • Kube-public
  • Kube-système

Il est impossible de modifier le profil de sécurité des pod pour ces espaces de noms privilégiés.

En plus de la configuration globale de contrôle d’admission de sécurité de pod, un contrôleur applique les étiquettes de contrôle d’admission de sécurité pod aux espaces de noms selon les autorisations SCC des comptes de service qui se trouvent dans un espace de noms donné.

Le contrôleur examine les autorisations d’objet ServiceAccount pour utiliser les contraintes de contexte de sécurité dans chaque espace de noms. Les contraintes de contexte de sécurité (SCC) sont cartographiées pour pod des profils de sécurité en fonction de leurs valeurs de champ; le contrôleur utilise ces profils traduits. Les étiquettes d’admission de sécurité Pod et les étiquettes d’audit sont définies sur le profil de sécurité de pod le plus privilégié dans l’espace de noms pour empêcher l’affichage des avertissements et les événements d’audit de journalisation lorsque des pods sont créés.

L’étiquetage de l’espace de noms est basé sur la prise en compte des privilèges de compte de service local-nomspace.

Appliquer des pods directement pourrait utiliser les privilèges SCC de l’utilisateur qui exécute le pod. Cependant, les privilèges de l’utilisateur ne sont pas pris en compte lors de l’étiquetage automatique.

La synchronisation de l’entrée de sécurité Pod est désactivée de façon permanente sur les espaces de noms créés par le système et les espaces de noms préfixés openshift-*.

Les espaces de noms qui sont définis comme faisant partie de la charge utile du cluster ont mis en place une synchronisation d’admission de sécurité désactivée de façon permanente. Les espaces de noms suivants sont désactivés de façon permanente:

  • défaut par défaut
  • location de Kube-node
  • Kube-système
  • Kube-public
  • à propos de OpenShift
  • L’ensemble des espaces de noms créés par le système qui sont préfixés avec openshift-

Afin de s’assurer que votre projet Opérateur peut s’exécuter sur une grande variété de déploiements et d’environnements, configurez les charges de travail de l’opérateur pour s’exécuter dans des espaces de noms définis au niveau de sécurité des pod restreint.

Avertissement

Il faut laisser le champ runAsUser vide. Lorsque votre image nécessite un utilisateur spécifique, elle ne peut pas être exécutée sous des contraintes de contexte de sécurité restreintes (SCC) et l’application de la sécurité des pod restreints.

Procédure

  • Afin de configurer les charges de travail de l’opérateur pour s’exécuter dans des espaces de noms définis au niveau de sécurité des pod restreints, modifiez la définition de l’espace de noms de votre opérateur similaire aux exemples suivants:

    Important

    Il est recommandé de définir le profil seccomp dans la définition de l’espace de noms de votre opérateur. Cependant, la configuration du profil seccomp n’est pas prise en charge dans Red Hat OpenShift Service sur AWS 4.10.

    • Dans le cas des projets d’opérateur qui ne doivent fonctionner que dans Red Hat OpenShift Service sur AWS 4.11 et plus tard, modifiez la définition de l’espace de noms de votre opérateur similaire à l’exemple suivant:

      Exemple de fichier config/manager/manager.yaml

      ...
spec:
 securityContext:
   seccompProfile:
     type: RuntimeDefault
      1 
      
   runAsNonRoot: true
 containers:
   - name: <operator_workload_container>
     securityContext:
       allowPrivilegeEscalation: false
       capabilities:
         drop:
           - ALL
...
      Copy to Clipboard Toggle word wrap

      1
      En définissant le type de profil seccomp sur RuntimeDefault, le SCC par défaut sur le profil de sécurité pod de l’espace de noms.

    • Dans le cas des projets d’opérateur qui doivent également fonctionner dans Red Hat OpenShift Service sur AWS 4.10, modifiez la définition de l’espace de noms de votre opérateur similaire à l’exemple suivant:

      Exemple de fichier config/manager/manager.yaml

      ...
spec:
 securityContext:
      1 
      
   runAsNonRoot: true
 containers:
   - name: <operator_workload_container>
     securityContext:
       allowPrivilegeEscalation: false
       capabilities:
         drop:
           - ALL
...
      Copy to Clipboard Toggle word wrap

      1
      En laissant le type de profil seccomp unset, votre projet Opérateur peut s’exécuter dans Red Hat OpenShift Service sur AWS 4.10.

Dans le cas où votre projet Opérateur nécessite des autorisations accrues pour s’exécuter, vous devez modifier la version du service cluster (CSV) de votre opérateur.

Procédure

  1. Définissez la configuration du contexte de sécurité au niveau d’autorisation requis dans le CSV de votre opérateur, semblable à l’exemple suivant:

    Exemple &lt;operator_name&gt;.clusterserviceversion.yaml fichier avec les privilèges d’administrateur réseau

    ...
containers:
   - name: my-container
     securityContext:
       allowPrivilegeEscalation: false
       capabilities:
         add:
           - "NET_ADMIN"
...
    Copy to Clipboard Toggle word wrap

  2. Définissez les privilèges de compte de service qui permettent aux charges de travail de votre opérateur d’utiliser les contraintes de contexte de sécurité (SCC) requises, comme l’exemple suivant:

    Exemple &lt;operator_name&gt;.clusterserviceversion.yaml fichier

    ...
  install:
    spec:
      clusterPermissions:
      - rules:
        - apiGroups:
          - security.openshift.io
          resourceNames:
          - privileged
          resources:
          - securitycontextconstraints
          verbs:
          - use
        serviceAccountName: default
...
    Copy to Clipboard Toggle word wrap

  3. Éditez la description CSV de votre opérateur pour expliquer pourquoi votre projet Opérateur nécessite des autorisations accrues similaires à l’exemple suivant:

    Exemple &lt;operator_name&gt;.clusterserviceversion.yaml fichier

    ...
spec:
  apiservicedefinitions:{}
  ...
description: The <operator_name> requires a privileged pod security admission label set on the Operator's namespace. The Operator's agents require escalated permissions to restart the node if the node needs remediation.
    Copy to Clipboard Toggle word wrap

Retour au début
Red Hat logoGithubredditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance. Découvrez nos récentes mises à jour.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez le Blog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

Theme

© 2025 Red Hat