OpenShift Pipelines 보안

프로세스

1. Red Hat OpenShift Pipelines 클러스터에 대한 Tekton Cryostat CR을 생성합니다.

   apiVersion: operator.tekton.dev/v1alpha1
   kind: TektonChain
   metadata:
     name: chain
   spec:
     targetNamespace: openshift-pipelines

   Copy to Clipboard Toggle word wrap

2. Tekton Cryostat CR을 적용합니다.

   $ oc apply -f TektonChain.yaml 

   1

   Copy to Clipboard Toggle word wrap

   1

   Tekton Cryostat CR의 파일 이름으로 대체합니다.

3. 설치 상태를 확인합니다.

   $ oc get tektonchains.operator.tekton.dev

   Copy to Clipboard Toggle word wrap

프로세스

1. Kubernetes 서비스 계정의 네임스페이스 및 이름을 설정합니다.

   $ export NAMESPACE=<namespace> 

   1

   
   $ export SERVICE_ACCOUNT_NAME=<service_account> 

   2

   Copy to Clipboard Toggle word wrap

   1

   서비스 계정과 연결된 네임스페이스입니다.

   2

   서비스 계정의 이름입니다.

2. Kubernetes 시크릿을 생성합니다.

   $ oc create secret registry-credentials \
     --from-file=.dockerconfigjson \ 

   1

   
     --type=kubernetes.io/dockerconfigjson \
     -n $NAMESPACE

   Copy to Clipboard Toggle word wrap

   1

   Docker 구성 파일의 경로로 바꿉니다. 기본 경로는 ~/.docker/config.json 입니다.

3. 서비스 계정에 시크릿에 대한 액세스 권한을 부여합니다.

   $ oc patch serviceaccount $SERVICE_ACCOUNT_NAME \
     -p "{\"imagePullSecrets\": [{\"name\": \"registry-credentials\"}]}" -n $NAMESPACE

   Copy to Clipboard Toggle word wrap

   Red Hat OpenShift Pipelines가 모든 작업 실행에 할당하는 기본 파이프라인 서비스 계정을 패치하면 Red Hat OpenShift Pipelines Operator가 서비스 계정을 재정의합니다. 모범 사례로 다음 단계를 수행할 수 있습니다.

   1. 사용자의 작업 실행에 할당할 별도의 서비스 계정을 생성합니다.

      $ oc create serviceaccount <service_account_name>

      Copy to Clipboard Toggle word wrap

   2. 작업 실행 템플릿에서 serviceaccountname 필드의 값을 설정하여 서비스 계정을 작업 실행에 연결합니다.

      apiVersion: tekton.dev/v1beta1
      kind: TaskRun
      metadata:
      name: build-push-task-run-2
      spec:
      serviceAccountName: build-bot 

      1

      
      taskRef:
        name: build-push
      ...

      Copy to Clipboard Toggle word wrap

      1

      새로 생성된 서비스 계정의 이름으로 바꿉니다.

프로세스

1. 암호화된 x509 키 쌍을 생성하여 Kubernetes 시크릿으로 저장합니다.

   $ cosign generate-key-pair k8s://openshift-pipelines/signing-secrets

   Copy to Clipboard Toggle word wrap

   메시지가 표시되면 암호를 입력합니다. cosign은 생성된 개인 키를 openshift-pipelines 네임스페이스에 signing-secrets Kubernetes 시크릿의 일부로 저장하고 공개 키를 cosign.pub 로컬 파일에 씁니다.

2. 이미지 레지스트리에 대한 인증을 구성합니다.

   1. OCI 레지스트리로 서명을 푸시하도록 Tekton 체인 컨트롤러를 구성하려면 작업 실행의 서비스 계정과 연결된 인증 정보를 사용합니다. 자세한 내용은 " OCI 레지스트리에 인증" 섹션을 참조하십시오.

   2. 이미지를 빌드하고 레지스트리로 내보내는 Kaniko 작업에 대한 인증을 구성하려면 필요한 인증 정보가 포함된 docker config.json 파일의 Kubernetes 시크릿을 생성합니다.

      $ oc create secret generic <docker_config_secret_name> \ 

      1

      
        --from-file <path_to_config.json> 

      2

      Copy to Clipboard Toggle word wrap

      1

      docker config secret 이름으로 대체합니다.

      2

      docker config.json 파일의 경로로 바꿉니다.

