2.11. Sécuriser les constructions par la stratégie


Les builds dans OpenShift Container Platform sont exécutés dans des conteneurs privilégiés. En fonction de la stratégie de construction utilisée, si vous avez des privilèges, vous pouvez exécuter des constructions pour escalader leurs permissions sur le cluster et les nœuds hôtes. En tant que mesure de sécurité, elle limite les personnes autorisées à exécuter des builds et la stratégie utilisée pour ces builds. Les builds personnalisés sont intrinsèquement moins sûrs que les builds source, car ils peuvent exécuter n'importe quel code dans un conteneur privilégié, et sont désactivés par défaut. Accordez les permissions de construction de docker avec prudence, car une vulnérabilité dans la logique de traitement de Dockerfile pourrait entraîner l'octroi de privilèges sur le nœud hôte.

Par défaut, tous les utilisateurs qui peuvent créer des builds sont autorisés à utiliser les stratégies de build docker et Source-to-image (S2I). Les utilisateurs disposant de privilèges d'administrateur de cluster peuvent activer la stratégie de build personnalisée, comme indiqué dans la section restreignant les stratégies de build à un utilisateur de manière globale.

Vous pouvez contrôler qui peut construire et quelles stratégies de construction ils peuvent utiliser en utilisant une politique d'autorisation. Chaque stratégie de construction a une sous-ressource de construction correspondante. Un utilisateur doit avoir l'autorisation de créer un build et l'autorisation de créer sur la sous-ressource de la stratégie de build pour créer des builds utilisant cette stratégie. Des rôles par défaut sont fournis pour accorder l'autorisation de création sur la sous-ressource de la stratégie de construction.

Expand
Tableau 2.3. Stratégie de construction Sous-ressources et rôles
StratégieSous-ressourceRôle

Docker

builds/docker

system:build-strategy-docker

De la source à l'image

builds/source

system:build-strategy-source

Sur mesure

constructions/personnalisées

système:construire-stratégie-personnalisée

JenkinsPipeline

builds/jenkinspipeline

système:construire-stratégie-jenkinspipeline

Pour empêcher l'accès à une stratégie de construction particulière au niveau mondial, connectez-vous en tant qu'utilisateur disposant de privilèges d'administrateur de cluster, supprimez le rôle correspondant du groupe system:authenticated et appliquez l'annotation rbac.authorization.kubernetes.io/autoupdate: "false" pour les protéger contre les modifications entre les redémarrages de l'API. L'exemple suivant montre la désactivation de la stratégie de construction Docker.

Procédure

  1. Appliquez l'annotation rbac.authorization.kubernetes.io/autoupdate:

    $ oc edit clusterrolebinding system:build-strategy-docker-binding
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    apiVersion: rbac.authorization.k8s.io/v1
    kind: ClusterRoleBinding
    metadata:
      annotations:
        rbac.authorization.kubernetes.io/autoupdate: "false" 
    1
    
      creationTimestamp: 2018-08-10T01:24:14Z
      name: system:build-strategy-docker-binding
      resourceVersion: "225"
      selfLink: /apis/rbac.authorization.k8s.io/v1/clusterrolebindings/system%3Abuild-strategy-docker-binding
      uid: 17b1f3d4-9c3c-11e8-be62-0800277d20bf
    roleRef:
      apiGroup: rbac.authorization.k8s.io
      kind: ClusterRole
      name: system:build-strategy-docker
    subjects:
    - apiGroup: rbac.authorization.k8s.io
      kind: Group
      name: system:authenticated
    Copy to Clipboard Toggle word wrap

    1
    Changez la valeur de l'annotation rbac.authorization.kubernetes.io/autoupdate en "false".
  2. Supprimer le rôle :

    $ oc adm policy remove-cluster-role-from-group system:build-strategy-docker system:authenticated
    Copy to Clipboard Toggle word wrap
  3. Assurez-vous que les sous-ressources de la stratégie de construction sont également supprimées de ces rôles :

    $ oc edit clusterrole admin
    Copy to Clipboard Toggle word wrap
    $ oc edit clusterrole edit
    Copy to Clipboard Toggle word wrap
  4. Pour chaque rôle, indiquez les sous-ressources qui correspondent à la ressource de la stratégie à désactiver.

    1. Désactiver la stratégie de construction de docker pour admin:

      kind: ClusterRole
      metadata:
        name: admin
      ...
      - apiGroups:
        - ""
        - build.openshift.io
        resources:
        - buildconfigs
        - buildconfigs/webhooks
        - builds/custom 
      1
      
        - builds/source
        verbs:
        - create
        - delete
        - deletecollection
        - get
        - list
        - patch
        - update
        - watch
      ...
      Copy to Clipboard Toggle word wrap
      1
      Ajoutez builds/custom et builds/source pour désactiver globalement les constructions de dockers pour les utilisateurs ayant le rôle admin.

Vous pouvez autoriser un ensemble d'utilisateurs spécifiques à créer des builds avec une stratégie particulière.

Conditions préalables

  • Désactiver l'accès global à la stratégie de construction.

Procédure

  • Attribuez le rôle correspondant à la stratégie de construction à un utilisateur spécifique. Par exemple, pour ajouter le rôle de cluster system:build-strategy-docker à l'utilisateur devuser:

    $ oc adm policy add-cluster-role-to-user system:build-strategy-docker devuser
    Copy to Clipboard Toggle word wrap
    Avertissement

    Accorder à un utilisateur l'accès au niveau du cluster à la sous-ressource builds/docker signifie que l'utilisateur peut créer des builds avec la stratégie docker dans n'importe quel projet dans lequel il peut créer des builds.

De la même manière que vous attribuez le rôle de stratégie de construction à un utilisateur de manière globale, vous pouvez autoriser un ensemble d'utilisateurs spécifiques au sein d'un projet à créer des constructions à l'aide d'une stratégie particulière.

Conditions préalables

  • Désactiver l'accès global à la stratégie de construction.

Procédure

  • Attribuer le rôle correspondant à la stratégie de construction à un utilisateur spécifique au sein d'un projet. Par exemple, pour ajouter le rôle system:build-strategy-docker dans le projet devproject à l'utilisateur devuser:

    $ oc adm policy add-role-to-user system:build-strategy-docker devuser -n devproject
    Copy to Clipboard Toggle word wrap
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