Chapitre 12. Configuration des profils seccomp
Un conteneur OpenShift Container Platform ou un pod exécute une application unique qui effectue une ou plusieurs tâches bien définies. L'application ne nécessite généralement qu'un petit sous-ensemble des API du noyau du système d'exploitation sous-jacent. Le mode de calcul sécurisé, seccomp, est une fonctionnalité du noyau Linux qui peut être utilisée pour limiter le processus s'exécutant dans un conteneur à l'utilisation d'un sous-ensemble d'appels système disponibles.
Le SCC restricted-v2 s'applique à tous les pods nouvellement créés dans la version 4.12. Le profil seccomp par défaut runtime/default est appliqué à ces modules.
Les profils Seccomp sont stockés sous forme de fichiers JSON sur le disque.
Les profils Seccomp ne peuvent pas être appliqués aux conteneurs privilégiés.
12.1. Vérification du profil seccomp par défaut appliqué à un pod
OpenShift Container Platform est livré avec un profil seccomp par défaut qui est référencé comme runtime/default. Dans la version 4.12, les pods nouvellement créés ont la contrainte de contexte de sécurité (SCC) définie sur restricted-v2 et le profil seccomp par défaut s'applique au pod.
Procédure
Vous pouvez vérifier la contrainte de contexte de sécurité (SCC) et le profil seccomp par défaut défini sur un pod en exécutant les commandes suivantes :
Vérifier quels pods sont en cours d'exécution dans l'espace de noms :
$ oc get pods -n <namespace>
Par exemple, pour vérifier quels pods sont en cours d'exécution dans l'espace de noms
workshop, exécutez ce qui suit :$ oc get pods -n workshop
Exemple de sortie
NAME READY STATUS RESTARTS AGE parksmap-1-4xkwf 1/1 Running 0 2m17s parksmap-1-deploy 0/1 Completed 0 2m22s
Inspecter les gousses :
$ oc get pod parksmap-1-4xkwf -n workshop -o yaml
Exemple de sortie
apiVersion: v1 kind: Pod metadata: annotations: k8s.v1.cni.cncf.io/network-status: |- [{ "name": "openshift-sdn", "interface": "eth0", "ips": [ "10.131.0.18" ], "default": true, "dns": {} }] k8s.v1.cni.cncf.io/networks-status: |- [{ "name": "openshift-sdn", "interface": "eth0", "ips": [ "10.131.0.18" ], "default": true, "dns": {} }] openshift.io/deployment-config.latest-version: "1" openshift.io/deployment-config.name: parksmap openshift.io/deployment.name: parksmap-1 openshift.io/generated-by: OpenShiftWebConsole openshift.io/scc: restricted-v2 1 seccomp.security.alpha.kubernetes.io/pod: runtime/default 2
12.1.1. Cluster amélioré
Dans les clusters mis à jour vers la version 4.12, tous les utilisateurs authentifiés ont accès à restricted et restricted-v2 SCC.
Une charge de travail admise par le SCC restricted par exemple, sur un cluster OpenShift Container Platform v4.10 lors d'une mise à niveau peut être admise par restricted-v2. En effet, restricted-v2 est le SCC le plus restrictif entre restricted et restricted-v2.
La charge de travail doit pouvoir être exécutée à l'adresse retricted-v2.
À l'inverse, dans le cas d'une charge de travail nécessitant privilegeEscalation: true, cette charge de travail continuera à disposer du CSC restricted pour tout utilisateur authentifié. En effet, restricted-v2 n'autorise pas privilegeEscalation.
12.1.2. Cluster nouvellement installé
Pour les clusters OpenShift Container Platform 4.11 ou ultérieurs nouvellement installés, le restricted-v2 remplace le restricted SCC en tant que SCC disponible pour être utilisé par n'importe quel utilisateur authentifié. Une charge de travail avec privilegeEscalation: true, n'est pas admise dans le cluster car restricted-v2 est le seul SCC disponible par défaut pour les utilisateurs authentifiés.
L'élément privilegeEscalation est autorisé par restricted mais pas par restricted-v2. Le nombre de fonctionnalités refusées par restricted-v2 est supérieur au nombre de fonctionnalités autorisées par restricted SCC.
Une charge de travail avec privilegeEscalation: true peut être admise dans un cluster OpenShift Container Platform 4.11 ou plus récent. Pour donner accès au SCC restricted au ServiceAccount qui exécute la charge de travail (ou tout autre SCC qui peut admettre cette charge de travail) à l'aide d'un RoleBinding, exécutez la commande suivante :
oc -n <workload-namespace> adm policy add-scc-to-user <scc-name> -z <serviceaccount_name>
Dans OpenShift Container Platform 4.12, la possibilité d'ajouter les annotations pod seccomp.security.alpha.kubernetes.io/pod: runtime/default et container.seccomp.security.alpha.kubernetes.io/<container_name>: runtime/default est obsolète.
