検索

OpenShift Pipelines の保護

download PDF
Red Hat OpenShift Pipelines 1.13

OpenShift Pipelines のセキュリティー機能

Red Hat OpenShift Documentation Team

概要

このドキュメントでは、OpenShift Pipelines のセキュリティー機能について説明します。

第1章 OpenShift Pipelines サプライチェーンセキュリティーでの Tekton Chains の使用

Tekton Chains は、Kubernetes カスタムリソース定義 (CRD) コントローラーです。これを使用して、Red Hat OpenShift Pipelines を使用して作成されたタスクおよびパイプラインのサプライチェーンセキュリティーを管理できます。

デフォルトでは、Tekton Chains は OpenShift Container Platform クラスター内のすべてのタスク実行を監視します。タスクの実行が完了すると、Tekton Chains はタスク実行のスナップショットを取得します。次に、スナップショットを 1 つ以上の標準ペイロード形式に変換し、最後にすべてのアーティファクトに署名して保存します。

タスクの実行に関する情報を取得するために、Tekton Chains は Result オブジェクトを使用します。オブジェクトが使用できない場合、Tekton Chains はOCI イメージの URL と修飾ダイジェストを使用します。

1.1. 主な特長

  • cosignskopeo などのツールで生成された暗号キーを使用して、タスク実行、タスク実行結果、OCI レジストリーイメージに署名できます。
  • in-toto などの認証形式を使用できます。
  • OCI リポジトリーをストレージバックエンドとして使用して、署名と署名されたアーティファクトを安全に保存できます。

1.2. Tekton Chains の設定

Red Hat OpenShift Pipelines Operator は、デフォルトで Tekton Chains をインストールします。TektonConfig カスタムリソースを変更することで、Tekton Chains を設定できます。Operator は、このカスタムリソースに加えた変更を自動的に適用します。

カスタムリソースを編集するには、次のコマンドを使用します。

$ oc edit TektonConfig config

カスタムリソースには、chain: 配列が含まれます。次の例に示すように、サポートされている設定パラメーターをこの配列に追加できます。

apiVersion: operator.tekton.dev/v1alpha1
kind: TektonConfig
metadata:
  name: config
spec:
  addon: {}
  chain:
    artifacts.taskrun.format: tekton
  config: {}

1.2.1. Tekton Chains 設定でサポートされているパラメーター

クラスター管理者は、サポートされているさまざまなパラメーターのキーと値を使用して、タスクの実行、OCI イメージ、およびストレージに関する仕様を設定できます。

1.2.1.1. タスク実行アーティファクトでサポートされているパラメーター
表1.1 チェーン設定: タスク実行アーティファクトでサポートされているパラメーター
キー説明サポート対象の値デフォルト値

artifacts.taskrun.format

タスク実行ペイロードを保存するための形式。

in-toto, slsa/v1

in-toto

artifacts.taskrun.storage

タスク実行署名のストレージバックエンド。“tekton,oci" のように、複数のバックエンドをコンマ区切りのリストとして指定できます。タスク実行アーティファクトの保存を無効にするには、空の文字列 “” を指定します。

tekton, oci, gcs, docdb, grafeas

tekton

artifacts.taskrun.signer

タスク実行ペイロードに署名するための署名バックエンド。

x509, kms

x509

注記

slsa/v1 は、下位互換性のための in-toto のエイリアスです。

1.2.1.2. パイプライン実行アーティファクトでサポートされているパラメーター
表1.2 チェーン設定: パイプライン実行アーティファクトでサポートされているパラメーター
パラメーター説明サポート対象の値デフォルト値

artifacts.pipelinerun.format

パイプライン実行ペイロードを保存する形式。

in-toto, slsa/v1

in-toto

artifacts.pipelinerun.storage

パイプライン実行署名を保存するためのストレージバックエンド。“tekton,oci" のように、複数のバックエンドをコンマ区切りのリストとして指定できます。パイプライン実行アーティファクトの保存を無効にするには、空の文字列 "" を指定します。

tekton, oci, gcs, docdb, grafeas

tekton

artifacts.pipelinerun.signer

パイプライン実行ペイロードに署名するための署名バックエンド。

x509, kms

x509

注記
  • slsa/v1 は、下位互換性のための in-toto のエイリアスです。
  • Grafeas ストレージバックエンドの場合、Container Analysis のみがサポートされます。Tekton Chains の現在のバージョンでは、grafeas サーバーアドレスを設定できません。
1.2.1.3. OCI アーティファクトでサポートされているパラメーター
表1.3 チェーン設定: OCI アーティファクトでサポートされているパラメーター
パラメーター説明サポート対象の値デフォルト値

artifacts.oci.format

OCI ペイロードを保存するための形式。

simplesigning

simplesigning

artifacts.oci.storage

OCI 署名を保存するためのストレージバックエンド。“oci,tekton" のように、複数のバックエンドをコンマ区切りのリストとして指定できます。OCI アーティファクトの保存を無効にするには、空の文字列 “” を指定します。

tekton, oci, gcs, docdb, grafeas

oci

artifacts.oci.signer

OCI ペイロードに署名するための署名バックエンド。

x509, kms

x509

1.2.1.4. KMS 署名者でサポートされているパラメーター
表1.4 チェーン設定: KMS 署名者用にサポートされているパラメーター
パラメーター説明サポート対象の値デフォルト値

signers.kms.kmsref

kms 署名者で使用する KMS サービスへの URI 参照。

