Chapitre 15. Gestion des contraintes liées au contexte de sécurité


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

Les SCC par défaut sont créés lors de 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 la CLI OpenShift (oc).

Important

Ne modifiez pas les SCC par défaut. La personnalisation des SCC par défaut peut entraîner des problèmes lors du déploiement de certains pods de la plateforme ou lors de la mise à jour d'OpenShift Container Platform. De plus, les valeurs par défaut des SCC sont réinitialisées lors de certaines mises à niveau de clusters, ce qui annule toutes les personnalisations de ces SCC.

Au lieu de modifier les SCC par défaut, créez et modifiez vos propres SCC si nécessaire. Pour plus d'informations, voir Création de contraintes de contexte de sécurité.

15.1. A propos des contraintes du contexte de sécurité

De la même manière que 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 des modules. Ces autorisations déterminent les actions qu'un module peut effectuer et les ressources auxquelles il peut accéder. Vous pouvez utiliser les SCC pour définir un ensemble de conditions qu'un module doit respecter pour être accepté dans le système.

Les contraintes liées au contexte de sécurité permettent à l'administrateur de contrôler :

  • Si un pod peut exécuter des conteneurs privilégiés avec le drapeau allowPrivilegedContainer
  • Si un pod est contraint par le drapeau allowPrivilegeEscalation
  • Les capacités qu'un conteneur peut demander
  • L'utilisation de répertoires d'hôtes en tant que volumes
  • Le contexte SELinux du conteneur
  • L'identifiant de l'utilisateur du conteneur
  • L'utilisation des espaces de noms d'hôtes et des réseaux
  • L'attribution d'un FSGroup qui possède les volumes de pods
  • La configuration des groupes supplémentaires autorisés
  • Si un conteneur nécessite un accès en écriture à son système de fichiers racine
  • L'utilisation des types de volumes
  • La configuration des profils autorisés seccomp
Important

Ne définissez pas l'étiquette openshift.io/run-level sur les espaces de noms dans OpenShift Container Platform. Ce label est utilisé par les composants internes d'OpenShift Container Platform pour gérer le démarrage des principaux groupes d'API, tels que le serveur d'API Kubernetes et le serveur d'API OpenShift. Si le label openshift.io/run-level est défini, aucun SCC n'est appliqué aux pods dans cet espace de noms, ce qui fait que toutes les charges de travail s'exécutant dans cet espace de noms sont hautement privilégiées.

15.1.1. Contraintes de contexte de sécurité par défaut

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

Important

Ne modifiez pas les SCC par défaut. La personnalisation des SCC par défaut peut entraîner des problèmes lors du déploiement de certains pods de la plateforme ou lors de la mise à jour d'OpenShift Container Platform. De plus, les valeurs par défaut des SCC sont réinitialisées lors de certaines mises à niveau de clusters, ce qui annule toutes les personnalisations de ces SCC.

Au lieu de modifier les SCC par défaut, créez et modifiez vos propres SCC selon vos besoins. Pour connaître les étapes détaillées, voir Creating security context constraints.

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

anyuid

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

hostaccess

Permet l'accès à tous les espaces de noms d'hôtes, mais exige toujours que les pods soient exécutés avec un UID et un contexte SELinux alloués à l'espace de noms.

Avertissement

Ce SCC permet à l'hôte d'accéder aux espaces de noms, aux systèmes de fichiers et aux PID. Il ne doit être utilisé que par des pods de confiance. Accordez-le avec prudence.

hostmount-anyuid

Fournit toutes les fonctionnalités du SCC restricted, mais permet les montages d'hôtes et l'exécution sous n'importe quel UID et GID sur le système.

Avertissement

Ce SCC autorise l'accès au système de fichiers de l'hôte sous n'importe quel UID, y compris l'UID 0. A accorder avec prudence.

hostnetwork

Permet d'utiliser le réseau et les ports de l'hôte, mais exige toujours que les pods soient exécutés avec un UID et un contexte SELinux alloués à l'espace de noms.

Avertissement

Si d'autres charges de travail sont exécutées sur des hôtes du plan de contrôle, soyez prudent lorsque vous donnez accès à hostnetwork. Une charge de travail qui exécute hostnetwork sur un hôte du plan de contrôle est en fait la racine du cluster et doit être approuvée en conséquence.

