Red Hat Summit Red Hat SummitSupportConsoleDéveloppeursCommencer un essaiContact

Chapitre 13. Gestion des contraintes de contexte de sécurité

Dans OpenShift Dedicated, vous pouvez utiliser des contraintes de contexte de sécurité (SCC) pour contrôler les autorisations pour les pods de votre cluster.

Les CSC par défaut sont créés pendant l’installation et lorsque vous installez certains opérateurs ou d’autres composants. En tant qu’administrateur de cluster, vous pouvez également créer vos propres SCC en utilisant l’OpenShift CLI (oc).

Important

Il ne faut pas modifier les CCN par défaut. La personnalisation des SCC par défaut peut entraîner des problèmes lorsque certains pods de plate-forme se déploient ou OpenShift Dedicated est mis à niveau. De plus, les valeurs SCC par défaut sont réinitialisées aux valeurs par défaut lors de certaines mises à niveau de cluster, ce qui élimine toutes les personnalisations de ces SCC.

Au lieu de modifier les CSC par défaut, créez et modifiez vos propres CSC au besoin. En ce qui concerne les étapes détaillées, voir Créer des contraintes de contexte de sécurité.

Note

Dans les déploiements dédiés à OpenShift, vous pouvez créer vos propres SCC uniquement pour les clusters utilisant le modèle d’abonnement au cloud client (CCS). Il est impossible de créer des SCC pour les clusters dédiés OpenShift qui utilisent un compte cloud Red Hat, car la création de ressources SCC nécessite des privilèges d’administration de cluster.

13.1. À propos des contraintes de contexte de sécurité
Copier lien

À l’instar de la façon dont les ressources RBAC contrôlent l’accès des utilisateurs, les administrateurs peuvent utiliser des contraintes de contexte de sécurité (SCC) pour contrôler les autorisations pour les pods. Ces autorisations déterminent les actions qu’un pod peut effectuer et les ressources auxquelles il peut accéder. Il est possible d’utiliser les CSC pour définir un ensemble de conditions avec lesquelles un pod doit fonctionner pour être accepté dans le système.

Les contraintes de contexte de sécurité permettent à un administrateur de contrôler:

  • La possibilité d’exécuter des conteneurs privilégiés avec le drapeau AuthorPrivilegedContainer
  • La question de savoir si un pod est limité avec le drapeau AuthorPrivilegeEscalation
  • Les capacités qu’un conteneur peut demander
  • L’utilisation des répertoires hôtes comme volumes
  • Le contexte SELinux du conteneur
  • L’identifiant de l’utilisateur du conteneur
  • L’utilisation d’espaces de noms d’hôte et de mise en réseau
  • L’attribution d’un groupe FS qui possède les volumes de pod
  • La configuration des groupes complémentaires admissibles
  • La question de savoir si un conteneur nécessite un accès par écrit à son système de fichiers racine
  • L’utilisation des types de volume
  • La configuration des profils seccomp admissibles
Important

Il ne faut pas définir l’étiquette de niveau openshift.io/run sur les espaces de noms d’OpenShift Dedicated. Ce label est destiné à être utilisé par les composants internes OpenShift dédiés pour gérer le démarrage des grands groupes d’API, tels que le serveur API Kubernetes et le serveur API OpenShift. Lorsque l’étiquette openshift.io/run-level est définie, aucun SCC n’est appliqué aux pods dans cet espace de noms, ce qui fait que les charges de travail qui s’exécutent dans cet espace de noms sont hautement privilégiées.

13.1.1. Contraintes du contexte de sécurité par défaut
Copier lien

Le cluster contient plusieurs contraintes de contexte de sécurité par défaut (SCC) comme décrit dans le tableau ci-dessous. Des SCC supplémentaires peuvent être installés lorsque vous installez des Opérateurs ou d’autres composants sur OpenShift Dedicated.

Important

Il ne faut pas modifier les CCN par défaut. La personnalisation des SCC par défaut peut entraîner des problèmes lorsque certains pods de plate-forme se déploient ou OpenShift Dedicated est mis à niveau. De plus, les valeurs SCC par défaut sont réinitialisées aux valeurs par défaut lors de certaines mises à niveau de cluster, ce qui élimine toutes les personnalisations de ces SCC.