3. chain-config 개체에서 artifacts.taskrun.format,artifacts.taskrun.storage 및 transparency.enabled 매개변수를 설정하여 Tekton 체인을 구성합니다.

   $ oc patch configmap chains-config -n openshift-pipelines -p='{"data":{"artifacts.taskrun.format": "in-toto"}}'
   
   $ oc patch configmap chains-config -n openshift-pipelines -p='{"data":{"artifacts.taskrun.storage": "oci"}}'
   
   $ oc patch configmap chains-config -n openshift-pipelines -p='{"data":{"transparency.enabled": "true"}}'

   Copy to Clipboard Toggle word wrap

4. Kaniko 작업을 시작합니다.

   1. Kaniko 작업을 클러스터에 적용합니다.

      $ oc apply -f examples/kaniko/kaniko.yaml 

      1

      Copy to Clipboard Toggle word wrap

      1

      Kaniko 작업의 URI 또는 파일 경로로 바꿉니다.

   2. 적절한 환경 변수를 설정합니다.

      $ export REGISTRY=<url_of_registry> 

      1

      
      
      $ export DOCKERCONFIG_SECRET_NAME=<name_of_the_secret_in_docker_config_json> 

      2

      Copy to Clipboard Toggle word wrap

      1

      이미지를 내보낼 레지스트리의 URL을 바꿉니다.

      2

      docker config.json 파일의 보안 이름으로 바꿉니다.

   3. Kaniko 작업을 시작합니다.

      $ tkn task start --param IMAGE=$REGISTRY/kaniko-chains --use-param-defaults --workspace name=source,emptyDir="" --workspace name=dockerconfig,secret=$DOCKERCONFIG_SECRET_NAME kaniko-chains

      Copy to Clipboard Toggle word wrap

      모든 단계가 완료될 때까지 이 작업의 로그를 관찰합니다. 인증에 성공하면 최종 이미지가 $REGISTRY/kaniko-chains 로 푸시됩니다.

5. Tekton 체인에서 인증 정보를 생성하고 서명할 때까지 1분 정도 기다린 다음 작업 실행 시 chain.tekton.dev/signed=true 주석의 가용성을 확인합니다.

   $ oc get tr <task_run_name> \ 

   1

   
   -o json | jq -r .metadata.annotations
   
   {
     "chains.tekton.dev/signed": "true",
     ...
   }

   Copy to Clipboard Toggle word wrap

   1

   작업 실행 이름으로 대체합니다.

6. 이미지와 인증을 확인합니다.

   $ cosign verify --key cosign.pub $REGISTRY/kaniko-chains
   
   $ cosign verify-attestation --key cosign.pub $REGISTRY/kaniko-chains

   Copy to Clipboard Toggle word wrap

7. Rekor에서 이미지의 출처를 확인합니다.

   1. $REGISTRY/kaniko-chains 이미지의 다이제스트를 가져옵니다. 작업 실행을 검색하거나 이미지를 가져와 다이제스트를 추출할 수 있습니다.

   2. Rekor를 검색하여 이미지의 sha256 다이제스트와 일치하는 모든 항목을 찾습니다.

      $ rekor-cli search --sha <image_digest> 

      1

      
      
      <uuid_1> 

      2

      
      <uuid_2> 

      3

      
      ...

      Copy to Clipboard Toggle word wrap

      1

      이미지를 sha256 다이제스트로 대체합니다.

      2

      첫 번째 일치는 UUID(Universally unique identifier)입니다.

      3

      두 번째 일치하는 UUID입니다.

      검색 결과에는 일치하는 항목의 UUID가 표시됩니다. 해당 UUID 중 하나에 인증 정보가 있습니다.

   3. 테스트를 확인하십시오.

      $ rekor-cli get --uuid <uuid> --format json | jq -r .Attestation | base64 --decode | jq

      Copy to Clipboard Toggle word wrap

프로세스

1. fsGroup.type 매개변수를 RunAsAny 로 설정하여 사용자 지정 SCC를 정의합니다.

   예: 사용자 정의 SCC

   apiVersion: security.openshift.io/v1
   kind: SecurityContextConstraints
   metadata:
     annotations:
       kubernetes.io/description: my-scc is a close replica of anyuid scc. pipelines-scc has fsGroup - RunAsAny.
     name: my-scc
   allowHostDirVolumePlugin: false
   allowHostIPC: false
   allowHostNetwork: false
   allowHostPID: false
   allowHostPorts: false
   allowPrivilegeEscalation: true
   allowPrivilegedContainer: false
   allowedCapabilities: null
   defaultAddCapabilities: null
   fsGroup:
     type: RunAsAny
   groups:
   - system:cluster-admins
   priority: 10
   readOnlyRootFilesystem: false
   requiredDropCapabilities:
   - MKNOD
   runAsUser:
     type: RunAsAny
   seLinuxContext:
     type: MustRunAs
   supplementalGroups:
     type: RunAsAny
   volumes:
   - configMap
   - downwardAPI
   - emptyDir
   - persistentVolumeClaim
   - projected
   - secret

   Copy to Clipboard Toggle word wrap

