Red Hat Summit Red Hat SummitSupportConsoleDéveloppeursCommencer un essaiContact

3.18. Construction non privilégiée d'images de conteneurs à l'aide de Buildah

L'exécution d'OpenShift Pipelines en tant qu'utilisateur root sur un conteneur peut exposer les processus du conteneur et l'hôte à d'autres ressources potentiellement malveillantes. Vous pouvez réduire ce type d'exposition en exécutant la charge de travail en tant qu'utilisateur non root spécifique dans le conteneur. Pour sécuriser les builds non privilégiés des images de conteneurs en utilisant Buildah, vous pouvez effectuer les étapes suivantes :

  • Définir le compte de service personnalisé (SA) et la contrainte de contexte de sécurité (SCC).
  • Configurez Buildah pour qu'il utilise l'utilisateur build avec l'identifiant 1000.
  • Lancez une exécution de tâche avec une carte de configuration personnalisée ou intégrez-la à une exécution de pipeline.

La SA par défaut pipeline permet d'utiliser un identifiant d'utilisateur en dehors de la plage de l'espace de noms. Pour réduire la dépendance à l'égard de la SA par défaut, vous pouvez définir une SA et un SCC personnalisés avec le rôle de cluster et les liaisons de rôle nécessaires pour l'utilisateur build avec l'identifiant 1000.

Procédure

  • Créez un SA et un SCC personnalisés avec le rôle de cluster et les liaisons de rôle nécessaires.

    Exemple : SA et SCC personnalisés pour l'identifiant utilisé 1000

    apiVersion: v1
kind: ServiceAccount
metadata:
  name: pipelines-sa-userid-1000
    1 
    
---
kind: SecurityContextConstraints
metadata:
  annotations:
  name: pipelines-scc-userid-1000
    2 
    
allowHostDirVolumePlugin: false
allowHostIPC: false
allowHostNetwork: false
allowHostPID: false
allowHostPorts: false
allowPrivilegeEscalation: false
allowPrivilegedContainer: false
allowedCapabilities: null
apiVersion: security.openshift.io/v1
defaultAddCapabilities: null
fsGroup:
  type: MustRunAs
groups:
- system:cluster-admins
priority: 10
readOnlyRootFilesystem: false
requiredDropCapabilities:
- MKNOD
runAsUser:
    3 
    
  type: MustRunAs
  uid: 1000
seLinuxContext:
  type: MustRunAs
supplementalGroups:
  type: RunAsAny
users: []
volumes:
- configMap
- downwardAPI
- emptyDir
- persistentVolumeClaim
- projected
- secret
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: pipelines-scc-userid-1000-clusterrole
    4 
    
rules:
- apiGroups:
  - security.openshift.io
  resourceNames:
  - pipelines-scc-userid-1000
  resources:
  - securitycontextconstraints
  verbs:
  - use
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: pipelines-scc-userid-1000-rolebinding
    5 
    
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: pipelines-scc-userid-1000-clusterrole
subjects:
- kind: ServiceAccount
  name: pipelines-sa-userid-1000
    Copy to Clipboard Toggle word wrap

1
Définir une SA personnalisée.
2
Définir un SCC personnalisé créé sur la base de privilèges restreints, avec le champ runAsUser modifié.
3
Restreindre tout pod rattaché au SCC personnalisé par l'intermédiaire de la SA personnalisée à s'exécuter sous l'identité de l'utilisateur 1000.
4
Définir un rôle de cluster qui utilise le SCC personnalisé.
5
Lier le rôle de cluster qui utilise le SCC personnalisé à la SA personnalisée.

Vous pouvez définir une tâche Buildah pour utiliser l'utilisateur build avec l'identifiant 1000.

Procédure

  1. Créez une copie de la tâche de cluster buildah en tant que tâche ordinaire. 

    $ tkn task create --from=buildah
    Copy to Clipboard Toggle word wrap

  2. Modifiez la tâche buildah copiée. 

    $ oc edit task buildah
    Copy to Clipboard Toggle word wrap

    Exemple : Tâche Buildah modifiée avec l'utilisateur build 

    apiVersion: tekton.dev/v1beta1
