OpenShift Pipelines の保護
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. 主な特長 リンクのコピーリンクがクリップボードにコピーされました!
-
cosignやskopeoなどのツールで生成された暗号キーを使用して、タスク実行、タスク実行結果、OCI レジストリーイメージに署名できます。 -
in-totoなどの認証形式を使用できます。 - OCI リポジトリーをストレージバックエンドとして使用して、署名と署名されたアーティファクトを安全に保存できます。
1.2. Tekton Chains の設定 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat OpenShift Pipelines Operator は、デフォルトで Tekton Chains をインストールします。TektonConfig カスタムリソースを変更することで、Tekton Chains を設定できます。Operator は、このカスタムリソースに加えた変更を自動的に適用します。
カスタムリソースを編集するには、次のコマンドを使用します。
oc edit TektonConfig config
$ oc edit TektonConfig config
カスタムリソースには、chain: 配列が含まれます。次の例に示すように、サポートされている設定パラメーターをこの配列に追加できます。
1.2.1. Tekton Chains 設定でサポートされているパラメーター リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、サポートされているさまざまなパラメーターのキーと値を使用して、タスクの実行、OCI イメージ、およびストレージに関する仕様を設定できます。
1.2.1.1. タスク実行アーティファクトでサポートされているパラメーター リンクのコピーリンクがクリップボードにコピーされました!
| キー | 説明 | サポート対象の値 | デフォルト値 |
|---|---|---|---|
|
| タスク実行ペイロードを保存するための形式。 |
|
|
|
|
タスク実行署名のストレージバックエンド。 |
|
|
|
| タスク実行ペイロードに署名するための署名バックエンド。 |
|
|
slsa/v1 は、下位互換性のための in-toto のエイリアスです。
1.2.1.2. パイプライン実行アーティファクトでサポートされているパラメーター リンクのコピーリンクがクリップボードにコピーされました!
| パラメーター | 説明 | サポート対象の値 | デフォルト値 |
|---|---|---|---|
|
| パイプライン実行ペイロードを保存する形式。 |
|
|
|
|
パイプライン実行署名を保存するためのストレージバックエンド。 |
|
|
|
| パイプライン実行ペイロードに署名するための署名バックエンド。 |
|
|
-
slsa/v1は、下位互換性のためのin-totoのエイリアスです。 -
Grafeasストレージバックエンドの場合、Container Analysis のみがサポートされます。Tekton Chains の現在のバージョンでは、grafeasサーバーアドレスを設定できません。
1.2.1.3. OCI アーティファクトでサポートされているパラメーター リンクのコピーリンクがクリップボードにコピーされました!
| パラメーター | 説明 | サポート対象の値 | デフォルト値 |
|---|---|---|---|
|
| OCI ペイロードを保存するための形式。 |
|
|
|
|
OCI 署名を保存するためのストレージバックエンド。 |
|
|
|
| OCI ペイロードに署名するための署名バックエンド。 |
|
|
1.2.1.4. KMS 署名者でサポートされているパラメーター リンクのコピーリンクがクリップボードにコピーされました!
| パラメーター | 説明 | サポート対象の値 | デフォルト値 |
|---|---|---|---|
|
|
|
サポートされているスキーム: |
1.2.1.5. ストレージでサポートされているパラメーター リンクのコピーリンクがクリップボードにコピーされました!
| パラメーター | 説明 | サポート対象の値 | デフォルト値 |
|---|---|---|---|
|
| ストレージ用の GCS バケット | ||
|
| OCI 署名と証明書を保存するための OCI リポジトリー。 |
アーティファクトストレージバックエンドの 1 つを | |
|
| in-toto 証明書に設定するビルダー ID |
|
任意のアーティファクトに対して docdb ストレージ方法を有効にする場合は、docstore ストレージオプションを設定します。go-cloud docstore URI 形式の詳細は、docstore パッケージのドキュメント を参照してください。Red Hat OpenShift Pipelines は、次の docstore サービスをサポートしています。
-
firestore - DynamoDB
| パラメーター | 説明 | サポート対象の値 | デフォルト値 |
|---|---|---|---|
|
|
|
|
アーティファクトに対して 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> を使用します。
| パラメーター | 説明 | サポート対象の値 | デフォルト値 |
|---|---|---|---|
|
| オカレンスを保存する Grafeas サーバーが配置されている OpenShift Container Platform プロジェクト。 | ||
|
| オプション: 作成されたすべてのメモの名前に使用する接頭辞。 | スペースなしの文字列。 | |
|
|
オプション: Grafeas |
|
オプションで、バイナリー透明性証明書の追加アップロードを有効にできます。
| パラメーター | 説明 | サポート対象の値 | デフォルト値 |
|---|---|---|---|
|
| 自動バイナリー透明性アップロードを有効または無効にします。 |
|
|
|
| バイナリー透明性証明書をアップロードするための URL (有効な場合)。 |
|
Transparency.enabled を manual に設定すると、次のアノテーションが付いたタスク実行とパイプライン実行のみが透過性ログにアップロードされます。
chains.tekton.dev/transparency-upload: "true"
chains.tekton.dev/transparency-upload: "true"
x509 署名バックエンドを設定する場合、オプションで Fulcio を使用したキーレス署名を有効にできます。
| パラメーター | 説明 | サポート対象の値 | デフォルト値 |
|---|---|---|---|
|
| Fulcio からの自動証明書の要求を有効または無効にします。 |
|
|
|
| 証明書を要求するための Fulcio アドレス (有効な場合)。 |
| |
|
| 予想される OIDC 発行者。 |
| |
|
| ID トークンを要求するプロバイダー。 |
| Red Hat OpenShift Pipelines はすべてのプロバイダーの使用を試みます |
|
| ID トークンを含むファイルへのパス。 | ||
|
|
TUF サーバーの URL。 |
|
kms 署名バックエンドを設定する場合は、必要に応じて OIDC や Spire を含む KMS 設定を行います。
| パラメーター | 説明 | サポート対象の値 | デフォルト値 |
|---|---|---|---|
|
|
KMS サーバーの URI ( | ||
|
|
KMS サーバーの認証トークン ( | ||
|
|
OIDC 認証のパス (Vault の場合は | ||
|
| OIDC 認証のロール。 | ||
|
|
KMS トークンの Spire ソケットの URI (例: | ||
|
| 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 ツールをインストールしている。
手順
次のコマンドを実行して、
cosign.keyとcosign.pubキーのペアを生成します。cosign generate-key-pair k8s://openshift-pipelines/signing-secrets
$ cosign generate-key-pair k8s://openshift-pipelines/signing-secretsCopy to Clipboard Copied! Toggle word wrap Toggle overflow Cosign はパスワードの入力を求め、Kubernetes シークレットを作成します。
-
暗号化された
cosign.key秘密鍵とcosign.password復号化パスワードを、signing-secretsKubernetes シークレットに保存します。秘密鍵がENCRYPTED COSIGN PRIVATE KEY型の暗号化された PEM ファイルとして保存されていることを確認します。
1.3.2. skopeo を使用した署名 リンクのコピーリンクがクリップボードにコピーされました!
skopeo ツールを使用して鍵を生成し、Tekton Chains で cosign 署名スキームで使用できます。
前提条件
- skopeo ツールをインストールしている。
手順
次のコマンドを実行して、公開鍵と秘密鍵のペアを生成します。
skopeo generate-sigstore-key --output-prefix <mykey>
$ skopeo generate-sigstore-key --output-prefix <mykey>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<mykey>を選択した鍵名に置き換えます。
Skopeo は秘密鍵のパスフレーズの入力を求め、
<mykey>.privateおよび<mykey>.pubという名前の鍵ファイルを作成します。次のコマンドを実行し、
base64ツールを使用して<mykey>.pubファイルをエンコードします。base64 -w 0 <mykey>.pub > b64.pub
$ base64 -w 0 <mykey>.pub > b64.pubCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行し、
base64ツールを使用して<mykey>.privateファイルをエンコードします。base64 -w 0 <mykey>.private > b64.private
$ base64 -w 0 <mykey>.private > b64.privateCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行し、
base64ツールを使用してパスフレーズをエンコードします。echo -n '<passphrase>' | base64 -w 0 > b64.passphrase
$ echo -n '<passphrase>' | base64 -w 0 > b64.passphrase1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<passphrase>を鍵ペアに使用したパスフレーズに置き換えます。
次のコマンドを実行して、
openshift-pipelinesnamespace にsigned-secretsシークレットを作成します。oc create secret generic signing-secrets -n openshift-pipelines
$ oc create secret generic signing-secrets -n openshift-pipelinesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行して
signing-secretsシークレットを編集します。oc edit secret -n openshift-pipelines signing-secrets
$ oc edit secret -n openshift-pipelines signing-secretsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次の方法で、エンコードされた鍵をシークレットのデータに追加します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
1.3.3. "secret already exists" エラーの解決 リンクのコピーリンクがクリップボードにコピーされました!
signed-secret シークレットがすでに入力されている場合、このシークレットを作成するコマンドは次のエラーメッセージを出力する可能性があります。
Error from server (AlreadyExists): secrets "signing-secrets" already exists
Error from server (AlreadyExists): secrets "signing-secrets" already exists
このエラーは、シークレットを削除することで解決できます。
手順
次のコマンドを実行して、
signing-secretシークレットを削除します。oc delete secret signing-secrets -n openshift-pipelines
$ oc delete secret signing-secrets -n openshift-pipelinesCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 鍵ペアを再作成し、任意の署名スキームを使用してシークレットに保存します。
1.4. OCI レジストリーへの認証 リンクのコピーリンクがクリップボードにコピーされました!
署名を OCI レジストリーにプッシュする前に、クラスター管理者は、レジストリーで認証するように Tekton Chains を設定する必要があります。Tekton Chains コントローラーは、タスクの実行と同じサービスアカウントを使用します。署名を OCI レジストリーにプッシュするために必要な認証情報を使用してサービスアカウントを設定するには、次の手順を実行します。
手順
Kubernetes サービスアカウントの namespace と名前を設定します。
export NAMESPACE=<namespace> export SERVICE_ACCOUNT_NAME=<service_account>
$ export NAMESPACE=<namespace>1 $ export SERVICE_ACCOUNT_NAME=<service_account>2 Copy to Clipboard Copied! Toggle word wrap Toggle overflow Kubernetes シークレットを作成します。
oc create secret registry-credentials \ --from-file=.dockerconfigjson \ --type=kubernetes.io/dockerconfigjson \ -n $NAMESPACE
$ oc create secret registry-credentials \ --from-file=.dockerconfigjson \1 --type=kubernetes.io/dockerconfigjson \ -n $NAMESPACECopy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Docker 設定ファイルへのパスに置き換えます。デフォルトのパスは
~/.docker/config.jsonです。
サービスアカウントにシークレットへのアクセス権限を付与します。
oc patch serviceaccount $SERVICE_ACCOUNT_NAME \ -p "{\"imagePullSecrets\": [{\"name\": \"registry-credentials\"}]}" -n $NAMESPACE$ oc patch serviceaccount $SERVICE_ACCOUNT_NAME \ -p "{\"imagePullSecrets\": [{\"name\": \"registry-credentials\"}]}" -n $NAMESPACECopy to Clipboard Copied! Toggle word wrap Toggle overflow Red Hat OpenShift Pipelines がすべてのタスク実行に割り当てるデフォルトの
pipelineサービスアカウントにパッチを適用すると、Red Hat OpenShift Pipelines Operator はサービスアカウントをオーバーライドします。ベストプラクティスとして、次の手順を実行できます。ユーザーのタスク実行に割り当てる別のサービスアカウントを作成します。
oc create serviceaccount <service_account_name>
$ oc create serviceaccount <service_account_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow タスク実行テンプレートの
serviceaccountnameフィールドの値を設定して、サービスアカウントをタスク実行に関連付けます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 新しく作成したサービスアカウントの名前に置き換えます。
1.5. 追加認証なしでタスク実行の署名を作成および検証する リンクのコピーリンクがクリップボードにコピーされました!
追加認証を使用して Tekton Chains でタスク実行の署名を検証するには、次のタスクを実行します。
- 暗号化された x509 キーペアを作成し、Kubernetes シークレットとして保存します。
- Tekton Chains バックエンドストレージを設定します。
- タスク実行を作成して署名し、署名とペイロードをタスク実行自体にアノテーションとして保存します。
- 署名されたタスクの実行から署名とペイロードを取得します。
- タスク実行の署名を確認します。
前提条件
次のコンポーネントがクラスターにインストールされていることを確認する。
- Red Hat OpenShift Pipelines Operator
- Tekton Chains
- Cosign
手順
- 暗号化された x509 キーペアを作成し、Kubernetes シークレットとして保存します。鍵ペアの作成とシークレットとしての保存の詳細については、「Tekton Chains でのシークレットの署名」を参照してください。
Tekton Chains 設定で、OCI ストレージを無効にし、タスク実行ストレージとフォーマットを
tektonに設定します。TektonConfigカスタムリソースで次の値を設定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow TektonConfigカスタムリソースを使用した Tekton チェーンの設定の詳細は、「Tekton チェーンの設定」を参照してください。Tekton Chains コントローラーを再起動して、変更した設定が確実に適用されるようにするには、次のコマンドを入力します。
oc delete po -n openshift-pipelines -l app=tekton-chains-controller
$ oc delete po -n openshift-pipelines -l app=tekton-chains-controllerCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを入力してタスク実行を作成します。
oc create -f https://raw.githubusercontent.com/tektoncd/chains/main/examples/taskruns/task-output-image.yaml
$ oc create -f https://raw.githubusercontent.com/tektoncd/chains/main/examples/taskruns/task-output-image.yaml1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- サンプル URI を、タスクの実行を指す URI またはファイルパスに置き換えます。
出力例
taskrun.tekton.dev/build-push-run-output-image-qbjvh created
taskrun.tekton.dev/build-push-run-output-image-qbjvh createdCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを入力して、ステップのステータスを確認します。プロセスが完了するまで待ちます。
tkn tr describe --last
$ tkn tr describe --lastCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Base64でエンコードされたアノテーションとして保存されたオブジェクトから署名を取得するには、次のコマンドを入力します。tkn tr describe --last -o jsonpath="{.metadata.annotations.chains\.tekton\.dev/signature-taskrun-$TASKRUN_UID}" | base64 -d > sig$ tkn tr describe --last -o jsonpath="{.metadata.annotations.chains\.tekton\.dev/signature-taskrun-$TASKRUN_UID}" | base64 -d > sigCopy to Clipboard Copied! Toggle word wrap Toggle overflow export TASKRUN_UID=$(tkn tr describe --last -o jsonpath='{.metadata.uid}')$ export TASKRUN_UID=$(tkn tr describe --last -o jsonpath='{.metadata.uid}')Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 作成した公開鍵を使用して署名を検証するには、次のコマンドを入力します。
cosign verify-blob-attestation --insecure-ignore-tlog --key path/to/cosign.pub --signature sig --type slsaprovenance --check-claims=false /dev/null
$ cosign verify-blob-attestation --insecure-ignore-tlog --key path/to/cosign.pub --signature sig --type slsaprovenance --check-claims=false /dev/null
- 1
path/to/cosign.pubを公開鍵ファイルのパス名に置き換えます。出力例
Verified OK
Verified OKCopy to Clipboard Copied! Toggle word wrap Toggle overflow
1.5.1. 関連情報 リンクのコピーリンクがクリップボードにコピーされました!
1.6. Tekton Chains を使用したイメージと取得元の署名および検証 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、Tekton Chains を使用して、以下のタスクを実行することで、イメージと証明書を署名および検証できます。
- 暗号化された x509 鍵ペアを作成し、Kubernetes シークレットとして保存します。
- OCI レジストリーの認証を設定して、イメージ、イメージ署名、および署名されたイメージ証明書を保存します。
- Tekton Chains を設定して、証明書を生成し署名します。
- タスク実行で Kaniko を使用してイメージを作成します。
- 署名されたイメージと署名された証明書を検証する。
前提条件
以下がクラスターにインストールされていることを確認します。
手順
暗号化された x509 鍵ペアを作成し、Kubernetes シークレットとして保存します。
cosign generate-key-pair k8s://openshift-pipelines/signing-secrets
$ cosign generate-key-pair k8s://openshift-pipelines/signing-secretsCopy to Clipboard Copied! Toggle word wrap Toggle overflow プロンプトが表示されたらパスワードを入力します。Cosign は、結果の秘密鍵を
signing-secretsKubernetes シークレットの一部としてopenshift-pipelinesnamespace に保存し、公開鍵をcosign.pubローカルファイルに書き込みます。イメージレジストリーの認証を設定します。
- 署名を OCI レジストリーにプッシュするように Tekton Chains コントローラーを設定するには、タスク実行のサービスアカウントに関連付けられた認証情報を使用します。詳細については、OCI レジストリーへの認証を参照してください。
イメージをビルドしてレジストリーにプッシュする Kaniko タスクの認証を設定するには、必要な認証情報を含む docker
config.jsonファイルの Kubernetes シークレットを作成します。oc create secret generic <docker_config_secret_name> \ --from-file <path_to_config.json>
$ oc create secret generic <docker_config_secret_name> \1 --from-file <path_to_config.json>2 Copy to Clipboard Copied! Toggle word wrap Toggle overflow
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"}}'$ 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 Copied! Toggle word wrap Toggle overflow Kaniko タスクを開始します。
Kaniko タスクをクラスターに適用します。
oc apply -f examples/kaniko/kaniko.yaml
$ oc apply -f examples/kaniko/kaniko.yaml1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Kaniko タスクへの URI またはファイルパスに置き換えます。
適切な環境変数を設定します。
export REGISTRY=<url_of_registry> export DOCKERCONFIG_SECRET_NAME=<name_of_the_secret_in_docker_config_json>
$ export REGISTRY=<url_of_registry>1 $ export DOCKERCONFIG_SECRET_NAME=<name_of_the_secret_in_docker_config_json>2 Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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
$ tkn task start --param IMAGE=$REGISTRY/kaniko-chains --use-param-defaults --workspace name=source,emptyDir="" --workspace name=dockerconfig,secret=$DOCKERCONFIG_SECRET_NAME kaniko-chainsCopy to Clipboard Copied! Toggle word wrap Toggle overflow すべての手順が完了するまで、このタスクのログを確認してください。認証が成功すると、最終的なイメージが
$REGISTRY/kaniko-chainsにプッシュされます。
Tekton Chains が証明書を生成して署名するまで 1 分ほど待ち、タスク実行時に
chains.tekton.dev/signed=trueアノテーションが利用可能か確認します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- タスク実行の名前に置き換えます。
イメージとアテステーションを確認します。
cosign verify --key cosign.pub $REGISTRY/kaniko-chains cosign verify-attestation --key cosign.pub $REGISTRY/kaniko-chains
$ cosign verify --key cosign.pub $REGISTRY/kaniko-chains $ cosign verify-attestation --key cosign.pub $REGISTRY/kaniko-chainsCopy to Clipboard Copied! Toggle word wrap Toggle overflow Rekor でイメージの証明書を見つけます。
- $ REGISTRY/kaniko-chains イメージのダイジェストを取得します。タスクの実行中に検索するか、イメージをプルしてダイジェストをデプロイメントできます。
Rekor を検索して、イメージの
sha256ダイジェストに一致するすべてのエントリーを見つけます。rekor-cli search --sha <image_digest> <uuid_1> <uuid_2> ...
$ rekor-cli search --sha <image_digest>1 <uuid_1>2 <uuid_2>3 ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow 検索結果には、一致するエントリーの UUID が表示されます。それらの UUID の 1 つが証明書を保持します。
アテステーションを確認してください。
rekor-cli get --uuid <uuid> --format json | jq -r .Attestation | base64 --decode | jq
$ rekor-cli get --uuid <uuid> --format json | jq -r .Attestation | base64 --decode | jqCopy to Clipboard Copied! Toggle word wrap Toggle overflow
第2章 特権付きセキュリティーコンテキストでの Pod の使用 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Pipelines 1.3.x 以降のバージョンのデフォルト設定では、パイプライン実行またはタスク実行から Pod が作成される場合、特権付きセキュリティーコンテキストで Pod を実行できません。このような Pod の場合、デフォルトのサービスアカウントは pipeline であり、pipelines サービスアカウントに関連付けられた SCC (Security Context Constraint) は pipelines-scc になります。pipelines-scc SCC は anyuid SCC と似ていますが、パイプラインの SCC に関する YAML ファイルに定義されるように若干の違いがあります。
pipelines-scc.yaml スニペットの例
さらに、OpenShift Pipeline の一部として提供される Buildah クラスタータスクは、デフォルトのストレージドライバーとして vfs を使用します。
2.1. 特権付きセキュリティーコンテキストを使用したパイプライン実行 Pod およびタスク実行 Pod の実行 リンクのコピーリンクがクリップボードにコピーされました!
手順
privileged セキュリティーコンテキストで (パイプライン実行またはタスク実行で作成された) Pod を実行するには、以下の変更を行います。
関連するユーザーアカウントまたはサービスアカウントを、明示的な SCC を持つように設定します。以下の方法のいずれかを使用して設定を実行できます。
以下のコマンドを実行します。
oc adm policy add-scc-to-user <scc-name> -z <service-account-name>
$ oc adm policy add-scc-to-user <scc-name> -z <service-account-name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow もしくは、
RoleBindingおよび、RoleまたはClusterRoleの YAML ファイルを変更します。RoleBindingオブジェクトの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow ClusterRoleオブジェクトの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 使用するロールバインディングに基づいて適切なクラスターロールに置き換えます。
注記ベストプラクティスとして、デフォルトの YAML ファイルのコピーを作成し、その複製ファイルに変更を加えます。
-
vfsストレージドライバーを使用しない場合、タスク実行またはパイプライン実行に関連付けられたサービスアカウントを特権付き SCC を持つように設定し、セキュリティーコンテキストをprivileged: trueに設定します。
2.2. カスタム SCC およびカスタムサービスアカウントを使用したパイプライン実行とタスク実行 リンクのコピーリンクがクリップボードにコピーされました!
デフォルトの pipelines サービスアカウントに関連付けられた pipelines-scc SCC (Security Context Constraints) を使用する場合、パイプライン実行およびタスク実行 Pod にタイムアウトが生じる可能性があります。これは、デフォルトの pipelines-scc SCC で fsGroup.type パラメーターが MustRunAs に設定されているために発生します。
Pod タイムアウトの詳細は、BZ#1995779 を参照してください。
Pod タイムアウトを回避するには、fsGroup.type パラメーターを RunAsAny に設定してカスタム SCC を作成し、これをカスタムサービスアカウントに関連付けることができます。
ベストプラクティスとして、パイプライン実行とタスク実行にカスタム SCC およびカスタムサービスアカウントを使用します。このアプローチを使用することで、柔軟性が増し、アップグレード時にデフォルト値が変更されても実行が失敗することはありません。
手順
fsGroup.typeパラメーターをRunAsAnyに設定してカスタム SCC を定義します。例: カスタム SCC
Copy to Clipboard Copied! Toggle word wrap Toggle overflow カスタム SCC を作成します。
例:
my-sccSCC の作成oc create -f my-scc.yaml
$ oc create -f my-scc.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow カスタムサービスアカウントを作成します。
例:
fsgroup-runasanyサービスアカウントの作成oc create serviceaccount fsgroup-runasany
$ oc create serviceaccount fsgroup-runasanyCopy to Clipboard Copied! Toggle word wrap Toggle overflow カスタム SCC をカスタムサービスアカウントに関連付けます。
例:
my-sccSCC をfsgroup-runasanyサービスアカウントに関連付けます。oc adm policy add-scc-to-user my-scc -z fsgroup-runasany
$ oc adm policy add-scc-to-user my-scc -z fsgroup-runasanyCopy to Clipboard Copied! Toggle word wrap Toggle overflow 特権付きタスクにカスタムサービスアカウントを使用する必要がある場合は、以下のコマンドを実行して
privilegedSCC をカスタムサービスアカウントに関連付けることができます。例:
fsgroup-runasanyサービスアカウントを使用したprivilegedSCC の関連付けoc adm policy add-scc-to-user privileged -z fsgroup-runasany
$ oc adm policy add-scc-to-user privileged -z fsgroup-runasanyCopy to Clipboard Copied! Toggle word wrap Toggle overflow パイプライン実行およびタスク実行でカスタムサービスアカウントを使用します。
例:
fsgroup-runasanyカスタムサービスアカウントを使用した Pipeline 実行 YAMLCopy to Clipboard Copied! Toggle word wrap Toggle overflow 例:
fsgroup-runasanyカスタムサービスアカウントを使用したタスク実行 YAMLCopy to Clipboard Copied! Toggle word wrap Toggle overflow
第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>
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>
$ oc create route reencrypt --service=<svc-name> --cert=tls.crt --key=tls.key --ca-cert=ca.crt --hostname=<hostname>
または、再暗号化 TLS 終端 YAML ファイルを作成して、セキュアなルートを作成できます。
セキュアなルートを作成する再暗号化 TLS 終端 YAML の例
- 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 リソースのサンプルの作成について説明します。
手順
pipelines-tutorial リポジトリーで利用可能な YAML ファイルから
TriggerBindingリソースを作成します。oc create -f https://raw.githubusercontent.com/openshift/pipelines-tutorial/master/03_triggers/01_binding.yaml
$ oc create -f https://raw.githubusercontent.com/openshift/pipelines-tutorial/master/03_triggers/01_binding.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow pipelines-tutorial リポジトリーで利用可能な YAML ファイルから
TriggerTemplateリソースを作成します。oc create -f https://raw.githubusercontent.com/openshift/pipelines-tutorial/master/03_triggers/02_template.yaml
$ oc create -f https://raw.githubusercontent.com/openshift/pipelines-tutorial/master/03_triggers/02_template.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow Triggerリソースを pipelines-tutorial リポジトリーから直接作成します。oc create -f https://raw.githubusercontent.com/openshift/pipelines-tutorial/master/03_triggers/03_trigger.yaml
$ oc create -f https://raw.githubusercontent.com/openshift/pipelines-tutorial/master/03_triggers/03_trigger.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow セキュアな HTTPS 接続を使用して
EventListenerリソースの作成します。ラベルを追加して、
Eventlistenerリソースへのセキュアな HTTPS 接続を有効にします。oc label namespace <ns-name> operator.tekton.dev/enable-annotation=enabled
$ oc label namespace <ns-name> operator.tekton.dev/enable-annotation=enabledCopy to Clipboard Copied! Toggle word wrap Toggle overflow pipelines-tutorial リポジトリーで利用可能な YAML ファイルから
EventListenerリソースを作成します。oc create -f https://raw.githubusercontent.com/openshift/pipelines-tutorial/master/03_triggers/04_event_listener.yaml
$ oc create -f https://raw.githubusercontent.com/openshift/pipelines-tutorial/master/03_triggers/04_event_listener.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 再暗号化 TLS 終端でルートを作成します。
oc create route reencrypt --service=<svc-name> --cert=tls.crt --key=tls.key --ca-cert=ca.crt --hostname=<hostname>
$ oc create route reencrypt --service=<svc-name> --cert=tls.crt --key=tls.key --ca-cert=ca.crt --hostname=<hostname>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
第4章 シークレットを使用したリポジトリーでのパイプラインの認証 リンクのコピーリンクがクリップボードにコピーされました!
パイプラインとタスクでは、Git リポジトリーとコンテナーリポジトリーで認証するために認証情報が必要になる場合があります。Red Hat OpenShift Pipelines では、シークレットを使用して、実行中に Git リポジトリーまたはコンテナーリポジトリーと対話するパイプライン実行およびタスク実行を認証できます。
Git リポジトリーでの認証用のシークレットは Git シークレット と呼ばれます。
パイプライン実行またはタスク実行は、関連付けられたサービスアカウントを介してシークレットにアクセスできます。あるいは、パイプラインまたはタスクでワークスペースを定義し、そのワークスペースにシークレットをバインドすることもできます。
4.1. 前提条件 リンクのコピーリンクがクリップボードにコピーされました!
-
ocOpenShift コマンドラインユーティリティーがインストールされている。
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 Pipelines がシークレット内の認証情報を使用する必要があるホストの URL に指定します。
次の例では、OpenShift Pipelines は basic-auth シークレットを使用して github.com および gitlab.com のリポジトリーにアクセスします。
例: 複数の Git リポジトリーでの Basic 認証の認証情報
次の例のように、ssh-auth シークレットを使用して Git リポジトリーにアクセスするための秘密鍵を指定することもできます。
例: SSH ベースの認証の秘密鍵
- 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 Pipelines がシークレット内の認証情報を使用する必要があるホストの URL に指定します。このアノテーションは、他のタイプのコンテナーレジストリーシークレットには必要ありません。
次の例では、OpenShift Pipelines はユーザー名とパスワードに依存する basic-auth シークレットを使用して、quay.io および my-registry.example.com のコンテナーレジストリーにアクセスします。
例: 複数のコンテナーリポジトリーでの Basic 認証の認証情報
次の例のように、既存の設定ファイルから 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 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> \ --docker-username=<username> \ --docker-password=<password> \ --docker-server=my-registry.example.com:5000
$ oc create secret docker-registry docker-secret-config \
--docker-email=<email> \
--docker-username=<username> \
--docker-password=<password> \
--docker-server=my-registry.example.com:5000
4.2.2. サービスアカウントを使用した Git の Basic 認証の設定 リンクのコピーリンクがクリップボードにコピーされました!
パスワードで保護されたリポジトリーからリソースを取得するパイプラインの場合は、そのパイプラインの Basic 認証を設定できます。
Basic 認証ではなく SSH ベースの認証を使用することを検討してください。
パイプラインの Basic 認証を設定するには、Basic 認証シークレットを作成し、このシークレットをサービスアカウントに関連付け、このサービスアカウントを TaskRun または PipelineRun リソースに関連付けます。
GitHub では、プレーンパスワードを使用した認証は非推奨になりました。代わりに、 Personal Access Token を使用します。
手順
secret.yamlファイルにシークレットの YAML マニフェストを作成します。このマニフェストでは、対象の Git リポジトリーにアクセスするためのユーザー名とパスワード、または GitHub Personal Access Token を指定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow サービスアカウントの YAML マニフェストを
serviceaccount.yamlファイルに作成します。このマニフェストで、シークレットをサービスアカウントに関連付けます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow run.yamlファイルにタスク実行またはパイプライン実行の YAML マニフェストを作成し、サービスアカウントをタスク実行またはパイプライン実行に関連付けます。次のいずれかの例を使用します。サービスアカウントを
TaskRunリソースに関連付けます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow サービスアカウントを
PipelineRunリソースに関連付けます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
次のコマンドを入力して、作成した YAML マニフェストを適用します。
oc apply --filename secret.yaml,serviceaccount.yaml,run.yaml
$ oc apply --filename secret.yaml,serviceaccount.yaml,run.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
4.2.3. サービスアカウントを使用した Git の SSH 認証の設定 リンクのコピーリンクがクリップボードにコピーされました!
パイプラインが SSH キーで設定されたリポジトリーからリソースを取得するには、そのパイプラインの SSH ベースの認証を設定する必要があります。
パイプラインの SSH ベースの認証を設定するには、SSH 秘密鍵を使用して認証シークレットを作成し、このシークレットをサービスアカウントに関連付け、このサービスアカウントを TaskRun または PipelineRun リソースに関連付けます。
手順
-
SSH 秘密鍵 を生成するか、既存の秘密鍵をコピーします。これは通常
~/.ssh/id_rsaファイルで入手できます。 secret.yamlファイルにシークレットの YAML マニフェストを作成します。このマニフェストでは、ssh-privatekeyの値を SSH 秘密鍵ファイルの内容に、known_hostsの値を既知のホストファイルの内容に設定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 重要既知のホストファイルを省略すると、OpenShift Pipelines は任意のサーバーの公開鍵を受け入れます。
-
オプション: アノテーション値の末尾に
:<port_number>を追加して、カスタム SSH ポートを指定します。たとえば、tekton.dev/git-0: github.com:2222などです。 サービスアカウントの YAML マニフェストを
serviceaccount.yamlファイルに作成します。このマニフェストで、シークレットをサービスアカウントに関連付けます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow run.yamlファイルで、サービスアカウントをタスク実行またはパイプライン実行に関連付けます。次のいずれかの例を使用します。サービスアカウントをタスク実行に関連付けます。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow サービスアカウントをパイプライン実行に関連付けます。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
変更を適用します。
oc apply --filename secret.yaml,serviceaccount.yaml,run.yaml
$ oc apply --filename secret.yaml,serviceaccount.yaml,run.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
4.2.4. サービスアカウントを使用したコンテナーレジストリー認証の設定 リンクのコピーリンクがクリップボードにコピーされました!
パイプラインがレジストリーからコンテナーイメージを取得したり、コンテナーイメージをレジストリーにプッシュしたりするには、そのレジストリーの認証を設定する必要があります。
パイプラインのレジストリー認証を設定するには、Docker 設定ファイルを使用して認証シークレットを作成し、このシークレットをサービスアカウントに関連付け、このサービスアカウントを TaskRun または PipelineRun リソースに関連付けます。
手順
次のコマンドを入力して、認証情報を含めて、既存の
config.jsonファイルからコンテナーレジストリー認証シークレットを作成します。oc create secret generic my-registry-credentials \ --from-file=config.json=/home/user/credentials/config.json
$ oc create secret generic my-registry-credentials \1 --from-file=config.json=/home/user/credentials/config.json2 Copy to Clipboard Copied! Toggle word wrap Toggle overflow サービスアカウントの YAML マニフェストを
serviceaccount.yamlファイルに作成します。このマニフェストで、シークレットをサービスアカウントに関連付けます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow タスク実行またはパイプライン実行の YAML マニフェストを
run.yamlファイルとして作成します。このファイルで、サービスアカウントをタスク実行またはパイプライン実行に関連付けます。次のいずれかの例を使用します。サービスアカウントをタスク実行に関連付けます。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow サービスアカウントをパイプライン実行に関連付けます。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
次のコマンドを入力して変更を適用します。
oc apply --filename serviceaccount.yaml,run.yaml
$ oc apply --filename serviceaccount.yaml,run.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
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 コマンドの前に次のコマンドが含まれている必要があります。
ただし、git タイプのパイプラインリソースまたは Tekton カタログで使用可能な git-clone タスクを使用する場合は、明示的なシンボリックリンクは必要ありません。
git タイプのタスクで SSH 認証を使用する例として、authenticating-git-commands.yaml を参照してください。
4.2.5.2. ルート以外のユーザーとしてのシークレットの使用 リンクのコピーリンクがクリップボードにコピーされました!
以下のような特定のシナリオでは、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 秘密鍵を使用して認証シークレットを作成し、タスクでこのシークレットの名前付きワークスペースを設定し、タスクの実行時にシークレットを指定します。
手順
次のコマンドを入力して、既存の
.sshディレクトリー内のファイルから Git SSH 認証シークレットを作成します。oc create secret generic my-github-ssh-credentials \ --from-file=id_ed25519=/home/user/.ssh/id_ed25519 \ --from-file=known_hosts=/home/user/.ssh/known_hosts
$ 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_hosts3 Copy to Clipboard Copied! Toggle word wrap Toggle overflow タスク定義で、Git 認証用の名前付きワークスペース (例:
ssh-directory)を設定します。ワークスペースの定義例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
タスクの手順では、
$(workspaces.<workspace_name>.path)環境変数のパスを使用してディレクトリーにアクセスします (例:$(workspaces.ssh-directory.path))。 タスクを実行するときは、
tkn task startコマンドに--workspace引数を含めて、名前付きワークスペースのシークレットを指定します。tkn task start <task_name> --workspace name=<workspace_name>,secret=<secret_name> # ...$ tkn task start <task_name> --workspace name=<workspace_name>,secret=<secret_name>1 # ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<workspace_name>は、設定したワークスペースの名前に、<secret_name>は、作成したシークレットの名前に置き換えます。
認証に SSH 鍵を使用して Git リポジトリーをクローンするタスクの例
- 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
$ 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 設定ファイルを使用して認証シークレットを作成し、タスクでこのシークレットの名前付きワークスペースを設定し、タスクの実行時にシークレットを指定します。
手順
次のコマンドを入力して、認証情報を含めて、既存の
config.jsonファイルからコンテナーレジストリー認証シークレットを作成します。oc create secret generic my-registry-credentials \ --from-file=config.json=/home/user/credentials/config.json
$ oc create secret generic my-registry-credentials \1 --from-file=config.json=/home/user/credentials/config.json2 Copy to Clipboard Copied! Toggle word wrap Toggle overflow タスク定義で、Git 認証用の名前付きワークスペース (例:
ssh-directory)を設定します。ワークスペースの定義例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
タスクの手順では、
$(workspaces.<workspace_name>.path)環境変数のパス (例:$(workspaces.dockerconfig.path))を使用してディレクトリーにアクセスします。 タスクを実行するには、
tkn task startコマンドに--workspace引数を含めて、名前付きワークスペースのシークレットを指定します。tkn task start <task_name> --workspace name=<workspace_name>,secret=<secret_name> # ...$ tkn task start <task_name> --workspace name=<workspace_name>,secret=<secret_name>1 # ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<workspace_name>は、設定したワークスペースの名前に、<secret_name>は、作成したシークレットの名前に置き換えます。
Skopeo を使用してコンテナーリポジトリーからイメージをコピーするタスクの例
タスクを実行するためのコマンドの例
tkn task start skopeo-copy
--workspace name=dockerconfig,secret=my-registry-credentials
--use-param-defaults --showlog
$ tkn task start skopeo-copy
--workspace name=dockerconfig,secret=my-registry-credentials
--use-param-defaults --showlog
4.3.3. ワークスペースを使用してシークレットを特定のステップのみに限定する手順 リンクのコピーリンクがクリップボードにコピーされました!
ワークスペースを使用して認証シークレットを提供し、タスクでワークスペースを定義すると、デフォルトでは、そのワークスペースはタスク内のすべてのステップで使用できるようになります。
シークレットを特定のステップに制限するには、タスク仕様とステップ仕様の両方でワークスペースを定義します。
手順
次の例のように、タスク仕様とステップ仕様の両方の下に、
workspaces:定義を追加します。1 つのステップのみが認証情報ワークスペースにアクセスできるタスク定義の例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
第5章 非 root ユーザーとして Buildah を使用したコンテナーイメージのビルド リンクのコピーリンクがクリップボードにコピーされました!
コンテナーで root ユーザーとして OpenShift Pipelines を実行すると、コンテナープロセスとホストが他の悪意のあるリソースにさらされる可能性があります。コンテナー内の特定の root 以外のユーザーとしてワークロードを実行すると、このタイプの露出を減らすことができます。非 root ユーザーとして Buildah を使用してコンテナーイメージのビルドを実行するには、次の手順を実行します。
- カスタムサービスアカウント (SA) とセキュリティーコンテキスト制約 (SCC) を定義します。
-
ID が
1000のbuildユーザーを使用するように Buildah を設定します。 - カスタム設定マップを使用してタスクの実行を開始するか、パイプラインの実行と統合します。
5.1. カスタムサービスアカウントとセキュリティーコンテキストの制約の設定 リンクのコピーリンクがクリップボードにコピーされました!
デフォルトの pipeline SA では、namespace の範囲外のユーザー ID を使用できます。デフォルト SA への依存を減らすために、ユーザー ID 1000 の build ユーザーに必要なクラスターロールとロールバインディングを使用して、カスタム SA と SCC を定義できます。
現時点で、Buildah がコンテナー内で正常に実行されるためには、allowPrivilegeEscalation 設定を有効にする必要があります。この設定により、Buildah は非 root ユーザーとして実行するときに SETUID および SETGID 機能を活用できます。
手順
必要なクラスターロールとロールバインディングを使用して、カスタム SA と SCC を作成します。
例: 使用される ID が
1000のカスタム SA および SCCCopy to Clipboard Copied! Toggle word wrap Toggle overflow
- 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 が 1000 の build ユーザーを使用する Buildah タスクを定義できます。
手順
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 -
$ 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 Copied! Toggle word wrap Toggle overflow コピーした
buildahタスクを編集します。oc edit task buildah-as-user
$ oc edit task buildah-as-userCopy to Clipboard Copied! Toggle word wrap Toggle overflow 例:
buildユーザーで変更された Buildah タスクCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.3. カスタムの config map を使用したタスク実行またはパイプライン実行の開始 リンクのコピーリンクがクリップボードにコピーされました!
カスタム Buildah クラスタータスクを定義したら、ユーザー ID が 1000 の build ユーザーとしてイメージをビルドする TaskRun オブジェクトを作成できます。さらに、TaskRun オブジェクトを PipelineRun オブジェクトの一部として統合できます。
手順
カスタム
ConfigMapおよびDockerfileオブジェクトを使用してTaskRunオブジェクトを作成します。例: Buildah をユーザー ID
1000として実行するタスク実行Copy to Clipboard Copied! Toggle word wrap Toggle overflow (オプション) パイプラインと対応するパイプライン実行を作成します。
例: パイプラインと対応するパイプラインの実行
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - タスクの実行またはパイプラインの実行を開始します。
5.4. 非特権ビルドの制限 リンクのコピーリンクがクリップボードにコピーされました!
非特権ビルドのプロセスは、ほとんどの Dockerfile オブジェクトで機能します。ただし、ビルドが失敗する原因となる既知の制限がいくつかあります。
-
--mount=type=cacheオプションの使用は、必要となる権限の問題が原因で失敗する場合があります。詳細は、この記事 を参照してください。 -
--mount=type=secretオプションの使用は失敗します。リソースのマウントには、カスタム SCC によって提供されない追加の機能が必要になるためです。