OpenShift Pipelines の保護

手順

1. Red Hat OpenShift Pipelines クラスターの TektonChain CR を作成します。

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

   Copy to Clipboard Toggle word wrap

2. TektonChain CR を適用します。

   $ oc apply -f TektonChain.yaml 

   1

   Copy to Clipboard Toggle word wrap

   1

   TektonChain CR のファイル名に置き換えます。

3. インストールのステータスを確認します。

   $ oc get tektonchains.operator.tekton.dev

   Copy to Clipboard Toggle word wrap

手順

1. Kubernetes サービスアカウントの namespace と名前を設定します。

   $ export NAMESPACE=<namespace> 

   1

   
   $ export SERVICE_ACCOUNT_NAME=<service_account> 

   2

   Copy to Clipboard Toggle word wrap

   1

   サービスアカウントに関連付けられた namespace。

   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 がすべてのタスク実行に割り当てるデフォルトの pipeline サービスアカウントにパッチを適用すると、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 は、結果の秘密鍵を signing-secrets Kubernetes シークレットの一部として openshift-pipelinesnamespace に保存し、公開鍵を cosign.pub ローカルファイルに書き込みます。

2. イメージレジストリーの認証を設定します。

   1. 署名を OCI レジストリーにプッシュするように Tekton Chains コントローラーを設定するには、タスク実行のサービスアカウントに関連付けられた認証情報を使用します。詳細については、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 設定シークレットの名前に置き換えます。

      2

      docker config.json ファイルへのパスに置き換えます。

3. Tekton Chains を設定するには、chains-config オブジェクトで artifacts.taskrun.format、artifacts.taskrun.storage、transparency.enabled パラメーターを設定します。

   $ 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 Chains が証明書を生成して署名するまで 1 分ほど待ち、タスク実行時に chains.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)。

      3

      2 番目に一致する UUID。

      検索結果には、一致するエントリーの UUID が表示されます。それらの UUID の 1 つが証明書を保持します。

   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

   特権付きタスクにカスタムサービスアカウントを使用する必要がある場合は、以下のコマンドを実行して privileged SCC をカスタムサービスアカウントに関連付けることができます。

   例: fsgroup-runasany サービスアカウントを使用した privileged SCC の関連付け

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

   Copy to Clipboard Toggle word wrap

5. パイプライン実行およびタスク実行でカスタムサービスアカウントを使用します。

   例: fsgroup-runasany カスタムサービスアカウントを使用した Pipeline 実行 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 リポジトリーで利用可能な YAML ファイルから TriggerTemplate リソースを作成します。

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

   Copy to Clipboard Toggle word wrap

3. Trigger リソースを pipelines-tutorial リポジトリーから直接作成します。

   $ 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 ファイルで、ターゲット Git リポジトリーにアクセスするためのユーザー名とパスワードまたは GitHub パーソナルアクセストークン を指定します。

   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 ポートを指定するには、annotation 値の最後に :<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 イメージの build ユーザーに対応し、明示的に 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 を使用してソースを取得するなどの事前タスクはなく、タスクの実行に焦点が置かれているため、config map を使用します。

   2

   作成したサービスアカウントの名前。

   3

   buildah-as-user タスクのソースワークスペースとして config map をマウントします。

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. タスクの実行またはパイプラインの実行を開始します。