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).
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
FSGroupqui 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
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.
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.
| Contrainte du contexte de sécurité | Description |
|---|---|
|
|
Fournit toutes les fonctionnalités du SCC |
|
| 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. |
|
|
Fournit toutes les fonctionnalités du SCC 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. |
|
| 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 à |
|
|
Comme le
|
|
| 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. |
|
|
Fournit toutes les fonctionnalités de |
|
|
Comme le
|
|
| 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
Note
Le fait de définir |
|
| 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
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 |
|
|
Comme le
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 |
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égorie | Description |
|---|---|
| Contrôlé par un booléen |
Les champs de ce type prennent par défaut la valeur la plus restrictive. Par exemple, |
| 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 :
|
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.
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 derunAsUser. Utilise le siterunAsUserconfiguré comme valeur par défaut. Valide par rapport à l'adresserunAsUserconfigurée.Exemple
MustRunAssnippet... 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
MustRunAsRangesnippet... runAsUser: type: MustRunAsRange uidRangeMax: <maxvalue> uidRangeMin: <minvalue> ...
MustRunAsNonRoot- Nécessite que le pod soit soumis avec unrunAsUsernon nul ou que la directiveUSERsoit définie dans l'image. Aucune valeur par défaut n'est fournie.Exemple
MustRunAsNonRootsnippet... runAsUser: type: MustRunAsNonRoot ...
RunAsAny- Aucune valeur par défaut n'est fournie. Permet de spécifier n'importe quellerunAsUser.Exemple
RunAsAnysnippet... runAsUser: type: RunAsAny ...
SELinuxContext
-
MustRunAs- Nécessite la configuration deseLinuxOptionssi l'on n'utilise pas de valeurs pré-allouées. UtiliseseLinuxOptionscomme valeur par défaut. Valide par rapport àseLinuxOptions. -
RunAsAny- Aucune valeur par défaut n'est fournie. Permet de spécifier n'importe quelleseLinuxOptions.
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 quellesupplementalGroups.
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 identifiantfsGroup.
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 :
-
awsElasticBlockStore -
azureDisk -
azureFile -
cephFS -
cinder -
configMap -
downwardAPI -
emptyDir -
fc -
flexVolume -
flocker -
gcePersistentDisk -
gitRepo -
glusterfs -
hostPath -
iscsi -
nfs -
persistentVolumeClaim -
photonPersistentDisk -
portworxVolume -
projected -
quobyte -
rbd -
scaleIO -
secret -
storageos -
vsphereVolume - * (Une valeur spéciale pour permettre l'utilisation de tous les types de volumes)
-
none(Une valeur spéciale pour interdire l'utilisation de tous les types de volumes. N'existe que pour la compatibilité ascendante)
L'ensemble minimal recommandé de volumes autorisés pour les nouveaux CCN est le suivant : configMap, downwardAPI, emptyDir, persistentVolumeClaim, secret, et projected.
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.
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 :
- Récupérer tous les CCN disponibles pour utilisation.
- 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.
- 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 :
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 :
- Les CSC les plus prioritaires sont commandés en premier.
- Si les priorités sont égales, les CSC sont classées de la plus restrictive à la moins restrictive.
- 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.
