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é

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: null 
5

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

- '*'
Copy to Clipboard Toggle word wrap

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

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
Copy to Clipboard Toggle word wrap

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

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
Copy to Clipboard Toggle word wrap

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.

Retour au début
Red Hat logoGithubredditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance. Découvrez nos récentes mises à jour.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez le Blog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

Theme

© 2025 Red Hat