OpenShift Pipelines の保護

手順

1. 次のコマンドを入力して、Mongo サーバーの URL 値を含む MONGO_SERVER_URL ファイルを使用して、mongo-url という名前のシークレットを作成します。

   $ oc create secret generic mongo-url -n tekton-chains \
     --from-file=MONGO_SERVER_URL=<path>/MONGO_SERVER_URL 1

   1

   Mongo サーバーの URL 値が含まれる MONGO_SERVER_URL ファイルの完全なパスと名前。

2. TektonConfig カスタムリソース (CR) の chain セクションで、Tekton Chains コントローラーにシークレットをマウントするように設定し、次の例に示すように、storage.docdb.mongo-server-url-dir パラメーターをシークレットがマウントされるディレクトリーに設定します。

   mongo-url シークレットをマウントする設定例

   apiVersion: operator.tekton.dev/v1
   kind: TektonConfig
   metadata:
     name: config
   spec:
   # ...
     chain:
       disabled: false
       storage.docdb.mongo-server-url-dir: /tmp/mongo-url
       options:
         deployments:
           tekton-chains-controller:
             spec:
               template:
                 spec:
                   containers:
                   - name: tekton-chains-controller
                     volumeMounts:
                     - mountPath: /tmp/mongo-url
                       name: mongo-url
                   volumes:
                   -  name: mongo-url
                      secret:
                       secretName: mongo-url
   # ...

手順

1. 次のコマンドを入力して、KMS サーバーの認証トークンを含む KMS_AUTH_TOKEN ファイルを使用して、kms-secrets という名前のシークレットを作成します。

   $ oc create secret generic kms-secrets -n tekton-chains \
     --from-file=KMS_AUTH_TOKEN=<path_and_name> 1

   1

   KMS サーバーの認証トークンを含むファイルの完全なパスと名前 (例: /home/user/KMS_AUTH_TOKEN)。KMS_AUTH_TOKEN の代わりに別のファイル名を使用することもできます。

2. TektonConfig カスタムリソース (CR) の chain セクションで、Tekton Chains コントローラーにシークレットをマウントするように設定し、signers.kms.auth.token-path パラメーターを認証トークンファイルのフルパス名に設定します (次の例を参照)。

   kms-secrets シークレットをマウントする設定例

   apiVersion: operator.tekton.dev/v1
   kind: TektonConfig
   metadata:
     name: config
   spec:
   # ...
     chain:
       disabled: false
       signers.kms.auth.token-path: /etc/kms-secrets/KMS_AUTH_TOKEN
       options:
         deployments:
           tekton-chains-controller:
             spec:
               template:
                 spec:
                   containers:
                   - name: tekton-chains-controller
                     volumeMounts:
                     - mountPath: /etc/kms-secrets
                       name: kms-secrets
                   volumes:
                   -  name: kms-secrets
                      secret:
                       secretName: kms-secrets
   # ...

手順

1. 次のコマンドを実行して、TektonConfig CR を編集します。

   $ oc edit TektonConfig config

2. TektonConfig CR で、generateSigningSecret の値を true に設定します。

   TektonConfig CR を使用して ecdsa キーペアを作成する例

   apiVersion: operator.tekton.dev/v1
   kind: TektonConfig
   metadata:
     name: config
   spec:
   # ...
     chain:
       disabled: false
       generateSigningSecret: true 1
   # ...

   1

   デフォルト値は false です。値を true に設定すると、ecdsa キーペアが生成されます。

手順

1. 次のコマンドを実行して、cosign.key と cosign.pub キーのペアを生成します。

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

   Cosign はパスワードの入力を求め、Kubernetes シークレットを作成します。

2. 暗号化された cosign.key 秘密鍵と cosign.password 復号化パスワードを、signing-secrets Kubernetes シークレットに保存します。秘密鍵が ENCRYPTED COSIGN PRIVATE KEY 型の暗号化された PEM ファイルとして保存されていることを確認します。

手順

1. 次のコマンドを実行して、公開鍵と秘密鍵のペアを生成します。

   $ skopeo generate-sigstore-key --output-prefix <mykey> 1

   1

   <mykey> を選択した鍵名に置き換えます。

   Skopeo は秘密鍵のパスフレーズの入力を求め、<mykey>.private および <mykey>.pub という名前の鍵ファイルを作成します。