2. 사용자 지정 SCC를 생성합니다.

   예: my-scc SCC 생성

   $ oc create -f my-scc.yaml

   Copy to Clipboard Toggle word wrap

3. 사용자 정의 서비스 계정을 생성합니다.

   예: fsgroup-runasany 서비스 계정 생성

   $ oc create serviceaccount fsgroup-runasany

   Copy to Clipboard Toggle word wrap

4. 사용자 지정 SCC를 사용자 지정 서비스 계정과 연결합니다.

   예: my-scc SCC를 fsgroup-runasany 서비스 계정과 연결

   $ oc adm policy add-scc-to-user my-scc -z fsgroup-runasany

   Copy to Clipboard Toggle word wrap

   권한 있는 작업에 사용자 정의 서비스 계정을 사용하려면 다음 명령을 실행하여 권한 있는 SCC를 사용자 정의 서비스 계정과 연결할 수 있습니다.

   예: 권한 있는 SCC를 fsgroup-runasany 서비스 계정에 연결

   $ oc adm policy add-scc-to-user privileged -z fsgroup-runasany

   Copy to Clipboard Toggle word wrap

5. 파이프라인 실행 및 작업 실행에서 사용자 정의 서비스 계정을 사용합니다.

   예: 파이프라인은 fsgroup-runasany 사용자 지정 서비스 계정으로 YAML을 실행합니다.

   apiVersion: tekton.dev/v1beta1
   kind: PipelineRun
   metadata:
     name: <pipeline-run-name>
   spec:
     pipelineRef:
       name: <pipeline-cluster-task-name>
     serviceAccountName: 'fsgroup-runasany'

   Copy to Clipboard Toggle word wrap

   예: 작업에서는 fsgroup-runasany 사용자 지정 서비스 계정으로 YAML을 실행합니다.

   apiVersion: tekton.dev/v1beta1
   kind: TaskRun
   metadata:
     name: <task-run-name>
   spec:
     taskRef:
       name: <cluster-task-name>
     serviceAccountName: 'fsgroup-runasany'

   Copy to Clipboard Toggle word wrap

프로세스

1. pipelines-tutorial 리포지토리에서 사용 가능한 YAML 파일에서 TriggerBinding 리소스를 생성합니다.

   $ oc create -f https://raw.githubusercontent.com/openshift/pipelines-tutorial/master/03_triggers/01_binding.yaml

   Copy to Clipboard Toggle word wrap

2. pipelines-tutorial 리포지토리에서 직접 TriggerTemplate 리소스를 생성합니다.

   $ oc create -f https://raw.githubusercontent.com/openshift/pipelines-tutorial/master/03_triggers/02_template.yaml

   Copy to Clipboard Toggle word wrap

3. pipelines-tutorial 리포지토리에서 직접 Trigger 리소스를 생성합니다.

   $ oc create -f https://raw.githubusercontent.com/openshift/pipelines-tutorial/master/03_triggers/03_trigger.yaml

   Copy to Clipboard Toggle word wrap

4. 보안 HTTPS 연결을 사용하여 EventListener 리소스를 생성합니다.

   1. Eventlistener 리소스에 대한 보안 HTTPS 연결을 활성화하려면 레이블을 추가합니다.

      $ oc label namespace <ns-name> operator.tekton.dev/enable-annotation=enabled

      Copy to Clipboard Toggle word wrap

   2. pipelines-tutorial 리포지토리에서 사용 가능한 YAML 파일에서 EventListener 리소스를 생성합니다.

      $ oc create -f https://raw.githubusercontent.com/openshift/pipelines-tutorial/master/03_triggers/04_event_listener.yaml

      Copy to Clipboard Toggle word wrap

   3. 재암호화 TLS 종료로 경로를 생성합니다.

      $ oc create route reencrypt --service=<svc-name> --cert=tls.crt --key=tls.key --ca-cert=ca.crt --hostname=<hostname>

      Copy to Clipboard Toggle word wrap

프로세스