hostnetwork-v2

Comme le hostnetwork SCC, mais avec les différences suivantes :

  • ALL sont retirées des conteneurs.
  • La capacité NET_BIND_SERVICE peut être ajoutée explicitement.
  • seccompProfile est fixé par défaut à runtime/default.
  • allowPrivilegeEscalation doit être désactivé ou fixé à false dans les contextes de sécurité.

node-exporter

Utilisé pour l'exportateur de nœuds Prometheus.

Avertissement

Ce SCC autorise l'accès au système de fichiers de l'hôte sous n'importe quel UID, y compris l'UID 0. A accorder avec prudence.

nonroot

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

nonroot-v2

Comme le nonroot SCC, mais avec les différences suivantes :

  • ALL sont retirées des conteneurs.
  • La capacité NET_BIND_SERVICE peut être ajoutée explicitement.
  • seccompProfile est fixé par défaut à runtime/default.
  • allowPrivilegeEscalation doit être désactivé ou fixé à false dans les contextes de sécurité.

privileged

Permet d'accéder à toutes les fonctions privilégiées et hôtes et de s'exécuter en tant qu'utilisateur, groupe, FSGroup et dans n'importe quel contexte SELinux.

Avertissement

Il s'agit du SCC le plus souple et il ne doit être utilisé que pour l'administration de clusters. Il doit être accordé avec prudence.

Le site privileged SCC permet :

  • Utilisateurs pour exécuter des pods privilégiés
  • Pods pour monter les répertoires de l'hôte en tant que volumes
  • Les pods peuvent être exécutés par n'importe quel utilisateur
  • Pods à utiliser avec n'importe quel label MCS
  • Pods pour utiliser l'espace de noms IPC de l'hôte
  • Pods pour utiliser l'espace de noms PID de l'hôte
  • Pods pour utiliser n'importe quel FSGroup
  • Pods pour utiliser n'importe quel groupe supplémentaire
  • Pods pour utiliser n'importe quel profil seccomp
  • Pods pour demander n'importe quelle capacité
Note

Le fait de définir privileged: true dans la spécification du pod ne sélectionne pas nécessairement le SCC privileged. Le SCC qui a allowPrivilegedContainer: true et qui a la priorité la plus élevée sera choisi si l'utilisateur a les permissions de l'utiliser.

restricted

Refuse l'accès à toutes les fonctionnalités de l'hôte et exige que les pods soient exécutés avec un UID et un contexte SELinux qui sont alloués à l'espace de noms.

Le restricted SCC :

  • Veille à ce que les pods ne puissent pas être exécutés en tant que privilégiés
  • Veille à ce que les pods ne puissent pas monter les volumes du répertoire de l'hôte
  • Exige qu'un pod soit exécuté en tant qu'utilisateur dans une gamme pré-attribuée d'UID
  • Nécessite qu'un module soit exécuté avec une étiquette MCS pré-attribuée
  • Permet aux pods d'utiliser n'importe quel FSGroup
  • Permet aux pods d'utiliser n'importe quel groupe supplémentaire

Dans les clusters qui ont été mis à niveau depuis OpenShift Container Platform 4.10 ou une version antérieure, ce SCC est disponible pour être utilisé par tout utilisateur authentifié. Le SCC restricted n'est plus disponible pour les utilisateurs des nouvelles installations d'OpenShift Container Platform 4.11 ou ultérieures, à moins que l'accès ne soit explicitement accordé.

restricted-v2

Comme le restricted SCC, mais avec les différences suivantes :

  • ALL sont retirées des conteneurs.
  • La capacité NET_BIND_SERVICE peut être ajoutée explicitement.
  • seccompProfile est fixé par défaut à runtime/default.
  • allowPrivilegeEscalation doit être désactivé ou fixé à false dans les contextes de sécurité.

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

Note

Le SCC restricted-v2 est le plus restrictif des SCC inclus par défaut dans le système. Cependant, vous pouvez créer un SCC personnalisé encore plus restrictif. Par exemple, vous pouvez créer un SCC qui restreint readOnlyRootFilesystem à true.

15.1.2. Paramètres des contraintes du contexte de sécurité

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