2. 次のコマンドを実行し、base64 ツールを使用して <mykey>.pub ファイルをエンコードします。

   $ base64 -w 0 <mykey>.pub > b64.pub

3. 次のコマンドを実行し、base64 ツールを使用して <mykey>.private ファイルをエンコードします。

   $ base64 -w 0 <mykey>.private > b64.private

4. 次のコマンドを実行し、base64 ツールを使用してパスフレーズをエンコードします。

   $ echo -n '<passphrase>' | base64 -w 0 > b64.passphrase 1

   1

   <passphrase> を鍵ペアに使用したパスフレーズに置き換えます。

5. 次のコマンドを実行して、openshift-pipelines namespace に signing-secrets シークレットを作成します。

   $ oc create secret generic signing-secrets -n openshift-pipelines

6. 以下のコマンドを実行して signing-secrets シークレットを編集します。

   $ oc edit secret -n openshift-pipelines signing-secrets

   次の方法で、エンコードされた鍵をシークレットのデータに追加します。

   apiVersion: v1
   data:
     cosign.key: <Encoded <mykey>.private> 1
     cosign.password: <Encoded passphrase> 2
     cosign.pub: <Encoded <mykey>.pub> 3
   immutable: true
   kind: Secret
   metadata:
     name: signing-secrets
   # ...
   type: Opaque

   1

   <Encoded <mykey>.private> を b64.private ファイルの内容に置き換えます。

   2

   <Encoded passphrase> を b64.passphrase ファイルの内容に置き換えます。

   3

   <Encoded <mykey>.pub> を b64.pub ファイルの内容に置き換えます。

手順

1. 次のコマンドを実行して、signing-secret シークレットを削除します。

   $ oc delete secret signing-secrets -n openshift-pipelines

2. 鍵ペアを再作成し、任意の署名スキームを使用してシークレットに保存します。

手順

1. アクティビティー→PipelineRuns タブに移動します。
2. SBOM を表示するプロジェクトには、最新のパイプライン実行を選択します。

3. PipelineRun の詳細ページで、SBOM の表示 を選択します。

   1. Web ブラウザーを使用すると、ソフトウェアサプライチェーンの脆弱性を示す用語を SBOM ですぐに検索できます。たとえば、log4j を検索してみてください。
   2. SBOM をダウンロードするには Download を選択し、全画面で表示するには Expand を選択できます。

手順

1. ターミナルを開き、開発者 または 管理者 のパースペクティブにログインして、関連するプロジェクトに切り替えます。

2. OpenShift Web コンソールから、download sbom コマンドをコピーし、ターミナルで実行します。

   cosign コマンドの例

   $ cosign download sbom quay.io/<workspace>/user-workload@sha256

   1. (オプション) 完全な SBOM を検索可能な形式で表示するには、次のコマンドを実行して出力をリダイレクトします。

      cosign コマンドの例

      $ cosign download sbom quay.io/<workspace>/user-workload@sha256 > sbom.txt

手順

1. secret.yaml ファイルにシークレットの YAML マニフェストを作成します。このマニフェストでは、対象の Git リポジトリーにアクセスするためのユーザー名とパスワード、または GitHub Personal Access Token を指定します。

   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

   1

   シークレットの名前。この例では、basic-user-pass です。

   2

   Git リポジトリーのユーザー名。

   3

   Git リポジトリーのパスワードまたは Personal Access Token

2. サービスアカウントの YAML マニフェストを serviceaccount.yaml ファイルに作成します。このマニフェストで、シークレットをサービスアカウントに関連付けます。

   apiVersion: v1
   kind: ServiceAccount
   metadata:
     name: build-bot 1
   secrets:
     - name: basic-user-pass 2

   1

   サービスアカウントの名前。この例では、build-bot です。

   2

   シークレットの名前。この例では、basic-user-pass です。