1. secret.yaml 파일에서 사용자 이름과 암호 또는 GitHub 개인 액세스 토큰 을 지정하여 대상 Git 리포지토리에 액세스합니다.

   apiVersion: v1
   kind: Secret
   metadata:
     name: basic-user-pass 

   1

   
     annotations:
       tekton.dev/git-0: https://github.com
   type: kubernetes.io/basic-auth
   stringData:
     username: <username> 

   2

   
     password: <password> 

   3

   Copy to Clipboard Toggle word wrap

   1

   보안의 이름입니다. 예에서는 basic-user-pass 입니다.

   2

   Git 리포지토리의 사용자 이름입니다.

   3

   Git 리포지토리의 암호입니다.

2. serviceaccount.yaml 파일에서 보안을 적절한 서비스 계정과 연결합니다.

   apiVersion: v1
   kind: ServiceAccount
   metadata:
     name: build-bot 

   1

   
   secrets:
     - name: basic-user-pass 

   2

   Copy to Clipboard Toggle word wrap

   1

   서비스 계정의 이름입니다. 이 예에서는 build-bot 입니다.

   2

   보안의 이름입니다. 예에서는 basic-user-pass 입니다.

3. run.yaml 파일에서 서비스 계정을 작업 실행 또는 파이프라인 실행과 연결합니다.

   • 서비스 계정을 작업 실행과 연결합니다.

     apiVersion: tekton.dev/v1beta1
     kind: TaskRun
     metadata:
       name: build-push-task-run-2 

     1

     
     spec:
       serviceAccountName: build-bot 

     2

     
       taskRef:
         name: build-push 

     3

     Copy to Clipboard Toggle word wrap

     1

     작업 실행의 이름입니다. 예에서는 build-push-task-run-2 입니다.

     2

     서비스 계정의 이름입니다. 이 예에서는 build-bot 입니다.

     3

     작업 이름입니다. 예에서는 build-push.

   • 서비스 계정을 PipelineRun 리소스와 연결합니다.

     apiVersion: tekton.dev/v1beta1
     kind: PipelineRun
     metadata:
       name: demo-pipeline 

     1

     
       namespace: default
     spec:
       serviceAccountName: build-bot 

     2

     
       pipelineRef:
         name: demo-pipeline 

     3

     Copy to Clipboard Toggle word wrap

     1

     파이프라인 실행의 이름입니다. 예에서는 demo-pipeline 입니다.

     2

     서비스 계정의 이름입니다. 이 예에서는 build-bot 입니다.

     3

     파이프라인의 이름입니다. 예에서는 demo-pipeline 입니다.

4. 변경 사항을 적용합니다.

   $ oc apply --filename secret.yaml,serviceaccount.yaml,run.yaml

   Copy to Clipboard Toggle word wrap

프로세스

1. SSH 개인 키를 생성하거나 일반적으로 ~/.ssh/id_rsa 파일에서 사용할 수 있는 기존 개인 키를 복사합니다.

2. secret.yaml 파일에서 ssh-privatekey 의 값을 SSH 개인 키 파일의 콘텐츠로 설정하고 known_hosts 값을 알려진 호스트 파일의 콘텐츠로 설정합니다.

   apiVersion: v1
   kind: Secret
   metadata:
     name: ssh-key 

   1

   
     annotations:
       tekton.dev/git-0: github.com
   type: kubernetes.io/ssh-auth
   stringData:
     ssh-privatekey: 

   2

   
     known_hosts: 

   3

   Copy to Clipboard Toggle word wrap

   1

   SSH 개인 키가 포함된 시크릿의 이름입니다. 예에서는 ssh-key.

   2

   SSH 개인 키 파일의 내용입니다.

   3

   알려진 호스트 파일의 내용입니다.

   Important

   개인 키를 생략하면 OpenShift Pipelines에서 서버의 공개 키를 수락합니다.

3. 선택 사항: 사용자 정의 SSH 포트를 지정하려면 주석 값 끝에 :<port number >를 추가합니다. 예: tekton.dev/git-0: github.com:2222.

4. serviceaccount.yaml 파일에서 ssh-key 시크릿을 build-bot 서비스 계정과 연결합니다.

   apiVersion: v1
   kind: ServiceAccount
   metadata:
     name: build-bot 

   1

   
   secrets:
     - name: ssh-key 

   2

   Copy to Clipboard Toggle word wrap

   1

   서비스 계정의 이름입니다. 이 예에서는 build-bot 입니다.

   2

   SSH 개인 키가 포함된 시크릿의 이름입니다. 예에서는 ssh-key.