CatégorieDescription

Contrôlé par un booléen

Les champs de ce type prennent par défaut la valeur la plus restrictive. Par exemple, AllowPrivilegedContainer est toujours remplacé par false s'il n'est pas spécifié.

Contrôlé par un ensemble autorisé

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 ajoutée :

  • Un mécanisme pour générer la valeur, et
  • Mécanisme permettant de s'assurer qu'une valeur spécifiée fait partie de l'ensemble des valeurs autorisées.

Le CRI-O dispose de la liste suivante de capacités par défaut qui sont autorisées pour chaque conteneur d'un pod :

  • CHOWN
  • DAC_OVERRIDE
  • FSETID
  • FOWNER
  • SETGID
  • SETUID
  • SETPCAP
  • NET_BIND_SERVICE
  • KILL

Les conteneurs utilisent les capacités de cette liste par défaut, mais les auteurs de manifestes de pods peuvent modifier la liste en demandant des capacités supplémentaires ou en supprimant certains comportements par défaut. Utilisez les paramètres allowedCapabilities, defaultAddCapabilities, et requiredDropCapabilities pour contrôler ces demandes de la part des modules. Ces paramètres permettent de spécifier les capacités qui peuvent être demandées, celles qui doivent être ajoutées à chaque conteneur et celles qui doivent être interdites ou supprimées de chaque conteneur.

Note

Vous pouvez supprimer toutes les capacités des conteneurs en réglant le paramètre requiredDropCapabilities sur ALL. C'est ce que fait le CCN restricted-v2.

15.1.3. Contexte de sécurité contraintes stratégies

Exécuter en tant qu'utilisateur

  • MustRunAs - Nécessite la configuration de runAsUser. Utilise le site runAsUser configuré comme valeur par défaut. Valide par rapport à l'adresse runAsUser configurée.

    Exemple MustRunAs snippet

    ...
    runAsUser:
      type: MustRunAs
      uid: <id>
    ...

  • MustRunAsRange - Nécessite la définition des valeurs minimale et maximale si l'on n'utilise pas de valeurs pré-allouées. Utilise le minimum comme valeur par défaut. Valide par rapport à l'ensemble de la plage autorisée.

    Exemple MustRunAsRange snippet

    ...
    runAsUser:
      type: MustRunAsRange
      uidRangeMax: <maxvalue>
      uidRangeMin: <minvalue>
    ...

  • MustRunAsNonRoot - Nécessite que le pod soit soumis avec un runAsUser non nul ou que la directive USER soit définie dans l'image. Aucune valeur par défaut n'est fournie.

    Exemple MustRunAsNonRoot snippet

    ...
    runAsUser:
      type: MustRunAsNonRoot
    ...

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

    Exemple RunAsAny snippet

    ...
    runAsUser:
      type: RunAsAny
    ...

SELinuxContext

  • MustRunAs - Nécessite la configuration de seLinuxOptions si l'on n'utilise pas de valeurs pré-allouées. Utilise seLinuxOptions comme valeur par défaut. Valide par rapport à seLinuxOptions.
  • RunAsAny - Aucune valeur par défaut n'est fournie. Permet de spécifier n'importe quelle seLinuxOptions.

Groupes supplémentaires

  • MustRunAs - Nécessite la spécification d'au moins une plage si l'on n'utilise pas de valeurs pré-allouées. Utilise la valeur minimale de la première plage comme valeur par défaut. Valide toutes les plages.
  • RunAsAny - Aucune valeur par défaut n'est fournie. Permet de spécifier n'importe quelle supplementalGroups.

FSGroup

  • MustRunAs - Nécessite la spécification d'au moins une plage si l'on n'utilise pas de valeurs pré-allouées. Utilise par défaut la valeur minimale de la première plage. Valide par rapport au premier ID de la première plage.
  • RunAsAny - Aucune valeur par défaut n'est fournie. Permet de spécifier n'importe quel identifiant fsGroup.

15.1.4. Contrôle des volumes

L'utilisation de types de volumes spécifiques peut être contrôlée en définissant le champ volumes du SCC.

Les valeurs autorisées de ce champ correspondent aux sources de volume définies lors de la création d'un volume :