Au lieu de modifier les CSC par défaut, créez et modifiez vos propres CSC au besoin. En ce qui concerne les étapes détaillées, voir Créer des contraintes de contexte de sécurité.

Expand
Tableau 13.1. Contraintes du contexte de sécurité par défaut
Contrainte du contexte de sécuritéDescription

à n’importe queluid

Fournit toutes les fonctionnalités du SCC restreint, mais permet aux utilisateurs de fonctionner avec n’importe quel UID et n’importe quel GID.

la non-racine

Fournit toutes les fonctionnalités du SCC restreint, mais permet aux utilisateurs de fonctionner avec n’importe quel UID non-root. L’utilisateur doit spécifier l’UID ou il doit être spécifié dans le manifeste de l’exécution du conteneur.

la non-root-v2

Comme le CCN non racine, mais avec les différences suivantes:

  • Toutes les capacités sont supprimées des conteneurs.
  • La capacité NET_BIND_SERVICE peut être ajoutée explicitement.
  • le fichier seccompProfile est défini sur runtime/par défaut par défaut.
  • AuthorPrivilegeEscalation doit être non défini ou défini sur false dans des contextes de sécurité.

limité

Il refuse l’accès à toutes les fonctionnalités de l’hôte et nécessite que les pods soient exécutés avec un UID et un contexte SELinux qui sont attribués à l’espace de noms.

Le CCN restreint:

  • Fait en sorte que les gousses ne puissent pas fonctionner comme privilégiées
  • Garantit que les pods ne peuvent pas monter des volumes de répertoires hôtes
  • Exige qu’un pod soit exécuté en tant qu’utilisateur dans une plage préaffectée d’UIDs
  • Exige qu’un pod soit exécuté avec une étiquette MCS préaffectée
  • Exige qu’un pod soit exécuté avec un groupe FS préaffecté
  • Autorise les gousses à utiliser n’importe quel groupe supplémentaire

Dans les clusters qui ont été mis à niveau à partir d’OpenShift Dedicated 4.10 ou antérieur, ce SCC est disponible pour utilisation par tout utilisateur authentifié. Le SCC restreint n’est plus disponible pour les utilisateurs de nouvelles installations OpenShift Dedicated 4.11 ou ultérieures, sauf si l’accès est explicitement accordé.

limité-v2

Comme le CCN restreint, mais avec les différences suivantes:

  • Toutes les capacités sont supprimées des conteneurs.
  • La capacité NET_BIND_SERVICE peut être ajoutée explicitement.
  • le fichier seccompProfile est défini sur runtime/par défaut par défaut.
  • AuthorPrivilegeEscalation doit être non défini ou défini sur false dans des contextes de sécurité.

Il s’agit du SCC le plus restrictif fourni par une nouvelle installation et sera utilisé par défaut pour les utilisateurs authentifiés.

Note

Le CCN restreint-v2 est le plus restrictif des CSC qui est inclus par défaut avec le système. Cependant, vous pouvez créer un CSC personnalisé qui est encore plus restrictif. À titre d’exemple, vous pouvez créer un SCC qui limite readOnlyRootFilesystem à true.

Les contraintes de contexte de sécurité (SCC) sont composées de paramètres et de stratégies qui contrôlent les fonctionnalités de sécurité auxquelles un pod a accès. Ces paramètres se répartissent en trois catégories:

Expand
CatégorieDescription

Contrôlé par un booléen

Les champs de ce type par défaut à la valeur la plus restrictive. À titre d’exemple, AllowPrivilegedContainer est toujours mis à faux s’il n’est pas spécifié.

Contrôlé par un ensemble admissible

Les champs de ce type sont vérifiés par rapport à l’ensemble pour s’assurer que leur valeur est autorisée.

Contrôlé par une stratégie

Les éléments qui ont une stratégie pour générer une valeur fournissent:

  • D’un mécanisme pour générer la valeur, et
  • D’un mécanisme permettant de s’assurer qu’une valeur spécifiée tombe dans l’ensemble des valeurs admissibles.

CRI-O a la liste par défaut suivante des capacités qui sont autorisées pour chaque conteneur d’un pod:

  • CHOWN
  • DAC_OVERRIDE
  • FSETID
  • FOWNER
  • À PROPOS DE SETGID
  • ♪ SETUID ♪
  • LE SETPCAP
  • ACCUEIL NET_BIND_SERVICE
  • ♪ TUE ♪