3. run.yaml ファイルにタスク実行またはパイプライン実行の YAML マニフェストを作成し、サービスアカウントをタスク実行またはパイプライン実行に関連付けます。次のいずれかの例を使用します。

   • サービスアカウントを TaskRun リソースに関連付けます。

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

     1

     タスク実行の名前。この例では、build-push-task-run-2 です。

     2

     サービスアカウントの名前。この例では、build-bot です。

     3

     タスクの名前。この例では、build-push です。

   • サービスアカウントを PipelineRun リソースに関連付けます。

     apiVersion: tekton.dev/v1
     kind: PipelineRun
     metadata:
       name: demo-pipeline 1
       namespace: default
     spec:
       taskRunTemplate:
         serviceAccountName: build-bot 2
       pipelineRef:
         name: demo-pipeline 3

     1

     パイプライン実行の名前。この例では、demo-pipeline です。

     2

     サービスアカウントの名前。この例では、build-bot です。

     3

     パイプラインの名前。この例では、demo-pipeline です。

4. 次のコマンドを入力して、作成した YAML マニフェストを適用します。

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

手順

1. SSH 秘密鍵 を生成するか、既存の秘密鍵をコピーします。これは通常 ~/.ssh/id_rsa ファイルで入手できます。

2. secret.yaml ファイルにシークレットの 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

   1

   SSH 秘密鍵が含まれるシークレットの名前。この例では、ssh-key です。

   2

   SSH 秘密鍵ファイルの内容。

   3

   既知のホストファイルの内容。

   重要

   既知のホストファイルを省略すると、OpenShift Pipelines は任意のサーバーの公開鍵を受け入れます。

3. オプション: アノテーション値の末尾に :<port_number> を追加して、カスタム SSH ポートを指定します。たとえば、tekton.dev/git-0: github.com:2222 などです。

4. サービスアカウントの YAML マニフェストを serviceaccount.yaml ファイルに作成します。このマニフェストで、シークレットをサービスアカウントに関連付けます。

   apiVersion: v1
   kind: ServiceAccount
   metadata:
     name: build-bot 1
   secrets:
     - name: ssh-key 2

   1

   サービスアカウントの名前。この例では、build-bot です。

   2

   SSH 秘密鍵が含まれるシークレットの名前。この例では、ssh-key です。

5. run.yaml ファイルで、サービスアカウントをタスク実行またはパイプライン実行に関連付けます。次のいずれかの例を使用します。

   • サービスアカウントをタスク実行に関連付けます。

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

     1

     タスク実行の名前。この例では、build-push-task-run-2 です。

     2

     サービスアカウントの名前。この例では、build-bot です。

     3

     タスクの名前。この例では、build-push です。

   • サービスアカウントをパイプライン実行に関連付けます。

     apiVersion: tekton.dev/v1
     kind: PipelineRun
     metadata:
       name: demo-pipeline 1
       namespace: default
     spec:
       taskRunTemplate:
         serviceAccountName: build-bot 2
       pipelineRef:
         name: demo-pipeline 3

     1

     パイプライン実行の名前。この例では、demo-pipeline です。

     2

     サービスアカウントの名前。この例では、build-bot です。

     3

     パイプラインの名前。この例では、demo-pipeline です。

6. 変更を適用します。

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

手順

1. 次のコマンドを入力して、認証情報を含めて、既存の config.json ファイルからコンテナーレジストリー認証シークレットを作成します。

   $ oc create secret generic my-registry-credentials \ 1
     --from-file=config.json=/home/user/credentials/config.json 2

   1

   シークレットの名前。この例では、my-registry-credentials です。

   2

   config.json ファイルのパス名。この例では、/home/user/credentials/config.json です。

2. サービスアカウントの YAML マニフェストを serviceaccount.yaml ファイルに作成します。このマニフェストで、シークレットをサービスアカウントに関連付けます。

   apiVersion: v1
   kind: ServiceAccount
   metadata:
     name: container-bot 1
   secrets:
     - name: my-registry-credentials 2

   1

   サービスアカウントの名前。この例では、container-bot です。

   2

   SSH 秘密鍵が含まれるシークレットの名前。この例では、my-registry-credentials です。

