14.2. À propos de la synchronisation de l’admission de sécurité de pod
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.
14.2.1. Exclusions de l’espace de noms de synchronisation de l’entrée de Pod en matière de sécurité Copier lienLien copié sur presse-papiers!
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-