Chapitre 13. Comprendre et gérer l’admission à la sécurité des pod
L’admission à la sécurité de Pod est une mise en œuvre des normes de sécurité des pod Kubernetes. Il faut utiliser l’admission de sécurité de pod pour restreindre le comportement des gousses.
13.1. À propos de l’admission à la sécurité de pod
Le service OpenShift Red Hat sur AWS inclut l’admission à la sécurité des pod Kubernetes. Les pods qui ne sont pas conformes à l’admission de sécurité pod définie globalement ou au niveau de l’espace de noms ne sont pas admis au cluster et ne peuvent pas s’exécuter.
À l’échelle mondiale, le profil privilégié est appliqué et le profil restreint est utilisé pour les avertissements et les audits.
Il est également possible de configurer les paramètres d’entrée de sécurité pod au niveau de l’espace de noms.
Évitez d’exécuter des charges de travail ou de partager l’accès aux projets par défaut. Les projets par défaut sont réservés à l’exécution de composants de cluster de base.
Les projets par défaut suivants sont considérés comme hautement privilégiés: par défaut, kube-public, kube-system, openshift, openshift-infra, openshift-node, et d’autres projets créés par système qui ont l’étiquette openshift.io / run-level définie à 0 ou 1. La fonctionnalité qui repose sur des plugins d’admission, tels que l’admission de sécurité pod, les contraintes de contexte de sécurité, les quotas de ressources de cluster et la résolution de référence d’image, ne fonctionne pas dans des projets hautement privilégiés.
13.1.1. Les modes d’admission à la sécurité de Pod
Les modes d’admission de sécurité pod suivants peuvent être configurés pour un espace de noms:
Le mode | Étiquette | Description |
---|---|---|
|
| Il rejette un pod d’admission s’il ne se conforme pas au profil défini |
|
| Enregistre les événements d’audit si un pod ne se conforme pas au profil défini |
|
| Affiche les avertissements si un pod ne se conforme pas au profil défini |
13.1.2. Les profils d’admission à la sécurité de Pod
Chacun des modes d’admission à la sécurité de pod peut être défini sur l’un des profils suivants:
Le profil | Description |
---|---|
| La politique la moins restrictive; permet une escalade connue des privilèges |
| La politique minimalement restrictive; empêche les escalades de privilèges connues |
| La politique la plus restrictive; suit les meilleures pratiques actuelles de durcissement de la pod |
13.1.3. Espaces de noms privilégiés
Les espaces de noms système suivants sont toujours définis sur le profil d’admission de sécurité de pod privilégié:
-
défaut par défaut
-
Kube-public
-
Kube-système
Il est impossible de modifier le profil de sécurité des pod pour ces espaces de noms privilégiés.
13.1.4. Conditions d’admission en matière de sécurité et contraintes liées au contexte de sécurité
Les normes d’admission en matière de sécurité de Pod et les contraintes liées au contexte de sécurité sont réconciliées et appliquées par deux contrôleurs indépendants. Les deux contrôleurs travaillent indépendamment en utilisant les processus suivants pour appliquer les politiques de sécurité:
- Le contrôleur de contrainte du contexte de sécurité peut muter certains champs de contexte de sécurité selon le SCC assigné par le pod. À titre d’exemple, si le profil seccomp est vide ou non défini et si le champ SCC assigné par le pod applique le champ seccompProfiles pour être runtime/default, le contrôleur définit le type par défaut sur RuntimeDefault.
- Le contrôleur de contrainte du contexte de sécurité valide le contexte de sécurité de la pod par rapport au SCC correspondant.
- Le contrôleur d’admission de sécurité de pod valide le contexte de sécurité du pod par rapport à la norme de sécurité de pod assignée à l’espace de noms.