3. タスク実行またはパイプライン実行の YAML マニフェストを run.yaml ファイルとして作成します。このファイルで、サービスアカウントをタスク実行またはパイプライン実行に関連付けます。次のいずれかの例を使用します。

   • サービスアカウントをタスク実行に関連付けます。

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

     1

     タスク実行の名前。この例では、build-container-task-run-2 です。

     2

     サービスアカウントの名前。この例では、container-bot です。

     3

     タスクの名前。この例では、build-container です。

   • サービスアカウントをパイプライン実行に関連付けます。

     apiVersion: tekton.dev/v1
     kind: PipelineRun
     metadata:
       name: demo-pipeline 1
       namespace: default
     spec:
       taskRunTemplate:
         serviceAccountName: container-bot 2
       pipelineRef:
         name: demo-pipeline 3

     1

     パイプライン実行の名前。この例では、demo-pipeline です。

     2

     サービスアカウントの名前。この例では、container-bot です。

     3

     パイプラインの名前。この例では、demo-pipeline です。

4. 次のコマンドを入力して変更を適用します。

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

手順

1. 次のコマンドを入力して、既存の .ssh ディレクトリー内のファイルから Git SSH 認証シークレットを作成します。

   $ oc create secret generic my-github-ssh-credentials \ 1
     --from-file=id_ed25519=/home/user/.ssh/id_ed25519 \ 2
     --from-file=known_hosts=/home/user/.ssh/known_hosts 3

   1

   シークレットの名前。この例では、my-github-ssh-credentials です。

   2

   秘密鍵ファイルの名前と完全パス名。この例では、/home/user/.ssh/id_ed25519 です。

   3

   既知のホストファイルの名前とフルパス名。この例では、/home/user/.ssh/known_hosts です。

2. タスク定義で、Git 認証用の名前付きワークスペース (例: ssh-directory) を設定します。

   ワークスペースの定義例

   apiVersion: tekton.dev/v1beta1
   kind: Task
   metadata:
     name: git-clone
   spec:
     workspaces:
       - name: ssh-directory
         description: |
           A .ssh directory with private key, known_hosts, config, etc.

3. タスクの手順では、$(workspaces.<workspace_name>.path) 環境変数のパスを使用してディレクトリーにアクセスします (例: $(workspaces.ssh-directory.path))。

4. タスクを実行するときは、tkn task start コマンドに --workspace 引数を含めて、名前付きワークスペースのシークレットを指定します。

   $ tkn task start <task_name>
         --workspace name=<workspace_name>,secret=<secret_name> 1
         # ...

   1

   <workspace_name> は、設定したワークスペースの名前に、<secret_name> は、作成したシークレットの名前に置き換えます。

手順

1. 次のコマンドを入力して、認証情報を含めて、既存の config.json ファイルからコンテナーレジストリー認証シークレットを作成します。

   $ oc create secret generic my-registry-credentials \ 1
     --from-file=config.json=/home/user/credentials/config.json 2

   1

   シークレットの名前。この例では、my-registry-credentials です。

   2

   config.json ファイルのパス名。この例では、/home/user/credentials/config.json です。

2. タスク定義で、Git 認証用の名前付きワークスペース (例: ssh-directory) を設定します。

   ワークスペースの定義例

   apiVersion: tekton.dev/v1beta1
   kind: Task
   metadata:
     name: skopeo-copy
   spec:
     workspaces:
       - name: dockerconfig
         description: Includes a docker `config.json`
   # ...

3. タスクの手順では、$(workspaces.<workspace_name>.path) 環境変数のパス (例: $(workspaces.dockerconfig.path)) を使用してディレクトリーにアクセスします。

4. タスクを実行するには、tkn task start コマンドに --workspace 引数を含めて、名前付きワークスペースのシークレットを指定します。

   $ tkn task start <task_name>
         --workspace name=<workspace_name>,secret=<secret_name> 1
         # ...

   1

   <workspace_name> は、設定したワークスペースの名前に、<secret_name> は、作成したシークレットの名前に置き換えます。

手順

1. openshift-pipelines namespace で提供されている buildah タスクのコピーを作成し、コピーの名前を buildah-as-user に変更します。

   $ oc get task buildah -n openshift-pipelines -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:
         resolver: cluster
         params:
         - name: kind
           value: task
         - name: name
           value: git-clone
         - name: namespace
           value: openshift-pipelines
       workspaces:
       - name: output
         workspace: shared-workspace
       params:
       - name: URL
         value: $(params.URL)
       - name: SUBDIRECTORY
         value: ""
       - name: DELETE_EXISTING
         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. タスクの実行またはパイプラインの実行を開始します。