サポートされているスキーム: gcpkms://awskms://azurekms://hachivault://。詳細は、Sigstore ドキュメントの KMS サポート を参照してください。

 
1.2.1.5. ストレージでサポートされているパラメーター
表1.5 Chains 設定: ストレージでサポートされているパラメーター
パラメーター説明サポート対象の値デフォルト値

storage.gcs.bucket

ストレージ用の GCS バケット

  

storage.oci.repository

OCI 署名と証明書を保存するための OCI リポジトリー。

アーティファクトストレージバックエンドの 1 つを oci に設定し、このキーを定義しない場合、Tekton Chains は、保存された OCI アーティファクト自体と一緒に証明書を保存します。このキーを定義すると、証明書は OCI アーティファクトと一緒に保存されず、指定された場所に保存されます。追加情報は、署名のドキュメント を参照してください。

 

builder.id

in-toto 証明書に設定するビルダー ID

 

https://tekton.dev/chains/v2

任意のアーティファクトに対して docdb ストレージ方法を有効にする場合は、docstore ストレージオプションを設定します。go-cloud docstore URI 形式の詳細は、docstore パッケージのドキュメント を参照してください。Red Hat OpenShift Pipelines は、次の docstore サービスをサポートしています。

  • firestore
  • dynamodb
表1.6 Chains 設定: docstore ストレージでサポートされているパラメーター
パラメーター説明サポート対象の値デフォルト値

storage.docdb.url

docstore コレクションへの go-cloud URI 参照。アーティファクトに対して docdb ストレージ方式が有効になっている場合に使用されます。

firestore://projects/[PROJECT]/databases/(default)/documents/[COLLECTION]?name_field=name

 

アーティファクトに対して Grafeas ストレージ方式を有効にする場合は、Grafeas ストレージオプションを設定します。Grafeas のメモとオカレンスの詳細は、 Grafeas の概念 を参照してください。

オカレンスを作成するには、Red Hat OpenShift Pipelines はまずオカレンスのリンクに使用されるノートを作成する必要があります。Red Hat OpenShift Pipelines は、ATESTATION オカレンスと BUILD オカレンスの 2 種類のオカレンスを作成します。

Red Hat OpenShift Pipelines は、設定可能な noteid をノート名の接頭辞として使用します。ATTESTATION ノートには接尾辞 -simplesigning が、BUILD ノートには接尾辞 -intoto が追加されます。noteid フィールドが設定されていない場合、Red Hat OpenShift Pipelines は接頭辞として tekton-<NAMESPACE> を使用します。

表1.7 Chains 設定: Grafeas ストレージでサポートされているパラメーター
パラメーター説明サポート対象の値デフォルト値

storage.grafeas.projectid

オカレンスを保存する Grafeas サーバーが配置されている OpenShift Container Platform プロジェクト。

  

storage.grafeas.noteid

オプション: 作成されたすべてのメモの名前に使用する接頭辞。

スペースなしの文字列。

 

storage.grafeas.notehint

オプション: Grafeas ATTESTATION メモの human_readable_name フィールド。

 

This attestation note was generated by Tekton Chains

オプションで、バイナリー透明性証明書の追加アップロードを有効にできます。

表1.8 Chains 設定: 透明性証明書ストレージでサポートされているパラメーター
パラメーター説明サポート対象の値デフォルト値

transparency.enabled

自動バイナリー透明性アップロードを有効または無効にします。

truefalsemanual

false

transparency.url

バイナリー透明性証明書をアップロードするための URL (有効な場合)。

 

https://rekor.sigstore.dev

注記

Transparency.enabledmanual に設定すると、次のアノテーションが付いたタスク実行とパイプライン実行のみが透過性ログにアップロードされます。

chains.tekton.dev/transparency-upload: "true"

x509 署名バックエンドを設定する場合、オプションで Fulcio を使用したキーレス署名を有効にできます。

表1.9 チェーン設定: Fulcio を使用した x509 キーレス署名でサポートされているパラメーター
パラメーター説明サポート対象の値デフォルト値

signers.x509.fulcio.enabled

Fulcio からの自動証明書の要求を有効または無効にします。

truefalse

false

signers.x509.fulcio.address

証明書を要求するための Fulcio アドレス (有効な場合)。

 

https://v1.fulcio.sigstore.dev

signers.x509.fulcio.issuer

予想される OIDC 発行者。

 

https://oauth2.sigstore.dev/auth

signers.x509.fulcio.provider

ID トークンを要求するプロバイダー。

Googlespiffegithubfilesystem

Red Hat OpenShift Pipelines はすべてのプロバイダーの使用を試みます

signers.x509.identity.token.file

ID トークンを含むファイルへのパス。

  

signers.x509.tuf.mirror.url

TUF サーバーの URL。$TUF_URL/root.json が存在する必要があります。

 

https://sigstore-tuf-root.storage.googleapis.com

kms 署名バックエンドを設定する場合は、必要に応じて OIDC や Spire を含む KMS 設定を行います。

表1.10 Chains 設定: KMS 署名でサポートされているパラメーター
パラメーター説明サポート対象の値デフォルト値

signers.kms.auth.address

KMS サーバーの URI (VAULT_ADDR の値)。

signers.kms.auth.token

KMS サーバーの認証トークン (VAULT_TOKEN の値)。

signers.kms.auth.oidc.path

OIDC 認証のパス (Vault の場合は jwt など)。

signers.kms.auth.oidc.role

OIDC 認証のロール。

signers.kms.auth.spire.sock