Les conteneurs utilisent les capacités de cette liste par défaut, mais les auteurs de manifestes de pod peuvent modifier la liste en demandant des capacités supplémentaires ou en supprimant certains des comportements par défaut. Employez les paramètres AutoriséCapities, defaultAddCapities et NeedDropCapities pour contrôler ces requêtes à partir des pods. Avec ces paramètres, vous pouvez spécifier quelles capacités peuvent être demandées, celles qui doivent être ajoutées à chaque conteneur, et celles qui doivent être interdites, ou abandonnées, de chaque conteneur.

Note

Il est possible de supprimer tous les capabilites des conteneurs en réglant le paramètre DropCapities requis sur TOUS. C’est ce que fait le CCN limité-v2.

13.1.3. Contraintes du contexte de sécurité
Copier lien

RunAsUser

  • Il faut qu’un runAsUser soit configuré. Utilise le runAsUser configuré par défaut. Il valide par rapport au runAsUser configuré.

    Exemple MustRunAs snippet

    ...
runAsUser:
  type: MustRunAs
  uid: <id>
...
    Copy to Clipboard Toggle word wrap

  • Les valeurs minimales et maximales doivent être définies si elles n’utilisent pas des valeurs préaffectées. Utilise le minimum par défaut. Il valide par rapport à l’ensemble de la gamme autorisée.

    Exemple MustRunAsRange snippet

    ...
runAsUser:
  type: MustRunAsRange
  uidRangeMax: <maxvalue>
  uidRangeMin: <minvalue>
...
    Copy to Clipboard Toggle word wrap

  • MustRunAsNonRoot - exige que le pod soit soumis avec un runasUser non nul ou que la directive UTILISATEUR soit définie dans l’image. Aucun défaut fourni.

    Exemple MustRunAsNonRoot snippet

    ...
runAsUser:
  type: MustRunAsNonRoot
...
    Copy to Clipboard Toggle word wrap

  • RunAsAny - Aucune valeur par défaut n’est fournie. Permet de spécifier n’importe quel runAsUser.

    Exemple RunAsAny snippet

    ...
runAsUser:
  type: RunAsAny
...
    Copy to Clipboard Toggle word wrap

À propos de SELinuxContext

  • Il faut configurer seLinuxOptions s’il n’utilise pas de valeurs préaffectées. Utilise seLinuxOptions par défaut. Il valide contre seLinuxOptions.
  • RunAsAny - Aucune valeur par défaut n’est fournie. Permet de spécifier toutes les options seLinux.

Groupes complémentaires

  • MustRunAs - exige qu’au moins une plage soit spécifiée si elle n’utilise pas de valeurs préaffectées. Utilise la valeur minimale de la première plage comme valeur par défaut. Il valide toutes les gammes.
  • RunAsAny - Aucune valeur par défaut n’est fournie. Permet de spécifier tout groupe supplémentaire.

Groupe FS

  • MustRunAs - exige qu’au moins une plage soit spécifiée si elle n’utilise pas de valeurs préaffectées. Utilise la valeur minimale de la première plage comme valeur par défaut. Il valide par rapport au premier ID de la première gamme.
  • RunAsAny - Aucune valeur par défaut n’est fournie. Permet de spécifier n’importe quel ID fsGroup.

13.1.4. Contrôle des volumes pour les clusters CCS
Copier lien

L’utilisation de types de volume spécifiques pour OpenShift Dedicated with Customer Cloud Subscription (CCS) peut être contrôlée en définissant le champ de volumes du SCC.

Les valeurs admissibles de ce champ correspondent aux sources de volume définies lors de la création d’un volume:

L’ensemble minimum recommandé de volumes autorisés pour les nouveaux CCN est configMap, downAPI, emptyDir, persistantVolumeClaim, secret et projeté.

Note

Cette liste de types de volume autorisés n’est pas exhaustive car de nouveaux types sont ajoutés à chaque version d’OpenShift Dedicated.

Note

En cas de rétrocompatibilité, l’utilisation de allowHostDirVolumePlugin remplace les paramètres dans le champ des volumes. À titre d’exemple, si l’autorisationHostDirVolumePlugin est définie sur false mais autorisée dans le champ volumes, la valeur hostPath sera supprimée des volumes.