L'ensemble minimal recommandé de volumes autorisés pour les nouveaux CCN est le suivant : configMap, downwardAPI, emptyDir, persistentVolumeClaim, secret, et projected.

Note

Cette liste de types de volumes autorisés n'est pas exhaustive car de nouveaux types sont ajoutés à chaque version d'OpenShift Container Platform.

Note

Pour des raisons de compatibilité ascendante, l'utilisation de allowHostDirVolumePlugin est prioritaire sur les paramètres du champ volumes. Par exemple, si allowHostDirVolumePlugin est défini comme faux mais autorisé dans le champ volumes, la valeur hostPath sera supprimée de volumes.

15.1.5. Contrôle d'admission

Admission control avec les CSC permet de contrôler la création de ressources en fonction des capacités accordées à un utilisateur.

En ce qui concerne les SCC, cela signifie qu'un contrôleur d'admission peut inspecter les informations sur l'utilisateur mises à disposition dans le contexte afin de récupérer un ensemble approprié de SCC. Ce faisant, il s'assure que le module est autorisé à formuler des demandes concernant son environnement opérationnel ou à générer un ensemble de contraintes à appliquer au module.

L'ensemble des CSC que l'admission utilise pour autoriser un module est déterminé par l'identité de l'utilisateur et les groupes auxquels il appartient. En outre, si le module spécifie un compte de service, l'ensemble des CSC autorisées comprend toutes les contraintes accessibles au compte de service.

Admission utilise l'approche suivante pour créer le contexte de sécurité final pour le module :

  1. Récupérer tous les CCN disponibles pour utilisation.
  2. Génère des valeurs de champ pour les paramètres du contexte de sécurité qui n'ont pas été spécifiés dans la demande.
  3. Valider les paramètres finaux en fonction des contraintes disponibles.

Si un ensemble de contraintes correspondantes est trouvé, le module est accepté. Si la demande ne peut être associée à une CSC, le module est rejeté.

Un pod doit valider chaque champ par rapport au CCN. Les exemples suivants ne concernent que deux des champs qui doivent être validés :

Note

Ces exemples s'inscrivent dans le cadre d'une stratégie utilisant les valeurs préallouées.

An FSGroup SCC strategy of MustRunAs

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

Si le champ SecurityContextConstraints.fsGroup a la valeur RunAsAny et que la spécification du module omet Pod.spec.securityContext.fsGroup, ce champ est considéré comme valide. Notez qu'il est possible qu'au cours de la validation, d'autres paramètres du CCN rejettent d'autres champs du module et fassent ainsi échouer le module.

A SupplementalGroups SCC strategy of MustRunAs

Si la spécification du module définit un ou plusieurs identifiants supplementalGroups, les identifiants du module doivent correspondre à l'un des identifiants figurant dans l'annotation openshift.io/sa.scc.supplemental-groups de l'espace de noms. Dans le cas contraire, le pod n'est pas validé par ce SCC et le SCC suivant est évalué.

Si le champ SecurityContextConstraints.supplementalGroups a la valeur RunAsAny et que la spécification du module omet Pod.spec.securityContext.supplementalGroups, ce champ est considéré comme valide. Notez qu'il est possible qu'au cours de la validation, d'autres paramètres du CCN rejettent d'autres champs du module et fassent ainsi échouer le module.

15.1.6. Priorité aux contraintes liées au contexte de sécurité

Les contraintes de contexte de sécurité (SCC) ont un champ de priorité qui affecte l'ordre lors de la tentative de validation d'une demande par le contrôleur d'admission.

Une valeur de priorité de 0 est la priorité la plus basse possible. Une priorité nulle est considérée comme une priorité 0, c'est-à-dire la plus basse. Les CSC ayant une priorité plus élevée sont déplacés vers l'avant de l'ensemble lors du tri.

Lorsque l'ensemble des CCN disponibles est déterminé, les CCN sont classés de la manière suivante :

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

Par défaut, le SCC anyuid accordé aux administrateurs de clusters est prioritaire dans leur jeu de SCC. Cela permet aux administrateurs de cluster d'exécuter des pods en tant que n'importe quel utilisateur en spécifiant RunAsUser dans le SCC du pod SecurityContext.

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.

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 leBlog 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.

© 2024 Red Hat, Inc.