KMS トークンの Spire ソケットの URI (例: unix:///tmp/spire-agent/public/api.sock)。

signers.kms.auth.spire.audience

Spire から SVID を要求する対象者。

1.3. Tekton Chains でデータに署名するための秘密

クラスター管理者は、キーペアを生成し、Tekton Chains を使用して、Kubernetes シークレットでアーティファクトに署名できます。Tekton Chains が機能するには、暗号化されたキーの秘密鍵とパスワードが、openshift-pipelines namespace の signing-secrets シークレットの一部として存在している必要があります。

現在、Tekton Chains は x509 および cosign 署名スキームをサポートしています。

注記

使用できるのは、サポートされている署名スキームのいずれか 1 つのみです。

Tekton Chains で x509 署名スキームを使用するには、ed25519 または ecdsa 型の x509.pem 秘密鍵を signing-secrets Kubernetes シークレットに保存します。

1.3.1. cosign を使用した署名

cosign 署名ツールを使用すると、Tekton Chains で cosign スキームを使用できます。

前提条件

  • cosign ツールをインストールしている。

手順

  1. 次のコマンドを実行して、cosign.keycosign.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.3.2. skopeo を使用した署名

skopeo ツールを使用して鍵を生成し、Tekton Chains で cosign 署名スキームで使用できます。

前提条件

  • skopeo ツールをインストールしている。

手順

  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 に signed-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.3.3. "secret already exists" エラーの解決

signed-secret シークレットがすでに入力されている場合、このシークレットを作成するコマンドは次のエラーメッセージを出力する可能性があります。

Error from server (AlreadyExists): secrets "signing-secrets" already exists

このエラーは、シークレットを削除することで解決できます。

手順

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

    $ oc delete secret signing-secrets -n openshift-pipelines
  2. 鍵ペアを再作成し、任意の署名スキームを使用してシークレットに保存します。

1.4. OCI レジストリーへの認証

署名を OCI レジストリーにプッシュする前に、クラスター管理者は、レジストリーで認証するように Tekton Chains を設定する必要があります。Tekton Chains コントローラーは、タスクの実行と同じサービスアカウントを使用します。署名を OCI レジストリーにプッシュするために必要な認証情報を使用してサービスアカウントを設定するには、次の手順を実行します。

手順

  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.5. 追加認証なしでタスク実行の署名を作成および検証する

追加認証を使用して Tekton Chains でタスク実行の署名を検証するには、次のタスクを実行します。

  • 暗号化された x509 キーペアを作成し、Kubernetes シークレットとして保存します。
  • Tekton Chains バックエンドストレージを設定します。
  • タスク実行を作成して署名し、署名とペイロードをタスク実行自体にアノテーションとして保存します。
  • 署名されたタスクの実行から署名とペイロードを取得します。
  • タスク実行の署名を確認します。

前提条件

次のコンポーネントがクラスターにインストールされていることを確認する。

  • Red Hat OpenShift Pipelines Operator
  • Tekton Chains
  • Cosign

手順

  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. 作成した公開鍵を使用して署名を検証するには、次のコマンドを入力します。
$ cosign verify-blob-attestation --insecure-ignore-tlog --key path/to/cosign.pub --signature sig --type slsaprovenance --check-claims=false /dev/null 1
1
path/to/cosign.pub を公開鍵ファイルのパス名に置き換えます。

出力例

Verified OK

1.5.1. 関連情報

1.6. Tekton Chains を使用したイメージと取得元の署名および検証

クラスター管理者は、Tekton Chains を使用して、以下のタスクを実行することで、イメージと証明書を署名および検証できます。

  • 暗号化された x509 鍵ペアを作成し、Kubernetes シークレットとして保存します。
  • OCI レジストリーの認証を設定して、イメージ、イメージ署名、および署名されたイメージ証明書を保存します。
  • Tekton Chains を設定して、証明書を生成し署名します。
  • タスク実行で Kaniko を使用してイメージを作成します。
  • 署名されたイメージと署名された証明書を検証する。

前提条件

以下がクラスターにインストールされていることを確認します。

  • Red Hat OpenShift Pipelines Operator
  • Tekton Chains
  • Cosign
  • Rekor
  • jq

手順

  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.formatartifacts.taskrun.storagetransparency.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.7. 関連情報

第2章 Pod のセキュリティーコンテキストの設定

OpenShift Pipelines が開始する Pod のデフォルトのサービスアカウントは、Pipeline です。pipeline サービスアカウントに関連付けられた security context constraint (SCC) は、Pipelines-scc です。Pipelines-scc SCC は anyuid SCC に基づいていますが、次の YAML 仕様で定義されているように若干の違いがあります。

pipelines-scc.yaml スニペットの例

apiVersion: security.openshift.io/v1
kind: SecurityContextConstraints
# ...
allowedCapabilities:
  - SETFCAP
# ...
fsGroup:
  type: MustRunAs
# ...

さらに、OpenShift Pipeline の一部として提供される Buildah クラスタータスクは、デフォルトのストレージドライバーとして vfs を使用します。

OpenShift Pipelines がパイプライン実行およびタスク実行用に作成する Pod のセキュリティーコンテキストを設定できます。次の変更を加えることができます。

  • すべての Pod のデフォルトおよび最大 SCC を変更する
  • 特定の namespace でのパイプライン実行およびタスク実行用に作成された Pod のデフォルト SCC を変更する
  • カスタム SCC およびサービスアカウントを使用するように特定のパイプライン実行またはタスク実行を設定する
注記

すべてのイメージを確実にビルドできるように buildah を実行する最も簡単な方法は、特権 SCC を使用して Pod 内で root として実行することです。より制限的なセキュリティー設定で buildah を実行する手順は、root 以外のユーザーとして Buildah を使用したコンテナーイメージのビルド を参照してください。

2.1. OpenShift Pipelines が作成する Pod のデフォルトおよび最大 SCC の設定

OpenShift Pipelines がタスク実行およびパイプライン実行用に作成するすべての Pod に対して、デフォルトの security context constraint (SCC) を設定できます。最大 SCC を設定することもできますが、これは、任意の namespace 内のこれらの Pod に対して設定できる最も制限の少ない SCC です。

手順

  • 次のコマンドを入力して、TektonConfig カスタムリソース (CR) を編集します。

    $ oc edit TektonConfig config

    次の例のように、仕様でデフォルトと最大の SCC を設定します。

    apiVersion: operator.tekton.dev/v1alpha1
    kind: TektonConfig
    metadata:
      name: config
    spec:
    #  ...
      platforms:
        openshift:
          scc:
            default: "restricted-v2" 1
            maxAllowed: "privileged" 2
    1
    spec.platforms.openshift.scc.default は、OpenShift Pipelines がワークロードに使用されるサービスアカウント (SA) にアタッチするデフォルトの SCC (デフォルトでは pipeline SA) を指定します。この SCC は、すべてのパイプライン実行 Pod とタスク実行 Pod に使用されます。
    2
    spec.platforms.openshift.scc.maxAllowed は、任意の namespace のパイプライン実行 Pod およびタスク実行 Pod に対して設定できる最も制限の少ない SCC を指定します。この設定は、特定のパイプライン実行またはタスク実行でカスタム SA および SCC を設定する場合には適用されません。

2.2. namespace 内の Pod の SCC 設定

特定の namespace で作成したパイプライン実行およびタスク実行用に OpenShift Pipelines が作成するすべての Pod に対してセキュリティーコンテキスト制約 (SCC) を設定できます。この SCC は、spec.platforms.openshift.scc.maxAllowed 仕様で TektonConfig CR を使用して設定した最大 SCC よりも制限が厳密に指定することはできません。

手順

  • namespace の operator.tekton.dev/scc アノテーションを SCC の名前に設定します。

    OpenShift Pipelines Pod の SCC を設定するための namespace アノテーションの例

    apiVersion: v1
    kind: Namespace
    metadata:
      name: test-namespace
      annotations:
        operator.tekton.dev/scc: nonroot

2.3. カスタム SCC およびカスタムサービスアカウントを使用したパイプライン実行とタスク実行

デフォルトの pipelines サービスアカウントに関連付けられた pipelines-scc SCC (Security Context Constraints) を使用する場合、パイプライン実行およびタスク実行 Pod にタイムアウトが生じる可能性があります。これは、デフォルトの pipelines-scc SCC で fsGroup.type パラメーターが MustRunAs に設定されているために発生します。

注記

Pod タイムアウトの詳細は、BZ#1995779 を参照してください。

Pod タイムアウトを回避するには、fsGroup.type パラメーターを RunAsAny に設定してカスタム SCC を作成し、これをカスタムサービスアカウントに関連付けることができます。

注記

ベストプラクティスとして、パイプライン実行とタスク実行にカスタム SCC およびカスタムサービスアカウントを使用します。このアプローチを使用することで、柔軟性が増し、アップグレード時にデフォルト値が変更されても実行が失敗することはありません。

手順

  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'

2.4. 関連情報

第3章 イベントリスナーによる Webhook のセキュリティー保護

管理者は、イベントリスナーで Webhook をセキュアにできます。namespace の作成後に、operator.tekton.dev/enable-annotation=enabled ラベルを namespace に追加して、Eventlistener リソースの HTTPS を有効にします。次に、再暗号化した TLS 終端を使用して Trigger リソースとセキュアなルートを作成します。

Red Hat OpenShift Pipelines のトリガーは、Eventlistener リソースへの非セキュアな HTTP およびセキュアな HTTPS 接続の両方をサポートします。HTTPS は、クラスター内外の接続を保護します。

Red Hat OpenShift Pipelines は、namespace のラベルを監視する tekton-operator-proxy-webhook Pod を実行します。ラベルを namespace に追加する場合、Webhook は service.beta.openshift.io/serving-cert-secret-name=<secret_name> アノテーションを EventListener オブジェクトに設定します。これにより、シークレットおよび必要な証明書が作成されます。

service.beta.openshift.io/serving-cert-secret-name=<secret_name>

さらに、作成されたシークレットを Eventlistener Pod にマウントし、要求を保護できます。

3.1. OpenShift ルートを使用したセキュアな接続の提供

再暗号化した TLS 終端を使用してルートを作成するには、以下を実行します。

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

または、再暗号化 TLS 終端 YAML ファイルを作成して、セキュアなルートを作成できます。

セキュアなルートを作成する再暗号化 TLS 終端 YAML の例

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: route-passthrough-secured  1
spec:
  host: <hostname>
  to:
    kind: Service
    name: frontend 2
  tls:
    termination: reencrypt 3
    key: [as in edge termination]
    certificate: [as in edge termination]
    caCertificate: [as in edge termination]
    destinationCACertificate: |- 4
      -----BEGIN CERTIFICATE-----
      [...]
      -----END CERTIFICATE-----

1 2
オブジェクトの名前 (63 文字のみに制限)。
3
termination フィールドは reencrypt に設定されます。これは、必要な唯一の TLS フィールドです。
4
これは、再暗号化に必要です。destinationCACertificate は CA 証明書を指定してエンドポイントの証明書を検証し、ルーターから宛先 Pod への接続のセキュリティーを保護します。このフィールドは以下のいずれかのシナリオで省略できます。
  • サービスは、サービス署名証明書を使用します。
  • 管理者はルーターのデフォルト CA 証明書を指定し、サービスにはその CA によって署名された証明書を指定します。

oc create route reencrypt --help コマンドを実行すると、他のオプションを表示できます。

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

このセクションでは、pipelines-tutorial の例を使用して、セキュアな HTTPS 接続を使用した EventListener リソースのサンプルの作成について説明します。

手順

  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>

第4章 シークレットを使用したリポジトリーでのパイプラインの認証

パイプラインおよびタスクでは、Git リポジトリーおよびコンテナーリポジトリーでの認証に認証情報が必要になる場合があります。Red Hat OpenShift Pipelines では、シークレットを使用して、実行時に Git リポジトリーまたはコンテナーリポジトリーと対話するパイプライン実行およびタスク実行を認証できます。

Git リポジトリーでの認証用のシークレットは Git シークレット と呼ばれます。

パイプライン実行またはタスク実行は、関連付けられたサービスアカウントを介してシークレットにアクセスできます。または、パイプラインまたはタスクで Workspace を定義し、シークレットをワークスペースにバインドすることもできます。

4.1. 前提条件

  • oc OpenShift コマンドラインユーティリティーをインストールしている。

4.2. サービスアカウントを使用したシークレットの提供

サービスアカウントを使用して、Git リポジトリーおよびコンテナーリポジトリーでの認証にシークレットを提供できます。

シークレットをサービスアカウントに関連付けることができます。シークレット内の情報は、このサービスアカウントで実行されるタスクで利用できるようになります。

4.2.1. サービスアカウントのシークレットのタイプおよびアノテーション

サービスアカウントを使用して認証シークレットを指定する場合、OpenShift Pipelines はいくつかのシークレットタイプをサポートします。これらのシークレットタイプのほとんどでは、認証シークレットが有効であるリポジトリーを定義するアノテーションを指定する必要があります。

4.2.1.1. Git 認証シークレット

サービスアカウントを使用して認証シークレットを指定する場合、OpenShift Pipelines は Git 認証用の以下のタイプのシークレットをサポートします。

  • kubernetes.io/basic-auth: Basic 認証のユーザー名とパスワード
  • kubernetes.io/ssh-auth: SSH ベースの認証用のキー

サービスアカウントを使用して認証シークレットを指定する場合は、Git シークレットに 1 つ以上のアノテーションキーが必要です。各キーの名前は tekton.dev/git- で開始する必要があり、値は OpenShift Pipeline がシークレットの認証情報を使用する必要があるホストの URL です。

以下の例では、OpenShift Pipeline は basic-auth シークレットを使用して github.com および gitlab.com のリポジトリーにアクセスします。

例:複数の Git リポジトリーを使用した Basic 認証の認証情報

apiVersion: v1
kind: Secret
metadata:
  name: git-secret-basic
  annotations:
    tekton.dev/git-0: github.com
    tekton.dev/git-1: gitlab.com
type: kubernetes.io/basic-auth
stringData:
  username: <username> 1
  password: <password> 2

1
リポジトリーのユーザー名
2
リポジトリーのパスワードまたはパーソナルアクセストークン

以下の例のように、ssh-auth シークレットを使用して、Git リポジトリーにアクセスするための秘密鍵を指定することもできます。

例:SSH ベースの認証の秘密鍵

apiVersion: v1
kind: Secret
metadata:
  name: git-secret-ssh
  annotations:
    tekton.dev/git-0: https://github.com
type: kubernetes.io/ssh-auth
stringData:
  ssh-privatekey: 1

1
SSH 秘密鍵ファイルの内容。
4.2.1.2. コンテナーレジストリーの認証シークレット

サービスアカウントを使用して認証シークレットを提供する場合、OpenShift Pipelines はコンテナー(Docker)レジストリー認証用の以下のタイプのシークレットをサポートします。

  • kubernetes.io/basic-auth: Basic 認証のユーザー名とパスワード
  • kubernetes.io/dockercfg: シリアル化された ~/.dockercfg ファイル
  • kubernetes.io/dockerconfigjson: シリアライズされた ~/.docker/config.json ファイル

サービスアカウントを使用して認証シークレットを提供する場合、kubernetes.io/basic-auth タイプのコンテナーレジストリーシークレットには 1 つ以上のアノテーションキーが必要です。各キーの名前は tekton.dev/docker- で開始する必要があり、値は OpenShift Pipeline がシークレットの認証情報を使用する必要があるホストの URL になります。このアノテーションは、他のタイプのコンテナーレジストリーシークレットには必要ありません。

以下の例では、OpenShift Pipelines はユーザー名とパスワードに依存する basic-auth シークレットを使用して、quay.io および my-registry.example.com のコンテナーレジストリーにアクセスします。

例:複数のコンテナーリポジトリーを使用した Basic 認証の認証情報

apiVersion: v1
kind: Secret
metadata:
  name: docker-secret-basic
  annotations:
    tekton.dev/docker-0: quay.io
    tekton.dev/docker-1: my-registry.example.com
type: kubernetes.io/basic-auth
stringData:
  username: <username> 1
  password: <password> 2

1
レジストリーのユーザー名
2
レジストリーのパスワードまたはパーソナルアクセストークン

次の例のように、既存の設定ファイルから kubernetes.io/dockercfg および kubernetes.io/dockerconfigjson シークレットを作成できます。

例:既存の設定ファイルからコンテナーリポジトリーに対して認証するためのシークレットを作成するコマンド

$ oc create secret generic docker-secret-config \
    --from-file=config.json=/home/user/.docker/config.json \
    --type=kubernetes.io/dockerconfigjson

以下の例のように、oc コマンドラインユーティリティーを使用して、認証情報から kubernetes.io/dockerconfigjson シークレットを作成することもできます。

例:認証情報からコンテナーリポジトリーに対して認証するためのシークレットを作成するコマンド

$ oc create secret docker-registry docker-secret-config \
  --docker-email=<email> \ 1
  --docker-username=<username> \ 2
  --docker-password=<password> \ 3
  --docker-server=my-registry.example.com:5000 4

1
レジストリーのメールアドレス
2
レジストリーのユーザー名
3
レジストリーのパスワードまたはパーソナルアクセストークン
4
レジストリーのホスト名およびポート

4.2.2. サービスアカウントを使用した Git の Basic 認証の設定

パイプラインが、パスワードで保護されたリポジトリーからリソースを取得するには、そのパイプラインの Basic 認証を設定できます。

注記

Basic 認証ではなく SSH ベースの認証を使用することを検討してください。

パイプラインの Basic 認証を設定するには、Basic 認証シークレットを作成し、このシークレットをサービスアカウントに関連付け、このサービスアカウントを TaskRun または PipelineRun リソースに関連付けます。

注記

GitHub では、プレーンパスワードを使用した認証は非推奨になりました。代わりに、パーソナルアクセストークン を使用します。

手順

  1. secret.yaml ファイルにシークレットの 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
    1
    シークレットの名前。この例では、basic-user-pass です。
    2
    Git リポジトリーのユーザー名。
    3
    Git リポジトリーのパスワードまたはパーソナルアクセストークン。
  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

4.2.3. サービスアカウントを使用した Git の SSH 認証の設定

パイプラインが SSH キーで設定されたリポジトリーからリソースを取得するには、そのパイプラインの SSH ベースの認証を設定する必要があります。

パイプラインの SSH ベースの認証を設定するには、SSH 秘密鍵で認証シークレットを作成し、このシークレットをサービスアカウントに関連付け、このサービスアカウントを TaskRun または PipelineRun リソースに関連付けます。

手順

  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
    既知のホストファイルの内容。
    重要

    既知の hosts ファイルを省略すると、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

4.2.4. サービスアカウントを使用したコンテナーレジストリー認証の設定

パイプラインがレジストリーからコンテナーイメージを取得したり、コンテナーイメージをレジストリーにプッシュしたりするには、そのレジストリーの認証を設定する必要があります。

パイプラインのレジストリー認証を設定するには、Docker 設定ファイルで認証シークレットを作成し、このシークレットをサービスアカウントに関連付け、このサービスアカウントを TaskRun または PipelineRun リソースに関連付けます。

手順

  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

4.2.5. サービスアカウントを使用した認証に関する追加の考慮事項

場合によっては、サービスアカウントを使用して指定する認証シークレットを使用するために追加の手順を実行する必要があります。

4.2.5.1. タスクでの SSH Git 認証

タスクの手順で Git コマンドを直接呼び出し、SSH 認証を使用できますが、追加の手順を完了する必要があります。

OpenShift Pipelines は、/tekton/home/.ssh ディレクトリーの SSH ファイルを提供し、$HOME 変数を /tekton/home に設定します。ただし、Git SSH 認証は $HOME 変数を無視し、ユーザーの /etc/passwd ファイルで指定されたホームディレクトリーを使用します。そのため、Git コマンドを使用する手順では、/tekton/home/.ssh ディレクトリーを、関連付けられたユーザーのホームディレクトリーにシンボリックリンクする必要があります。

たとえば、タスクが root ユーザーとして実行する場合は、Git コマンドの前に次のコマンドを含める必要があります。

apiVersion: tekton.dev/v1
kind: Task
metadata:
  name: example-git-task
spec:
  steps:
    - name: example-git-step
#     ...
      script:
        ln -s $HOME/.ssh /root/.ssh
#     ...

ただし、git タイプのパイプラインリソースまたは Tekton カタログで利用可能な git-clone タスクのパイプラインリソースを使用する場合は、明示的なシンボリックリンクは必要ありません。

git タイプのタスクで SSH 認証を使用する例として、authenticating-git-commands.yaml を参照してください。

4.2.5.2. root 以外のユーザーとしてのシークレットの使用

以下のような特定のシナリオでは、root 以外のユーザーとしてシークレットを使用する必要がある場合があります。

  • コンテナーが実行するために使用するユーザーとグループは、プラットフォームによってランダム化されます。
  • タスクの手順では、root 以外のセキュリティーコンテキストを定義します。
  • タスクは、root 以外のグローバルセキュリティーコンテキストを指定します。これは、タスクのすべての手順に適用されます。

このようなシナリオでは、root 以外のユーザーとしてタスク実行とパイプライン実行を行う際の次の側面を考慮してください。

  • Git の SSH 認証では、ユーザーが /etc/passwd ディレクトリーに有効なホームディレクトリーを設定している必要があります。有効なホームディレクトリーのない UID を指定すると、認証に失敗します。
  • SSH 認証は $HOME 環境変数を無視します。そのため、OpenShift Pipelines によって定義された $HOME ディレクトリー (/tekton/home) から適切なシークレットファイルを非 root ユーザーの有効なホームディレクトリーにシンボリックリンクする必要があります。

さらに、root 以外のセキュリティーコンテキストで SSH 認証を設定するには、git コマンドを認証する 例の git-clone-and-check ステップを参照してください

4.3. ワークスペースを使用したシークレットの提供

ワークスペースを使用して、Git リポジトリーおよびコンテナーリポジトリーでの認証にシークレットを提供できます。

名前付き Workspace を Task に設定し、ワークスペースのマウント先となるパスを指定できます。タスクの実行時に、シークレットをこの名前のワークスペースとして指定します。OpenShift Pipelines がタスクを実行すると、シークレットの情報はタスクで利用可能になります。

ワークスペースを使用して認証シークレットを指定する場合は、シークレットのアノテーションは必要ありません。

4.3.1. ワークスペースを使用した Git の SSH 認証の設定

パイプラインが SSH キーで設定されたリポジトリーからリソースを取得するには、そのパイプラインの SSH ベースの認証を設定する必要があります。

パイプラインの SSH ベースの認証を設定するには、SSH 秘密鍵で認証シークレットを作成し、タスクでこのシークレットの名前付きワークスペースを設定し、タスクの実行時にシークレットを指定します。

手順

  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 認証用に名前付きの workspace を設定します(例: 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
    &lt ;workspace_name&gt; は設定したワークスペースの名前に、< secret_name > は作成したシークレットの名前に置き換えます。

認証に SSH キーを使用して Git リポジトリーのクローンを作成するタスクの例

apiVersion: tekton.dev/v1beta1
kind: Task
metadata:
  name: git-clone
spec:
  workspaces:
    - name: output
      description: The git repo will be cloned onto the volume backing this Workspace.
    - name: ssh-directory
      description: |
        A .ssh directory with private key, known_hosts, config, etc. Copied to
        the user's home before git commands are executed. Used to authenticate
        with the git remote when performing the clone. Binding a Secret to this
        Workspace is strongly recommended over other volume types
  params:
    - name: url
      description: Repository URL to clone from.
      type: string
    - name: revision
      description: Revision to checkout. (branch, tag, sha, ref, etc...)
      type: string
      default: ""
    - name: gitInitImage
      description: The image providing the git-init binary that this Task runs.
      type: string
      default: "gcr.io/tekton-releases/github.com/tektoncd/pipeline/cmd/git-init:v0.37.0"
  results:
    - name: commit
      description: The precise commit SHA that was fetched by this Task.
    - name: url
      description: The precise URL that was fetched by this Task.
  steps:
    - name: clone
      image: "$(params.gitInitImage)"
      script: |
        #!/usr/bin/env sh
        set -eu
        # This is necessary for recent version of git
        git config --global --add safe.directory '*'
        cp -R "$(workspaces.ssh-directory.path)" "${HOME}"/.ssh 1
        chmod 700 "${HOME}"/.ssh
        chmod -R 400 "${HOME}"/.ssh/*
        CHECKOUT_DIR="$(workspaces.output.path)/"
        /ko-app/git-init \
          -url="$(params.url)" \
          -revision="$(params.revision)" \
          -path="${CHECKOUT_DIR}"
        cd "${CHECKOUT_DIR}"
        RESULT_SHA="$(git rev-parse HEAD)"
        EXIT_CODE="$?"
        if [ "${EXIT_CODE}" != 0 ] ; then
          exit "${EXIT_CODE}"
        fi
        printf "%s" "${RESULT_SHA}" > "$(results.commit.path)"
        printf "%s" "$(params.url)" > "$(results.url.path)"

1
スクリプトは、シークレットの内容(フォルダーの形式)を ${HOME}/.ssh にコピーします。これは、ssh が認証情報を検索する標準フォルダーです。

タスクを実行するコマンドの例

$ tkn task start git-clone
      --param url=git@github.com:example-github-user/buildkit-tekton
      --workspace name=output,emptyDir=""
      --workspace name=ssh-directory,secret=my-github-ssh-credentials
      --use-param-defaults --showlog

4.3.2. ワークスペースを使用したコンテナーレジストリー認証の設定

パイプラインがレジストリーからコンテナーイメージを取得するには、そのレジストリーの認証を設定する必要があります。

コンテナーレジストリーの認証を設定するには、Docker 設定ファイルを使用して認証シークレットを作成し、このシークレットの名前付きワークスペースをタスクに設定し、タスクの実行時にシークレットを指定します。

手順

  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 認証用に名前付きの workspace を設定します(例: 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
    &lt ;workspace_name&gt; は設定したワークスペースの名前に、< secret_name > は作成したシークレットの名前に置き換えます。

Skopeo を使用してコンテナーリポジトリーからイメージをコピーするタスクの例

apiVersion: tekton.dev/v1beta1
kind: Task
metadata:
  name: skopeo-copy
spec:
  workspaces:
    - name: dockerconfig 1
      description: Includes a docker `config.json`
  steps:
    - name: clone
      image: quay.io/skopeo/stable:v1.8.0
      env:
      - name: DOCKER_CONFIG
        value: $(workspaces.dockerconfig.path) 2
      script: |
        #!/usr/bin/env sh
        set -eu
        skopeo copy docker://docker.io/library/ubuntu:latest docker://quay.io/example_repository/ubuntu-copy:latest

1
config.json ファイルが含まれるワークスペースの名前。
2
DOCKER_CONFIG 環境変数は、dockerconfig ワークスペースの config.json ファイルの場所を指します。Skopeo はこの環境変数を使用して認証情報を取得します。

タスクを実行するコマンドの例

$ tkn task start skopeo-copy
      --workspace name=dockerconfig,secret=my-registry-credentials
      --use-param-defaults --showlog

4.3.3. ワークスペースを使用した特定のステップへのシークレットの制限

ワークスペースを使用して認証シークレットを指定し、ワークスペースをタスクに定義すると、デフォルトでワークスペースはタスクのすべての手順で使用できます。

シークレットを特定の手順に制限するには、タスク仕様とステップ仕様の両方でワークスペースを定義します。

手順

  • 以下の例のように、Task 仕様とステップ仕様の両方に workspaces: 定義を追加します。

    1 つのステップのみがクレデンシャルワークスペースにアクセスできるタスク定義の例

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

    1
    タスク仕様の ssh-directory ワークスペースの定義。
    2
    ステップ仕様の ssh-directory ワークスペースの定義。認証情報は、この手順で $(workspaces.ssh-directory.path) ディレクトリーとして利用できます。
    3
    この手順には ssh-directory ワークスペースの定義が含まれていないため、この手順では認証情報は利用できません。

第5章 非 root ユーザーとして Buildah を使用したコンテナーイメージのビルド

コンテナーで root ユーザーとして OpenShift Pipelines を実行すると、コンテナープロセスとホストが他の悪意のあるリソースにさらされる可能性があります。コンテナー内の特定の root 以外のユーザーとしてワークロードを実行すると、このタイプの露出を減らすことができます。非 root ユーザーとして Buildah を使用してコンテナーイメージのビルドを実行するには、次の手順を実行します。

  • カスタムサービスアカウント (SA) とセキュリティーコンテキスト制約 (SCC) を定義します。
  • ID が 1000build ユーザーを使用するように Buildah を設定します。
  • カスタム設定マップを使用してタスクの実行を開始するか、パイプラインの実行と統合します。

5.1. カスタムサービスアカウントとセキュリティーコンテキストの制約の設定

デフォルトの pipeline SA では、namespace の範囲外のユーザー ID を使用できます。デフォルト SA への依存を減らすために、ユーザー ID 1000build ユーザーに必要なクラスターロールとロールバインディングを使用して、カスタム SA と SCC を定義できます。

重要

現時点で、Buildah がコンテナー内で正常に実行されるためには、allowPrivilegeEscalation 設定を有効にする必要があります。この設定により、Buildah は非 root ユーザーとして実行するときに SETUID および SETGID 機能を活用できます。

手順

  • 必要なクラスターロールとロールバインディングを使用して、カスタム SA と SCC を作成します。

    例: 使用される ID が 1000 のカスタム SA および SCC

    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: true 3
    allowPrivilegedContainer: false
    allowedCapabilities: null
    apiVersion: security.openshift.io/v1
    defaultAddCapabilities: null
    fsGroup:
      type: MustRunAs
    groups:
    - system:cluster-admins
    priority: 10
    readOnlyRootFilesystem: false
    requiredDropCapabilities:
    - MKNOD
    - KILL
    runAsUser: 4
      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 5
    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 6
    roleRef:
      apiGroup: rbac.authorization.k8s.io
      kind: ClusterRole
      name: pipelines-scc-userid-1000-clusterrole
    subjects:
    - kind: ServiceAccount
      name: pipelines-sa-userid-1000

1
カスタム SA を定義します。
2
runAsUser フィールドを変更して、制限された権限に基づいて作成されたカスタム SCC を定義します。
3
現時点で、Buildah がコンテナー内で正常に実行されるためには、allowPrivilegeEscalation 設定を有効にする必要があります。この設定により、Buildah は非 root ユーザーとして実行するときに SETUID および SETGID 機能を活用できます。
4
カスタム SA を介してカスタム SCC にアタッチされた Pod を、ユーザー ID が 1000 として実行されるように制限します。
5
カスタム SCC を使用するクラスターロールを定義します。
6
カスタム SCC を使用するクラスターロールをカスタム SA にバインドします。

5.2. build ユーザーを使用するための Buildah の設定

ユーザー ID が 1000build ユーザーを使用する Buildah タスクを定義できます。

手順

  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
    必要に応じて、ボリュームマウントのパスを変更できます。

5.3. カスタムの config map を使用したタスク実行またはパイプライン実行の開始

カスタム Buildah クラスタータスクを定義したら、ユーザー ID が 1000build ユーザーとしてイメージをビルドする TaskRun オブジェクトを作成できます。さらに、TaskRun オブジェクトを PipelineRun オブジェクトの一部として統合できます。

手順

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

5.4. 非特権ビルドの制限

非特権ビルドのプロセスは、ほとんどの Dockerfile オブジェクトで機能します。ただし、ビルドが失敗する原因となる既知の制限がいくつかあります。

  • --mount=type=cache オプションの使用は、必要となる権限の問題が原因で失敗する場合があります。詳細は、この記事 を参照してください。
  • --mount=type=secret オプションの使用は失敗します。リソースのマウントには、カスタム SCC によって提供されない追加の機能が必要になるためです。

法律上の通知

Copyright © 2024 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.