13.3. Exemple de contraintes de contexte de sécurité
Les exemples suivants montrent le format et les annotations du contexte de sécurité (SCC):
CCN privilégié annoté
- 1
- Liste des capacités qu’un pod peut demander. La liste vide signifie qu’aucune des capacités ne peut être demandée alors que le symbole spécial * autorise des capacités.
- 2
- Liste des capacités supplémentaires qui sont ajoutées à n’importe quel pod.
- 3
- La stratégie FSGroup, qui dicte les valeurs admissibles pour le contexte de sécurité.
- 4
- Les groupes qui peuvent accéder à ce CSC.
- 5
- Liste des capacités à supprimer d’un pod. Indiquez TOUT pour laisser tomber toutes les capacités.
- 6
- Le type de stratégie runAsUser, qui dicte les valeurs autorisées pour le contexte de sécurité.
- 7
- Le type de stratégie seLinuxContext, qui dicte les valeurs autorisées pour le contexte de sécurité.
- 8
- La stratégie de groupe complémentaire, qui dicte les groupes supplémentaires admissibles pour le contexte de sécurité.
- 9
- Les utilisateurs qui peuvent accéder à ce SCC.
- 10
- Les types de volume admissibles pour le contexte de sécurité. Dans l’exemple, * permet l’utilisation de tous les types de volume.
Les utilisateurs et les groupes s’affichent sur le contrôle du CCN auquel les utilisateurs peuvent accéder au CCN. Les administrateurs de clusters, les nœuds et le contrôleur de construction bénéficient par défaut d’un accès au SCC privilégié. Les utilisateurs authentifiés bénéficient d’un accès au CCN restreint-v2.
Configuration sans runAsUser explicite
- 1
- Lorsqu’un conteneur ou un pod ne demande pas d’identifiant d’utilisateur sous lequel il doit être exécuté, l’UID efficace dépend du CCN qui émet ce pod. Étant donné que le SCC restreint-v2 est accordé à tous les utilisateurs authentifiés par défaut, il sera disponible pour tous les utilisateurs et comptes de service et utilisés dans la plupart des cas. Le SCC restrictif-v2 utilise la stratégie MustRunAsRange pour limiter et par défaut les valeurs possibles du champ securityContext.runAsUser. Le plugin d’admission cherchera l’annotation de plage openshift.io/sa.scc.uid sur le projet actuel pour peupler les champs de gamme, car il ne fournit pas cette plage. En fin de compte, un conteneur aura runAsUser égal à la première valeur de la gamme qui est difficile à prédire parce que chaque projet a des gammes différentes.
Avec le paramètre runAsUser explicite
- 1
- Le conteneur ou la pod qui demande un identifiant d’utilisateur spécifique ne sera accepté par OpenShift Dedicated que lorsqu’un compte de service ou un utilisateur se voit accorder l’accès à un SCC qui permet un tel identifiant d’utilisateur. Le SCC peut autoriser des ID arbitraires, un ID qui tombe dans une plage, ou l’identifiant d’utilisateur exact spécifique à la demande.
Cette configuration est valable pour les groupes SELinux, fsGroup et Supplémentaires.