kind: Task
metadata:
  name: buildah-as-user
spec:
  description: >-
    Buildah task builds source into a container image and
    then pushes it to a container registry.
    Buildah Task builds source into a container image using Project Atomic's
    Buildah build tool.It uses Buildah's support for building from Dockerfiles,
    using its buildah bud command.This command executes the directives in the
    Dockerfile to assemble a container image, then pushes that image to a
    container registry.
  params:
  - name: IMAGE
    description: Reference of the image buildah will produce.
  - name: BUILDER_IMAGE
    description: The location of the buildah builder image.
    default: registry.redhat.io/rhel8/buildah@sha256:99cae35f40c7ec050fed3765b2b27e0b8bbea2aa2da7c16408e2ca13c60ff8ee
  - name: STORAGE_DRIVER
    description: Set buildah storage driver
    default: vfs
  - name: DOCKERFILE
    description: Path to the Dockerfile to build.
    default: ./Dockerfile
  - name: CONTEXT
    description: Path to the directory to use as context.
    default: .
  - name: TLSVERIFY
    description: Verify the TLS on the registry endpoint (for push/pull to a non-TLS registry)
    default: "true"
  - name: FORMAT
    description: The format of the built container, oci or docker
    default: "oci"
  - name: BUILD_EXTRA_ARGS
    description: Extra parameters passed for the build command when building images.
    default: ""
  - description: Extra parameters passed for the push command when pushing images.
    name: PUSH_EXTRA_ARGS
    type: string
    default: ""
  - description: Skip pushing the built image
    name: SKIP_PUSH
    type: string
    default: "false"
  results:
  - description: Digest of the image just built.
    name: IMAGE_DIGEST
    type: string
  workspaces:
  - name: source
  steps:
  - name: build
    securityContext:
      runAsUser: 1000
    1 
    
    image: $(params.BUILDER_IMAGE)
    workingDir: $(workspaces.source.path)
    script: |
      echo "Running as USER ID `id`"
    2 
    
      buildah --storage-driver=$(params.STORAGE_DRIVER) bud \
        $(params.BUILD_EXTRA_ARGS) --format=$(params.FORMAT) \
        --tls-verify=$(params.TLSVERIFY) --no-cache \
        -f $(params.DOCKERFILE) -t $(params.IMAGE) $(params.CONTEXT)
      [[ "$(params.SKIP_PUSH)" == "true" ]] && echo "Push skipped" && exit 0
      buildah --storage-driver=$(params.STORAGE_DRIVER) push \
        $(params.PUSH_EXTRA_ARGS) --tls-verify=$(params.TLSVERIFY) \
        --digestfile $(workspaces.source.path)/image-digest $(params.IMAGE) \
        docker://$(params.IMAGE)
      cat $(workspaces.source.path)/image-digest | tee /tekton/results/IMAGE_DIGEST
    volumeMounts:
    - name: varlibcontainers
      mountPath: /home/build/.local/share/containers
    volumeMounts:
    - name: varlibcontainers
      mountPath: /home/build/.local/share/containers
  volumes:
  - name: varlibcontainers
    emptyDir: {}
    Copy to Clipboard Toggle word wrap

    1
    Exécutez le conteneur explicitement en tant qu'utilisateur 1000, ce qui correspond à l'utilisateur build dans l'image Buildah.
    2
    Affichez l'identifiant de l'utilisateur pour confirmer que le processus s'exécute en tant qu'identifiant de l'utilisateur 1000.

Après avoir défini la tâche de cluster Buildah personnalisée, vous pouvez créer un objet TaskRun qui construit une image en tant qu'utilisateur build avec l'identifiant d'utilisateur 1000. En outre, vous pouvez intégrer l'objet TaskRun dans un objet PipelineRun.

Procédure

  1. Créez un objet TaskRun avec des objets personnalisés ConfigMap et Dockerfile.

    Exemple : Une tâche qui exécute Buildah en tant qu'identifiant de l'utilisateur 1000

    apiVersion: v1