5. run.yaml 파일에서 서비스 계정을 작업 실행 또는 파이프라인 실행과 연결합니다.

   • 서비스 계정을 작업 실행과 연결합니다.

     apiVersion: tekton.dev/v1beta1
     kind: TaskRun
     metadata:
       name: build-push-task-run-2 

     1

     
     spec:
       serviceAccountName: build-bot 

     2

     
       taskRef:
         name: build-push 

     3

     Copy to Clipboard Toggle word wrap

     1

     작업 실행의 이름입니다. 예에서는 build-push-task-run-2 입니다.

     2

     서비스 계정의 이름입니다. 이 예에서는 build-bot 입니다.

     3

     작업 이름입니다. 예에서는 build-push.

   • 서비스 계정을 파이프라인 실행과 연결합니다.

     apiVersion: tekton.dev/v1beta1
     kind: PipelineRun
     metadata:
       name: demo-pipeline 

     1

     
       namespace: default
     spec:
       serviceAccountName: build-bot 

     2

     
       pipelineRef:
         name: demo-pipeline 

     3

     Copy to Clipboard Toggle word wrap

     1

     파이프라인 실행의 이름입니다. 예에서는 demo-pipeline 입니다.

     2

     서비스 계정의 이름입니다. 이 예에서는 build-bot 입니다.

     3

     파이프라인의 이름입니다. 예에서는 demo-pipeline 입니다.

6. 변경 사항을 적용합니다.

   $ oc apply --filename secret.yaml,serviceaccount.yaml,run.yaml

   Copy to Clipboard Toggle word wrap

프로세스

1. buildah 클러스터 작업의 사본을 일반 작업으로 생성합니다.

   $ oc get clustertask buildah -o yaml | yq '. |= (del .metadata |= with_entries(select(.key == "name" )))' | yq '.kind="Task"' | yq '.metadata.name="buildah-as-user"' | oc create -f -

   Copy to Clipboard Toggle word wrap

2. 복사한 buildah 작업을 편집합니다.

   $ oc edit task buildah-as-user

   Copy to Clipboard Toggle word wrap

   예: build 사용자를 사용하여 Buildah 작업

   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 

   3

   
     volumes:
     - name: varlibcontainers
       emptyDir: {}

   Copy to Clipboard Toggle word wrap

   1

   Buildah 이미지의 빌드 사용자에게 해당하는 사용자 ID 1000 으로 명시적으로 컨테이너를 실행합니다.

   2

   사용자 ID를 표시하여 프로세스가 사용자 ID 1000 으로 실행되고 있는지 확인합니다.

   3

   필요에 따라 볼륨 마운트의 경로를 변경할 수 있습니다.

프로세스

1. 사용자 정의 ConfigMap 및 Dockerfile 오브젝트를 사용하여 TaskRun 오브젝트를 생성합니다.

   예: Buildah를 사용자 ID 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 

   2

   
     params:
     - name: IMAGE
       value: image-registry.openshift-image-registry.svc:5000/test/buildahuser
     taskRef:
       kind: Task
       name: buildah-as-user
     workspaces:
     - configMap:
         name: dockerfile 

   3

   
       name: source

   Copy to Clipboard Toggle word wrap

   1

   Dockerfile이 있는 일부 소스를 가져오는 이전 작업 없이 작업에 중점을 두고 있으므로 구성 맵을 사용합니다.

   2

   생성한 서비스 계정의 이름입니다.

   3

   buildah-as-user 작업의 소스 작업 공간으로 구성 맵을 마운트합니다.

2. (선택 사항) 파이프라인 및 해당 파이프라인 실행을 생성합니다.

   예: 파이프라인 및 해당 파이프라인 실행

   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:
     taskRunSpecs:
       - pipelineTaskName: buildah
         taskServiceAccountName: pipelines-sa-userid-1000 

   3

   
     params:
     - name: URL
       value: https://github.com/openshift/pipelines-vote-api
     - name: IMAGE
       value: image-registry.openshift-image-registry.svc:5000/test/buildahuser
     pipelineRef:
       name: pipeline-buildah-as-user-1000
     workspaces:
     - name: shared-workspace 

   4

   
       volumeClaimTemplate:
         spec:
           accessModes:
             - ReadWriteOnce
           resources:
             requests:
               storage: 100Mi

   Copy to Clipboard Toggle word wrap

   1

   git-clone 클러스터 작업을 사용하여 Dockerfile이 포함된 소스를 가져와서 수정된 Buildah 작업을 사용하여 빌드합니다.

   2

   수정된 Buildah 작업을 참조합니다.

   3

   Buildah 작업에 대해 생성한 서비스 계정을 사용합니다.

   4

   컨트롤러에서 자동으로 생성한 PVC(영구 볼륨 클레임)를 사용하여 git-clone 작업과 수정된 Buildah 작업 간에 데이터를 공유합니다.

3. 작업 실행 또는 파이프라인 실행을 시작합니다.