OpenShift Pipelines の保護

手順

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

   $ export NAMESPACE=<namespace> 

   1

   
   $ export SERVICE_ACCOUNT_NAME=<service_account> 

   2

   1

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

   2

   サービスアカウントの名前

2. Kubernetes シークレットを作成します。

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

   1

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

   1

   Docker 設定ファイルへのパスに置き換えます。デフォルトのパスは ~/.docker/config.json です。

3. サービスアカウントにシークレットへのアクセス権限を付与します。

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

   Red Hat OpenShift Pipelines がすべてのタスク実行に割り当てるデフォルトの pipeline サービスアカウントにパッチを適用すると、Red Hat OpenShift Pipelines Operator はサービスアカウントをオーバーライドします。ベストプラクティスとして、次の手順を実行できます。

   1. ユーザーのタスク実行に割り当てる別のサービスアカウントを作成します。

      $ oc create serviceaccount <service_account_name>

   2. タスク実行テンプレートの serviceaccountname フィールドの値を設定して、サービスアカウントをタスク実行に関連付けます。

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

      1

      
        taskRef:
          name: build-push
      ...

      1

      新しく作成したサービスアカウントの名前に置き換えます。

手順

1. 暗号化された x509 キーペアを作成し、Kubernetes シークレットとして保存します。鍵ペアの作成とシークレットとしての保存の詳細については、「Tekton Chains でのシークレットの署名」を参照してください。

2. Tekton Chains 設定で、OCI ストレージを無効にし、タスク実行ストレージとフォーマットを tekton に設定します。TektonConfig カスタムリソースで次の値を設定します。

   apiVersion: operator.tekton.dev/v1alpha1
   kind: TektonConfig
   metadata:
     name: config
   spec:
   # ...
       chain:
         artifacts.oci.storage: ""
         artifacts.taskrun.format: tekton
         artifacts.taskrun.storage: tekton
   # ...

   TektonConfig カスタムリソースを使用した Tekton チェーンの設定の詳細は、「Tekton チェーンの設定」を参照してください。

3. Tekton Chains コントローラーを再起動して、変更した設定が確実に適用されるようにするには、次のコマンドを入力します。

   $ oc delete po -n openshift-pipelines -l app=tekton-chains-controller

4. 次のコマンドを入力してタスク実行を作成します。

   $ oc create -f https://raw.githubusercontent.com/tektoncd/chains/main/examples/taskruns/task-output-image.yaml 

   1

   1

   サンプル URI を、タスクの実行を指す URI またはファイルパスに置き換えます。

   出力例

   taskrun.tekton.dev/build-push-run-output-image-qbjvh created

5. 次のコマンドを入力して、ステップのステータスを確認します。プロセスが完了するまで待ちます。

   $ tkn tr describe --last

   出力例

   [...truncated output...]
   NAME                            STATUS
   ∙ create-dir-builtimage-9467f   Completed
   ∙ git-source-sourcerepo-p2sk8   Completed
   ∙ build-and-push                Completed
   ∙ echo                          Completed
   ∙ image-digest-exporter-xlkn7   Completed

6. Base64 でエンコードされたアノテーションとして保存されたオブジェクトから署名を取得するには、次のコマンドを入力します。

   $ tkn tr describe --last -o jsonpath="{.metadata.annotations.chains\.tekton\.dev/signature-taskrun-$TASKRUN_UID}" | base64 -d > sig

   $ export TASKRUN_UID=$(tkn tr describe --last -o  jsonpath='{.metadata.uid}')

7. 作成した公開鍵を使用して署名を検証するには、次のコマンドを入力します。

手順

1. 暗号化された x509 鍵ペアを作成し、Kubernetes シークレットとして保存します。

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

   プロンプトが表示されたらパスワードを入力します。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

      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"}}'

4. Kaniko タスクを開始します。

   1. Kaniko タスクをクラスターに適用します。

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

      1

      1

      Kaniko タスクへの URI またはファイルパスに置き換えます。

   2. 適切な環境変数を設定します。

      $ export REGISTRY=<url_of_registry> 

      1

      
      
      $ export DOCKERCONFIG_SECRET_NAME=<name_of_the_secret_in_docker_config_json> 

      2

      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

      すべての手順が完了するまで、このタスクのログを確認してください。認証が成功すると、最終的なイメージが $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",
     ...
   }

   1

   タスク実行の名前に置き換えます。

6. イメージとアテステーションを確認します。

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

7. Rekor でイメージの証明書を見つけます。

   1. $ REGISTRY/kaniko-chains イメージのダイジェストを取得します。タスクの実行中に検索するか、イメージをプルしてダイジェストをデプロイメントできます。

   2. Rekor を検索して、イメージの sha256 ダイジェストに一致するすべてのエントリーを見つけます。

      $ rekor-cli search --sha <image_digest> 

      1

      
      
      <uuid_1> 

      2

      
      <uuid_2> 

      3

      
      ...

      1

      イメージの sha256 ダイジェストに置き換えます。

      2

      最初に一致するユニバーサル一意識別子 (UUID)。

      3

      2 番目に一致する UUID。

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

   3. アテステーションを確認してください。

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

手順

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

2. カスタム SCC を作成します。

   例: my-scc SCC の作成

   $ oc create -f my-scc.yaml

3. カスタムサービスアカウントを作成します。

   例: fsgroup-runasany サービスアカウントの作成

   $ oc create serviceaccount fsgroup-runasany

4. カスタム SCC をカスタムサービスアカウントに関連付けます。

   例: my-scc SCC を fsgroup-runasany サービスアカウントに関連付けます。

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

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

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

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

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

   例: fsgroup-runasany カスタムサービスアカウントを使用した Pipeline 実行 YAML

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

   例: fsgroup-runasany カスタムサービスアカウントを使用したタスク実行 YAML

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

手順

1. pipelines-tutorial リポジトリーで利用可能な YAML ファイルから TriggerBinding リソースを作成します。

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

2. pipelines-tutorial リポジトリーで利用可能な YAML ファイルから TriggerTemplate リソースを作成します。

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

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

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

4. セキュアな HTTPS 接続を使用して EventListener リソースの作成します。

   1. ラベルを追加して、Eventlistener リソースへのセキュアな HTTPS 接続を有効にします。

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

   2. pipelines-tutorial リポジトリーで利用可能な YAML ファイルから EventListener リソースを作成します。

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

   3. 再暗号化 TLS 終端でルートを作成します。

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

手順

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 -

2. コピーした buildah タスクを編集します。

   $ oc edit task buildah-as-user

   例: build ユーザーで変更された Buildah タスク

   apiVersion: tekton.dev/v1
   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: {}

   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/ubi9/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/v1
   kind: TaskRun
   metadata:
     name: buildah-as-user-1000
   spec:
     taskRunTemplate:
       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

   1

   Dockerfile を使用してソースを取得するなどの事前タスクはなく、タスクの実行に焦点が置かれているため、config map を使用します。

   2

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

   3

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

2. (オプション) パイプラインと対応するパイプライン実行を作成します。

   例: パイプラインと対応するパイプラインの実行

   apiVersion: tekton.dev/v1
   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/v1
   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

   1

   git-clone クラスタータスクを使用して、Dockerfile を含むソースを取得し、変更された Buildah タスクを使用してそれをビルドします。

   2

   変更された Buildah タスクを参照してください。

   3

   Buildah タスク用に作成したサービスアカウントを使用します。

   4

   コントローラーによって自動的に作成される永続ボリューム要求 (PVC) を使用して、git-clone タスクと変更された Buildah タスクの間でデータを共有します。

3. タスクの実行またはパイプラインの実行を開始します。