5.9. Respecter l'admission à la sécurité des pods
Pod security admission est une implémentation des standards de sécurité des pods de Kubernetes. L'admission de sécurité des pods restreint le comportement des pods. Les pods qui ne sont pas conformes à l'admission de sécurité des pods définie globalement ou au niveau de l'espace de noms ne sont pas admis dans le cluster et ne peuvent pas s'exécuter.
Si votre projet Operator ne nécessite pas d'autorisations accrues 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é du pod restricted. Si votre projet Operator nécessite des autorisations d'escalade pour s'exécuter, vous devez définir les configurations de contexte de sécurité suivantes :
- Niveau d'admission à la sécurité du pod autorisé pour l'espace de noms de l'opérateur
- Les contraintes de contexte de sécurité (SCC) autorisées 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 pods.
5.9.1. Synchronisation des contraintes du contexte de sécurité avec les normes de sécurité des pods
OpenShift Container Platform inclut l'admission de sécurité des pods Kubernetes. Globalement, le profil privileged est appliqué et le profil restricted est utilisé pour les avertissements et les audits.
En plus de la configuration globale du contrôle d'admission à la sécurité des pods, il existe un contrôleur qui applique les étiquettes de contrôle d'admission à la sécurité des pods warn et audit aux espaces de noms en fonction des autorisations SCC des comptes de service qui se trouvent dans un espace de noms donné.
La synchronisation de l'admission à la sécurité des pods est désactivée en permanence pour les espaces de noms définis comme faisant partie de la charge utile du cluster. Vous pouvez activer la synchronisation de l'admission à la sécurité des pods sur d'autres espaces de noms si nécessaire. Si un opérateur est installé dans un espace de noms openshift-* créé par l'utilisateur, la synchronisation est activée par défaut après la création d'une version de service de cluster (CSV) dans l'espace de noms.
Le contrôleur examine les autorisations de l'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 converties en profils de sécurité de pods en fonction de leurs valeurs de champ ; le contrôleur utilise ces profils traduits. Les étiquettes d'admission à la sécurité des modules warn et audit sont définies sur le profil de sécurité de module le plus privilégié trouvé dans l'espace de noms afin d'éviter les avertissements et la journalisation d'audit lors de la création des modules.
L'étiquetage de l'espace de nommage est basé sur la prise en compte des privilèges du compte de service local de l'espace de nommage.
L'application directe des pods peut 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.
5.9.2. Veiller à ce que les charges de travail de l'opérateur s'exécutent dans des espaces de noms définis au niveau de sécurité "restricted pod"
Pour que votre projet Operator puisse fonctionner dans une grande variété de déploiements et d'environnements, configurez les charges de travail de l'Operator pour qu'elles s'exécutent dans des espaces de noms définis au niveau de sécurité du pod restricted.
Vous devez laisser le champ runAsUser vide. Si votre image nécessite un utilisateur spécifique, elle ne peut pas être exécutée avec des contraintes de contexte de sécurité restreintes (SCC) et une application restreinte de la sécurité des pods.
Procédure
Pour configurer les charges de travail de l'opérateur afin qu'elles s'exécutent dans des espaces de noms définis au niveau de sécurité du pod
restricted, modifiez la définition de l'espace de noms de votre opérateur comme dans les exemples suivants :ImportantIl est recommandé de définir le profil seccomp dans la définition de l'espace de noms de votre opérateur. Cependant, la définition du profil seccomp n'est pas prise en charge dans OpenShift Container Platform 4.10.
Pour les projets Operator qui doivent fonctionner uniquement sur OpenShift Container Platform 4.11 et plus, modifiez la définition de l'espace de noms de votre Operator comme dans 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 ...- 1
- En définissant le type de profil seccomp sur
RuntimeDefault, le SCC utilise par défaut le profil de sécurité pod de l'espace de noms.
Pour les projets Operator qui doivent également fonctionner dans OpenShift Container Platform 4.10, modifiez la définition de l'espace de noms de votre Operator comme dans 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 ...- 1
- En laissant le type de profil seccomp non défini, votre projet Operator peut fonctionner dans OpenShift Container Platform 4.10.
Ressources supplémentaires
5.9.3. Gestion de l'admission à la sécurité des pods pour les charges de travail de l'opérateur qui nécessitent des autorisations accrues
Si votre projet d'opérateur nécessite des autorisations élargies pour fonctionner, vous devez modifier la version du service de cluster (CSV) de votre opérateur.
Procédure
Définissez la configuration du contexte de sécurité au niveau d'autorisation requis dans le CSV de votre opérateur, comme dans l'exemple suivant :
Exemple
<operator_name>.clusterserviceversion.yamlfichier avec les privilèges d'un administrateur de réseau... containers: - name: my-container securityContext: allowPrivilegeEscalation: false capabilities: add: - "NET_ADMIN" ...Définissez les privilèges du 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 dans l'exemple suivant :
Exemple de fichier
<operator_name>.clusterserviceversion.yaml... install: spec: clusterPermissions: - rules: - apiGroups: - security.openshift.io resourceNames: - privileged resources: - securitycontextconstraints verbs: - use serviceAccountName: default ...Modifiez la description CSV de votre opérateur pour expliquer pourquoi votre projet d'opérateur nécessite des autorisations accrues, comme dans l'exemple suivant :
Exemple de fichier
<operator_name>.clusterserviceversion.yaml... 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.