13.1.5. Contrôle d’admission
Copier lien

Le contrôle d’admission avec les CCN permet de contrôler la création de ressources en fonction des capacités accordées à un utilisateur.

En ce qui concerne les CSC, cela signifie qu’un contrôleur d’admission peut inspecter les informations de l’utilisateur mises à disposition dans le contexte pour récupérer un ensemble approprié de CSC. Cela garantit que le pod est autorisé à faire des demandes sur son environnement d’exploitation ou à générer un ensemble de contraintes à appliquer à la gousse.

L’ensemble de CSC que l’admission utilise pour autoriser un pod sont déterminés par l’identité de l’utilisateur et les groupes auxquels l’utilisateur appartient. De plus, si la pod spécifie un compte de service, l’ensemble des CSC admissibles comprend toutes les contraintes accessibles au compte de service.

Note

Lorsque vous créez une ressource de charge de travail, comme le déploiement, seul le compte de service est utilisé pour trouver les CCN et admettre les pods lorsqu’ils sont créés.

L’admission utilise l’approche suivante pour créer le contexte de sécurité final pour le pod:

  1. Découvrez tous les CCN disponibles pour l’utilisation.
  2. Générez des valeurs de champ pour les paramètres de contexte de sécurité qui n’ont pas été spécifiés sur la demande.
  3. Validez les paramètres finaux par rapport aux contraintes disponibles.

Lorsqu’un ensemble de contraintes est trouvé, le pod est accepté. Dans le cas où la demande ne peut pas être appariée à une CSC, le pod est rejeté.

La gousse doit valider tous les champs par rapport au CCN. Ce qui suit sont des exemples pour seulement deux des champs qui doivent être validés:

Note

Ces exemples sont dans le contexte d’une stratégie utilisant les valeurs préaffectées.

La stratégie FSGroup SCC de MustRunAs

Lorsque le pod définit un ID fsGroup, cet ID doit être égal à l’ID fsGroup par défaut. Dans le cas contraire, le pod n’est pas validé par ce CCN et le prochain CSC est évalué.

Lorsque le champ SecurityContextConstraints.fsGroup a une valeur RunAsAny et que la spécification de pod omet le Pod.spec.securityContext.fsGroup, ce champ est considéré comme valide. Il est possible que lors de la validation, d’autres paramètres SCC rejettent d’autres champs de pod et causent ainsi l’échec de la dose.

La stratégie du CCN des groupes complémentaires de MustRunAs

Dans le cas où la spécification du pod définit un ou plusieurs IDs de groupes supplémentaires, les identifiants du pod doivent être égaux à l’un des ID de l’annotation openshift.io/sa.scc.supplémental-groups de l’espace de noms. Dans le cas contraire, le pod n’est pas validé par ce CCN et le prochain CSC est évalué.

Lorsque le champ SecurityContextConstraints.supplementalGroups a une valeur RunAsAny et que la spécification de pod omet le Pod.spec.securityContext.supplementalGroups, ce champ est considéré comme valide. Il est possible que lors de la validation, d’autres paramètres SCC rejettent d’autres champs de pod et causent ainsi l’échec de la dose.

13.1.6. Contraintes liées au contexte de sécurité
Copier lien

Les contraintes de contexte de sécurité (SCC) ont un champ prioritaire qui affecte la commande lorsque vous tentez de valider une demande du contrôleur d’admission.

La valeur prioritaire de 0 est la priorité la plus faible possible. La priorité zéro est considérée comme une priorité 0 ou inférieure. Les CCN prioritaires sont déplacés vers l’avant de l’ensemble lors du tri.

Lorsque l’ensemble complet des CSC disponibles est déterminé, les CSC sont ordonnés de la manière suivante:

  1. Les CCN prioritaires sont commandés en premier.
  2. Lorsque les priorités sont égales, les CSC sont classés de la plus restrictive à la moins restrictive.
  3. Lorsque les priorités et les restrictions sont égales, les CSC sont triés par nom.

Le CCN en tout état de cause accordé aux administrateurs de clusters par défaut est donné la priorité dans leur ensemble de CSC. Cela permet aux administrateurs de clusters d’exécuter des pods comme n’importe quel utilisateur en spécifiant RunAsUser dans SecurityContext du pod.

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