15.3. Exemple de contraintes liées au contexte de sécurité
Les exemples suivants montrent le format et les annotations des contraintes du contexte de sécurité (SCC) :
privileged SCC annoté
allowHostDirVolumePlugin: true allowHostIPC: true allowHostNetwork: true allowHostPID: true allowHostPorts: true allowPrivilegedContainer: true allowedCapabilities: 1 - '*' apiVersion: security.openshift.io/v1 defaultAddCapabilities: [] 2 fsGroup: 3 type: RunAsAny groups: 4 - system:cluster-admins - system:nodes kind: SecurityContextConstraints metadata: annotations: kubernetes.io/description: 'privileged allows access to all privileged and host features and the ability to run as any user, any group, any fsGroup, and with any SELinux context. WARNING: this is the most relaxed SCC and should be used only for cluster administration. Grant with caution.' creationTimestamp: null name: privileged priority: null readOnlyRootFilesystem: false requiredDropCapabilities: 5 - KILL - MKNOD - SETUID - SETGID runAsUser: 6 type: RunAsAny seLinuxContext: 7 type: RunAsAny seccompProfiles: - '*' supplementalGroups: 8 type: RunAsAny users: 9 - system:serviceaccount:default:registry - system:serviceaccount:default:router - system:serviceaccount:openshift-infra:build-controller volumes: 10 - '*'
- 1
- Liste des capacités qu'un pod peut demander. Une liste vide signifie qu'aucune capacité ne peut être demandée, tandis que le symbole spécial
*autorise toutes les capacités. - 2
- Liste des capacités supplémentaires qui sont ajoutées à un pod.
- 3
- La stratégie
FSGroup, qui dicte les valeurs autorisées pour le contexte de sécurité. - 4
- Les groupes qui peuvent accéder à ce CCN.
- 5
- Une liste de capacités à supprimer d'un module. Vous pouvez également spécifier
ALLpour supprimer 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
supplementalGroups, qui dicte les groupes supplémentaires autorisés pour le contexte de sécurité. - 9
- Les utilisateurs qui peuvent accéder à ce CCN.
- 10
- Les types de volumes autorisés pour le contexte de sécurité. Dans l'exemple,
*autorise l'utilisation de tous les types de volumes.
Les champs users et groups du SCC contrôlent les utilisateurs qui peuvent accéder au SCC. Par défaut, les administrateurs de cluster, les nœuds et le contrôleur de construction ont accès au SCC privilégié. Tous les utilisateurs authentifiés ont accès au SCC restricted-v2.
Sans réglage explicite de runAsUser
apiVersion: v1
kind: Pod
metadata:
name: security-context-demo
spec:
securityContext: 1
containers:
- name: sec-ctx-demo
image: gcr.io/google-samples/node-hello:1.0
- 1
- Lorsqu'un conteneur ou un pod ne demande pas d'identifiant sous lequel il doit être exécuté, l'UID effectif dépend du SCC qui émet ce pod. Comme le SCC
restricted-v2est accordé par défaut à tous les utilisateurs authentifiés, il sera disponible pour tous les utilisateurs et comptes de service et utilisé dans la plupart des cas. Le SCCrestricted-v2utilise la stratégieMustRunAsRangepour contraindre et définir par défaut les valeurs possibles du champsecurityContext.runAsUser. Le plugin d'admission recherchera l'annotationopenshift.io/sa.scc.uid-rangesur le projet actuel pour remplir les champs de la plage, car il ne fournit pas cette plage. Au final, un conteneur aurarunAsUserégal à la première valeur de l'intervalle, ce qui est difficile à prévoir car chaque projet a des intervalles différents.
Avec un réglage explicite de runAsUser
apiVersion: v1
kind: Pod
metadata:
name: security-context-demo
spec:
securityContext:
runAsUser: 1000 1
containers:
- name: sec-ctx-demo
image: gcr.io/google-samples/node-hello:1.0
- 1
- Un conteneur ou un pod qui demande un identifiant spécifique sera accepté par OpenShift Container Platform seulement si un compte de service ou un utilisateur a accès à un SCC qui autorise un tel identifiant. Le SCC peut autoriser des identifiants arbitraires, un identifiant compris dans une fourchette, ou l'identifiant exact spécifique à la demande.
Cette configuration est valable pour SELinux, fsGroup et Supplemental Groups.