data:
  Dockerfile: |
    ARG BASE_IMG=registry.access.redhat.com/ubi8/ubi
    FROM $BASE_IMG AS buildah-runner
    RUN dnf -y update && \
        dnf -y install git && \
        dnf clean all
    CMD git
kind: ConfigMap
metadata:
  name: dockerfile
    1 
    
---
apiVersion: tekton.dev/v1beta1
kind: TaskRun
metadata:
  name: buildah-as-user-1000
spec:
  serviceAccountName: pipelines-sa-userid-1000
  params:
  - name: IMAGE
    value: image-registry.openshift-image-registry.svc:5000/test/buildahuser
  taskRef:
    kind: Task
    name: buildah-as-user
  workspaces:
  - configMap:
      name: dockerfile
    2 
    
    name: source
    Copy to Clipboard Toggle word wrap

    1
    Utiliser une carte de configuration parce que l'accent est mis sur l'exécution de la tâche, sans aucune tâche préalable qui récupère des sources avec un Dockerfile.
    2
    Monter une carte de configuration comme espace de travail source pour la tâche buildah-as-user.

  2. (Facultatif) Créer un pipeline et un cycle de pipeline correspondant.

    Exemple : Une canalisation et un tronçon de canalisation correspondant

    apiVersion: tekton.dev/v1beta1
kind: Pipeline
metadata:
  name: pipeline-buildah-as-user-1000
spec:
  params:
  - name: IMAGE
  - name: URL
  workspaces:
  - name: shared-workspace
  - name: sslcertdir
    optional: true
  tasks:
  - name: fetch-repository
    1 
    
    taskRef:
      name: git-clone
      kind: ClusterTask
    workspaces:
    - name: output
      workspace: shared-workspace
    params:
    - name: url
      value: $(params.URL)
    - name: subdirectory
      value: ""
    - name: deleteExisting
      value: "true"
  - name: buildah
    taskRef:
      name: buildah-as-user
    2 
    
    runAfter:
    - fetch-repository
    workspaces:
    - name: source
      workspace: shared-workspace
    - name: sslcertdir
      workspace: sslcertdir
    params:
    - name: IMAGE
      value: $(params.IMAGE)
---
apiVersion: tekton.dev/v1beta1
kind: PipelineRun
metadata:
  name: pipelinerun-buildah-as-user-1000
spec:
  serviceAccountName: pipelines-sa-userid-1000
  params:
  - name: URL
    value: https://github.com/openshift/pipelines-vote-api
  - name: IMAGE
    value: image-registry.openshift-image-registry.svc:5000/test/buildahuser
  taskRef:
    kind: Pipeline
    name: pipeline-buildah-as-user-1000
  workspaces:
  - name: shared-workspace
    3 
    
    volumeClaimTemplate:
      spec:
        accessModes:
          - ReadWriteOnce
        resources:
          requests:
            storage: 100Mi
    Copy to Clipboard Toggle word wrap

    1
    Utilisez la tâche de cluster git-clone pour récupérer la source contenant un fichier Docker et le construire à l'aide de la tâche Buildah modifiée.
    2
    Se référer à la tâche Buildah modifiée.
    3
    Partager les données entre la tâche git-clone et la tâche Buildah modifiée à l'aide d'une revendication de volume persistant (PVC) créée automatiquement par le contrôleur.
  3. Lancer l'exécution de la tâche ou du pipeline.

3.18.4. Limites des versions non privilégiées
Copier lien

Le processus de construction sans privilège fonctionne avec la plupart des objets Dockerfile. Cependant, certaines limitations connues peuvent entraîner l'échec de la construction :

  • L'utilisation de l'option --mount=type=cache peut échouer en raison de problèmes de permissions non nécessaires. Pour plus d'informations, voir cet article.
  • L'utilisation de l'option --mount=type=secret échoue car le montage des ressources nécessite des capacités supplémentaires qui ne sont pas fournies par le SCC personnalisé.

Ressources complé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