Enterprise Contract によるコンプライアンス管理
Enterprise Contract では、プロモートするコードのコンプライアンスをより適切に確認し、管理する方法を学ぶ。また、会社の基準に合わせてサンプルポリシーをカスタマイズする。
概要
はじめに
Enterprise Contract は、コンテナーイメージのビルドとテストに関するポリシーを定義および適用し、ソフトウェアサプライチェーンのセキュリティーを維持するためのポリシー駆動型ワークフローツールです。セキュアな CI/CD ワークフローを実現するには、問題を早期に検出するためのアーティファクト検証を組み込む必要があります。Enterprise Contract の役割は、コンテナーイメージが既知の信頼できるビルドシステムによって署名およびアテストされていることを検証することです。
第1章 Red Hat Trusted Application Pipeline の Enterprise Contract
ソフトウェアサプライチェーンが複雑になるほど、ソフトウェアアーティファクトの整合性とソースコードの信頼性を保証するために、信頼性の高いチェックとベストプラクティスを採用することが重要になります。アーティファクトとは、たとえばイメージコンテナーです。このような背景から、Red Hat Trusted Application Pipeline のビルドおよびデプロイエクスペリエンスに、Red Hat Enterprise Contract が組み込まれました。
Enterprise Contract は、コンテナーイメージのビルドとテストに関するポリシーを定義および適用し、ソフトウェアサプライチェーンのセキュリティーを維持するためのポリシー駆動型ワークフローツールです。Supply-chain Levels for Software Artifacts (SLSA) の来歴アテステーションを作成するビルドシステム (Tekton Chains を使用した Tekton や SLSA GitHub Generator を使用した GitHub Actions など) では、署名をチェックし、アテステーションの内容が実際に期待どおりに一致することを確認することは、ソフトウェアサプライチェーンのインテグリティーを検証および維持する上で非常に重要です。セキュアな CI/CD ワークフローを実現するには、問題を早期に検出するためのアーティファクト検証を組み込む必要があります。Enterprise Contract の役割は、コンテナーイメージが既知の信頼できるビルドシステムによって署名およびアテストされていることを検証することです。
署名およびアテストされたコンテナーイメージを検証するための一般的な手順は次のとおりです。
- Red Hat Trusted Application Pipeline を使用してコンテナーイメージを作成またはコピーします。
- Cosign を使用して署名鍵を生成します。
- Cosign を使用してコンテナーイメージに署名します。
- Cosign を使用してイメージをアテストします。
- Enterprise Contract CLI を使用して、署名およびアテストしたコンテナーイメージを検証します。
しかし、コンテナーイメージのようなソフトウェアアーティファクトに 署名 して その来歴をアテスト するとは、どういうことでしょうか。ここでは、その理由と方法を説明します。
コンテナーイメージなどの署名済みのソフトウェアアーティファクトは、未署名のアーティファクトよりも、いくつかの攻撃ベクトルのリスクが大幅に低くなります。コンテナーイメージが署名されると、さまざまな暗号化技術によってイメージが特定のエンティティーまたは組織にバインドされます。その結果、イメージの信頼性を検証するデジタル署名が作成されるため、イメージの作成者 (エンティティーまたは組織) まで追跡できるようになります。また、署名後にイメージが変更または改ざんされていないことも検証できます。ソフトウェアサプライチェーンの脅威の詳細は、Supply chain threats を参照してください。
Enterprise Contract は、コンテナーイメージを検証するためのリソースライブラリーとして、業界標準の Sigstore Cosign を使用します。Red Hat Trusted Artifact Signer (Red Hat によってサポートされるバージョンの Sigstore フレームワーク) を使用すると、Sigstore サービスの独自のオンプレミスインスタンスを使用して、Cosign CLI でコンテナーイメージに署名およびアテストできます。RHTAS の詳細は、Red Hat Trusted Artifact Signer を参照してください。
ソフトウェアアーティファクトの アテステーション は、来歴がなければ実現できません。来歴 とは、コンテナーイメージなどのソフトウェアアーティファクトに関する検証可能な情報であり、そのアーティファクトがどこで、いつ、どのように作成されたかを説明したものです。アテステーション自体は、メタデータ形式の認証済みステートメントであり、アーティファクトが元のままであり信頼できることを証明するものです。Enterprise Contract は、そのようなアテステーションを使用して、ビルドが改ざんされていないことを暗号的に検証し、SLSA 要件などのポリシーセットに照らしてビルドをチェックします。SLSA の詳細は、About SLSA を参照してください。
ユーザーが RHTAP の開発名前空間からステージ名前空間に、またはステージ名前空間から実稼働名前空間にコードをプッシュすると、Enterprise Contract は検証チェックを自動的に実行し、コンテナーイメージが既知の信頼できるビルドシステムによって署名およびアテストされていることを確認します。イメージが Enterprise Contract チェックに合格すると、コードの変更をマージして、ある環境から次の環境へのプロモートを完了できます。アプリケーションを別の名前空間にデプロイする方法の詳細は、Trusted Application Pipeline Software Template を参照してください。RHTAP がデプロイメントマニフェストを保存する場所の詳細は、RHTAP GitOps リポジトリー とその YAML ファイルを参照してください。
第2章 Enterprise Contract コマンドラインのインストール
前提条件
- バージョン 4.13 以降の Red Hat OpenShift Container Platform 上で動作している Red Hat Trusted Artifact Signer インストール。
-
cosign
およびoc
バイナリーファイルがインストールされたワークステーション。 - OpenShift Web コンソールへのアクセス。
手順
OpenShift クラスターから
ec
バイナリーファイルをダウンロードします。- OpenShift Web コンソールにログインします。ホームページから ? アイコンをクリックし、Command line tools を選択して、ec ダウンロードセクションに移動してから、お使いのプラットフォームへのリンクをクリックします。
ワークステーションでターミナルを開き、バイナリー
.gz
ファイルを展開して、実行ビットを設定します。例
gunzip ec-amd64.gz chmod +x ec-amd64
gunzip ec-amd64.gz chmod +x ec-amd64
Copy to Clipboard Copied!
バイナリーを
$PATH
環境内の場所に移動し、名前を変更します。例
sudo mv ec-amd64 /usr/local/bin/ec
sudo mv ec-amd64 /usr/local/bin/ec
Copy to Clipboard Copied!
検証
-
ec version
コマンドを実行します。実行すると、インストールした Enterprise Contract CLI のバージョンが表示されるはずです。
第3章 ポリシーの作成
Enterprise Contract の ポリシー は、ルールまたはルールセットと、Enterprise Contract 固有のアノテーションです。Enterprise Contract は、いくつかの種類のポリシーチェックを実行できます。これには、Red Hat 製品に必要なポリシールール をすべてチェックすることが含まれます。Enterprise Contract は、Open Policy Agent (OPA) と呼ばれる汎用ポリシーエンジンを使用します。OPA は、Rego と呼ばれる独自の言語でポリシールールを定義します。そのため、Enterprise Contract のポリシーに含まれている OPA のポリシールールも、Rego で定義されています。
手順
次の例のように、新しいポリシールールを定義する Rego ファイルを作成します。
echo 'package zero_to_hero import future.keywords.contains import future.keywords.if import future.keywords.in # METADATA # title: Builder ID # description: Verify the SLSA Provenance has the builder.id set to # the expected value. # custom: # short_name: builder_id # failure_msg: The builder ID %q is not the expected %q # solution: >- # Ensure the correct build system was used to build the container # image. deny contains result if { some attestation in input.attestations attestation.statement.predicateType == "https://slsa.dev/provenance/v0.2" expected := "https://localhost/dummy-id" got := attestation.statement.predicate.builder.id expected != got result := { "code": "zero_to_hero.builder_id", "msg": sprintf("The builder ID %q is not expected, %q", [got, expected]) } } ' > rules.rego
echo 'package zero_to_hero import future.keywords.contains import future.keywords.if import future.keywords.in # METADATA
1 # title: Builder ID # description: Verify the SLSA Provenance has the builder.id set to # the expected value. # custom: # short_name: builder_id
2 # failure_msg: The builder ID %q is not the expected %q # solution: >- # Ensure the correct build system was used to build the container # image. deny contains result if { some attestation in input.attestations
3 attestation.statement.predicateType == "https://slsa.dev/provenance/v0.2" expected := "https://localhost/dummy-id" got := attestation.statement.predicate.builder.id expected != got result := { "code": "zero_to_hero.builder_id", "msg": sprintf("The builder ID %q is not expected, %q", [got, expected]) } } ' > rules.rego
Copy to Clipboard Copied! - 1
METADATA
コメントブロック (先頭にハッシュタグ (#) が付く最初の 10 行のコード) は、rego がルールアノテーションを指定する方法です。これにより、Enterprise Contract はこれらのアノテーションの詳細を成功と違反のレポートに含めることができます。rego のメタデータとアノテーションの詳細は、Metadata を参照してください。Enterprise Contract のポリシールールに含める必要があるアノテーションの詳細は、Rule annotations を参照してください。- 2
- この 1 つのポリシールールは、新しいポリシールールの
builder.id
が、Supply-chain Levels for Software Artifacts (SLSA) の来歴のbuilder.id
と一致することを確認します。 - 3
input.attestations
は、コンテナーイメージ、その署名、およびそのアテステーションに関するすべての情報が含まれる rego オブジェクトです。Enterprise Contract がinput.attestations
の内容をどこでどのように定義するかの詳細は、ポリシー入力 を参照してください。
ヒントinput.attestations
オブジェクトを JSON ファイルに保存すると、新しいポリシールールを指定するときにそのオブジェクトを借用できます。input.attestations
を JSON ファイルとして保存するには、次の例のようなコマンドを実行します。ec validate image --public-key cosign.pub --image "$REPOSITORY:latest" --policy policy.yaml \ --show-successes --info --output yaml
ec validate image --public-key cosign.pub --image "$REPOSITORY:latest" --policy policy.yaml \ --show-successes --info --output yaml
Copy to Clipboard Copied! 次の例のように、新しいポリシールールを使用するポリシー設定を作成します。
echo " --- sources: - policy: - $(pwd)/rules.rego " > policy.yaml
echo " --- sources: - policy: - $(pwd)/rules.rego " > policy.yaml
Copy to Clipboard Copied! 次の例のように、新しいポリシーを使用してコンテナーイメージを検証し、成功と違反のレポートに追加情報を表示します。
ec validate image --public-key cosign.pub --image "$REPOSITORY:latest" --policy policy.yaml \ --show-successes --info --output yaml
ec validate image --public-key cosign.pub --image "$REPOSITORY:latest" --policy policy.yaml \ --show-successes --info --output yaml
Copy to Clipboard Copied!
検証
-
成功と違反のレポートをチェックして、新しいルールが
successes
リストに含まれていることを確認します。
3.1. ポリシーの設定
インライン JSON または YAML 文字列を使用して、Enterprise Contract ポリシーを設定できます。このポリシーは、config または contract とも呼ばれ、実行するポリシーを適用するために使用するルールとデータを Enterprise Contract で検索する場所を指定します。1 つのルールや特定のルールパッケージを追加または除外することもできます。
手順
次の例のように、コマンドラインでポリシーを JSON または YAML 文字列として設定します。
ec validate image --policy '{ "configuration": { "include": ["@minimal"] }, "sources": [ { "policy": ["oci::quay.io/enterprise-contract/ec-release-policy:latest"], "data": ["git::https://github.com/enterprise-contract/ec-policies//example/data"] } ] }' ...
ec validate image --policy '{ "configuration": { "include": ["@minimal"] }, "sources": [ { "policy": ["oci::quay.io/enterprise-contract/ec-release-policy:latest"], "data": ["git::https://github.com/enterprise-contract/ec-policies//example/data"] } ] }' ...
Copy to Clipboard Copied! (オプション) 次の例のように、Enterprise Contract ポリシーから特定のルールパッケージを除外します。
exclude: - attestation_task_bundle - slsa_build_scripted_build
exclude: - attestation_task_bundle - slsa_build_scripted_build
Copy to Clipboard Copied! このコマンドにより、指定したパッケージ内のルールを除く全パッケージの全ルールが追加されます。
(オプション) 次の例のように、1 つのルールを除外します。
exclude: - attestation_task_bundle.unacceptable_task_bundle
exclude: - attestation_task_bundle.unacceptable_task_bundle
Copy to Clipboard Copied! このコマンドにより、
unacceptable_task_bundle
ルールを除くattestation_task_bundle
パッケージのすべてのルールが追加されます。(オプション) 次の例のように、特定のパッケージのルールのみを追加します。
include: - test - java
include: - test - java
Copy to Clipboard Copied! このコマンドにより、指定したパッケージのルールのみが追加されます。
(オプション) 特定パッケージの一部のルールのみを追加します。つまり、次の例のように、
include
とexclude
の両方を指定して、Enterprise Contract ポリシーに追加するルールのみを選択できます。include: - "*" - attestation_task_bundle.unacceptable_task_bundle exclude: - attestation_task_bundle.*
include: - "*"
1 - attestation_task_bundle.unacceptable_task_bundle exclude: - attestation_task_bundle.*
Copy to Clipboard Copied! - 1
- アスタリスク (*) はワイルドカードとして機能し、すべてのパッケージにマッチします。名前の一部にはマッチしないことに注意してください。たとえば、"s*" を指定して、"s" で始まるすべてのパッケージにマッチさせることはできません。
これらのコマンドにより、
attestation_task_bundle
パッケージのunacceptable_task_bundle
ルール のみ を追加し、そのパッケージ内の他のルールをすべて除外することが指定されます。(オプション) 次の例のように、特定のチェックを除外して、そのチェックが失敗した場合や完了しなかった場合でも、Enterprise Contract がコンテナーイメージを検証できるようにします。
exclude: - test:get-clair-scan - test:clamav-scan
exclude: - test:get-clair-scan - test:clamav-scan
Copy to Clipboard Copied! このコマンドによって、特定のチェックのいずれかが失敗した場合や完了しなかった場合でも、Enterprise Contract がコンテナーイメージの検証を完了できるようになります。
(オプション)
config.policy.include
コマンドまたはconfig.policy.exclude
コマンドのいずれかを文字列のリストとともに実行して、パッケージ内のルールのデフォルト設定を変更します。文字列のリストには、次のいずれかを含める必要があります。
- "パッケージ名" - Available rule collections リストからパッケージを選択します。
-
"ルール名" - パッケージ名とルールコードをドット (.) で区切って入力し、ルール名を指定します (例:
attestation_type.unknown_att_type
)。ルールコードは、こちら の「Attestation type」で確認できます。 - "パッケージ名:項目" - ポリシールールの中には、項目のリストを処理するものもあります。"パッケージ名" 文字列に "項目" を付加すると、そのリストから特定の項目を除外または追加できます。これは "パッケージ名" と同様に機能しますが、その項目にマッチするパッケージ内のポリシールールにのみ適用される点が異なります。たとえば、テストパッケージを実行する場合は、特定のテストケースを無視して、他のすべてのテストケースを追加することができます。
- "ルール名:項目" - これは "パッケージ名:項目" と似ていますが、パッケージに 項目 を追加または除外する代わりに、特定のパッケージの ポリシールール を追加または除外できる点が異なります。
-
"@コレクション名" - 定義済みのルールのコレクションを指定するには、これを文字列に追加します。コレクション名の前に必ず
@
記号を付けてください。こちら の利用可能なルールコレクションから選択します。
第4章 コンテナーイメージへの署名
前提条件
- OpenShift Web コンソールへのアクセス。
- バージョン 4.13 以降の OpenShift 上で実行中の動作している Red Hat Trusted Artifact Signer (RHTAS) インストール。
-
ec
、cosign
、oc
バイナリーファイルがインストールされたワークステーション。
手順
OpenShift クラスターにログインします。
構文
oc login --token=TOKEN --server=SERVER_URL_AND_PORT
例
oc login --token=sha256~ZvFDBvoIYAbVECixS4-WmkN4RfnNd8Neh3y1WuiFPXC --server=https://example.com:6443
注記コマンドラインログイントークンと URL を確認するには、OpenShift Web コンソール にログインします。ユーザー名をクリックし、Copy login command をクリックします。プロンプトが表示されたら、ユーザー名とパスワードを再度入力し、Display Token をクリックします。
RHTAS にログインします。コンテナーイメージに署名して検証するには、RHTAS シェル環境を必ず設定してください。以下に例を示します。
cd sigstore-ocp source tas-env-variables.sh
cd sigstore-ocp source tas-env-variables.sh
Copy to Clipboard Copied! 環境変数を手動で設定する方法もあります。以下に例を示します。
export OPENSHIFT_APPS_SUBDOMAIN=apps.$(oc get dns cluster -o jsonpath='{ .spec.baseDomain }') export OIDC_AUTHENTICATION_REALM=sigstore export FULCIO_URL=https://fulcio.$OPENSHIFT_APPS_SUBDOMAIN export OIDC_ISSUER_URL=https://keycloak-keycloak-system.$OPENSHIFT_APPS_SUBDOMAIN/auth/realms/$OIDC_AUTHENTICATION_REALM export REKOR_URL=https://rekor.$OPENSHIFT_APPS_SUBDOMAIN export TUF_URL=https://tuf.$OPENSHIFT_APPS_SUBDOMAIN
export OPENSHIFT_APPS_SUBDOMAIN=apps.$(oc get dns cluster -o jsonpath='{ .spec.baseDomain }') export OIDC_AUTHENTICATION_REALM=sigstore export FULCIO_URL=https://fulcio.$OPENSHIFT_APPS_SUBDOMAIN export OIDC_ISSUER_URL=https://keycloak-keycloak-system.$OPENSHIFT_APPS_SUBDOMAIN/auth/realms/$OIDC_AUTHENTICATION_REALM export REKOR_URL=https://rekor.$OPENSHIFT_APPS_SUBDOMAIN export TUF_URL=https://tuf.$OPENSHIFT_APPS_SUBDOMAIN
Copy to Clipboard Copied! 例
source ./tas-env-vars.sh
$ source ./tas-env-vars.sh
Copy to Clipboard Copied! -
oc logout
コマンドを実行して、OpenShift クラスターからログアウトします。 -
署名およびアテストするコンテナーイメージを特定します (例:
IMAGE=quay.io/lucarval/rhtas-test@sha256:6b95efc134c2af3d45472c0a2f88e6085433df058cc210abb2bb061ac4d74359
)。 -
パブリックの Sigstore デプロイメントではなく、Red Hat Trusted Artifact Signer を使用してコンテナーイメージに署名およびアテストすることを RHTAP に指定します。
cosign initialize --mirror=$TUF_URL --root=$TUF_URL/root.json
コマンドを入力します。 次のコマンドを使用してコンテナーイメージに署名します。
cosign sign -y --fulcio-url=$FULCIO_URL --rekor-url=$REKOR_URL \ --oidc-issuer=$OIDC_ISSUER_URL $IMAGE
cosign sign -y --fulcio-url=$FULCIO_URL --rekor-url=$REKOR_URL \ --oidc-issuer=$OIDC_ISSUER_URL $IMAGE
Copy to Clipboard Copied! - プロンプトが表示されたら、RHTAS をインストールしたときに RHTAP によってインストールされた Keycloak インスタンスにログインします。これは、Keycloak がユーザーを認証できるようにするためです。
次のステップ
これでイメージが署名されました。これで、以下が可能になります。
- SLSA の来歴アテステーションを作成し、コンテナーイメージに関連付けます。
- Red Hat Enterprise Contract でコンテナーイメージを検証します。
4.1. コンテナーイメージに署名してアテストするための署名鍵の生成
コンテナーイメージに署名してアテストするには、署名鍵が必要です。
前提条件
-
cosign
バイナリーファイルがインストールされたワークステーション。
手順
-
CLI で、
cosign generate-key-pair
コマンドを実行します。 - プロンプトが表示されたら、キーペアの新しいパスワードを入力します。パスワードは覚えやすく強力なものにしてください。
検証
これで、作業ディレクトリーに
cosign.pub
とcosign.key
という 2 つの新しいファイルが作成されます。-
cosign.pub
ファイルには、公開署名鍵が含まれています。この鍵は、コンテナーイメージの検証が必要なコラボレーターと共有できます。 -
cosign.key
ファイルは、コンテンツに署名するための秘密鍵です。イメージの署名およびアテステーションの責任者だけがcosign.key
ファイルにアクセスできるようにしてください。
-
4.2. Enterprise Contract と Red Hat Trusted Artifact Signer によるコンテナーイメージ署名の検証
Red Hat Trusted Artifact Signer (RHTAS) サービスをインストールすると、ec
バイナリーファイルを使用して、RHTAS サービスのキーレス署名フレームワークを使用するコンテナーイメージのアテステーションと署名を検証できます。RHTAS のインストールの詳細は、Operator Lifecycle Manager を使用した Red Hat Trusted Artifact Signer のインストール を参照してください。
前提条件
- バージョン 4.13 以降の OpenShift 上で実行中の動作している RHTAS インストール。
- OpenShift Web コンソールへのアクセス。
-
cosign
およびoc
バイナリーファイルがインストールされたワークステーション。
手順
OpenShift クラスターから
ec
バイナリーファイルをダウンロードします。- OpenShift Web コンソール にログインします。ホームページから、右上の ? アイコンをクリックし、Command Line Tools を選択します。
- ec download セクションから、プラットフォームのリンクをクリックします。
ターミナルを開き、
.gz
ファイルを展開し、ec
バイナリーファイルに実行ビットを設定します。Linux および macOS の例
-
$ gunzip ec-amd64.gz
-
$ chmod +x ec-amd64
-
ec
バイナリーファイルを$PATH
環境内のディレクトリーに移動します。例
$ sudo mv ec-amd64 /usr/local/bin/ec
他のイメージ検証コマンドオプションをすべて確認するには、ec validate image --help
コマンドを実行します。
コンテナーイメージの署名および検証用にシェル環境を設定します。
ターミナルを開き、
sigstore-ocp
ディレクトリーからtas-env-variables.sh
スクリプトを実行します。例
cd sigstore-ocp source tas-env-variables.sh
cd sigstore-ocp source tas-env-variables.sh
Copy to Clipboard Copied! (オプション) 環境変数を手動で設定します。
例
export OPENSHIFT_APPS_SUBDOMAIN=apps.$(oc get dns cluster -o jsonpath='{ .spec.baseDomain }') export OIDC_AUTHENTICATION_REALM=sigstore export FULCIO_URL=https://fulcio.$OPENSHIFT_APPS_SUBDOMAIN export OIDC_ISSUER_URL=https://keycloak-keycloak-system.$OPENSHIFT_APPS_SUBDOMAIN/auth/realms/$OIDC_AUTHENTICATION_REALM export REKOR_URL=https://rekor.$OPENSHIFT_APPS_SUBDOMAIN export TUF_URL=https://tuf.$OPENSHIFT_APPS_SUBDOMAIN
export OPENSHIFT_APPS_SUBDOMAIN=apps.$(oc get dns cluster -o jsonpath='{ .spec.baseDomain }') export OIDC_AUTHENTICATION_REALM=sigstore export FULCIO_URL=https://fulcio.$OPENSHIFT_APPS_SUBDOMAIN export OIDC_ISSUER_URL=https://keycloak-keycloak-system.$OPENSHIFT_APPS_SUBDOMAIN/auth/realms/$OIDC_AUTHENTICATION_REALM export REKOR_URL=https://rekor.$OPENSHIFT_APPS_SUBDOMAIN export TUF_URL=https://tuf.$OPENSHIFT_APPS_SUBDOMAIN
Copy to Clipboard Copied! 例
$ source ./tas-env-vars.sh
Update Framework (TUF) システムを初期化します。
例
cosign initialize --mirror=$TUF_URL --root=$TUF_URL/root.json
コンテナーイメージに署名します。
構文
cosign sign -y --fulcio-url=$FULCIO_URL --rekor-url=$REKOR_URL --oidc-issuer=$OIDC_ISSUER_URL IMAGE_NAME
例
cosign sign -y --fulcio-url=$FULCIO_URL --rekor-url=$REKOR_URL --oidc-issuer=$OIDC_ISSUER_URL example-hello-world@sha256:2788a47fd0ef1ece30898c1e608050ea71036d3329b9772dbb3d1f69313f745c
表示される Web ブラウザーで、メールアドレスを使用してコンテナーイメージに署名します。
predicate.json
ファイルを作成します。例
{ "builder": { "id": "https://localhost/dummy-id" }, "buildType": "https://example.com/tekton-pipeline", "invocation": {}, "buildConfig": {}, "metadata": { "completeness": { "parameters": false, "environment": false, "materials": false }, "reproducible": false }, "materials": [] }
{ "builder": { "id": "https://localhost/dummy-id" }, "buildType": "https://example.com/tekton-pipeline", "invocation": {}, "buildConfig": {}, "metadata": { "completeness": { "parameters": false, "environment": false, "materials": false }, "reproducible": false }, "materials": [] }
Copy to Clipboard Copied! predicate.json
ファイルをコンテナーイメージに関連付けます。構文
cosign attest -y --predicate ./predicate.json \ --type slsaprovenance IMAGE_NAME:TAG
cosign attest -y --predicate ./predicate.json \ --type slsaprovenance IMAGE_NAME:TAG
Copy to Clipboard Copied! 例
cosign attest -y --predicate ./predicate.json \ --type slsaprovenance example.io/hello-world:latest
$ cosign attest -y --predicate ./predicate.json \ --type slsaprovenance example.io/hello-world:latest
Copy to Clipboard Copied! コンテナーイメージにアテステーションと署名が 1 つ以上含まれていることを確認します。
構文
cosign tree IMAGE_NAME:TAG
例
cosign tree example.io/hello-world:latest
$ cosign tree example.io/hello-world:latest 📦 Supply Chain Security Related artifacts for an image: example.io/hello-world@sha256:7de5fa822a9d1e507c36565ee0cf50c08faa64505461c844a3ce3944d23efa35 └── 💾 Attestations for an image tag: example.io/hello-world:sha256-7de5fa822a9d1e507c36565ee0cf50c08faa64505461c844a3ce3944d23efa35.att └── 🍒 sha256:40d94d96a6d3ab3d94b429881e1b470ae9a3cac55a3ec874051bdecd9da06c2e └── 🔐 Signatures for an image tag: example.io/hello-world:sha256-7de5fa822a9d1e507c36565ee0cf50c08faa64505461c844a3ce3944d23efa35.sig └── 🍒 sha256:f32171250715d4538aec33adc40fac2343f5092631d4fc2457e2116a489387b7
Copy to Clipboard Copied! Enterprise Contract でコンテナーイメージを検証します。
構文
ec validate image --image IMAGE_NAME:TAG \ --certificate-identity-regexp 'SIGNER_EMAIL_ADDR' \ --certificate-oidc-issuer-regexp 'keycloak-keycloak-system' \ --output yaml --show-successes
ec validate image --image IMAGE_NAME:TAG \ --certificate-identity-regexp 'SIGNER_EMAIL_ADDR' \ --certificate-oidc-issuer-regexp 'keycloak-keycloak-system' \ --output yaml --show-successes
Copy to Clipboard Copied! 例
ec validate image --image example.io/hello-world:latest \ --certificate-identity 'jdoe@example.com' \ --certificate-oidc-issuer 'keycloak-keycloak-system' \ --output yaml --show-successes
$ ec validate image --image example.io/hello-world:latest \ --certificate-identity 'jdoe@example.com' \ --certificate-oidc-issuer 'keycloak-keycloak-system' \ --output yaml --show-successes success: true successes: - metadata: code: builtin.attestation.signature_check msg: Pass - metadata: code: builtin.attestation.syntax_check msg: Pass - metadata: code: builtin.image.signature_check msg: Pass ec-version: v0.1.2427-499ef12 effective-time: "2024-01-21T19:57:51.338191Z" key: "" policy: {} success: true
Copy to Clipboard Copied! Enterprise Contract は、セキュリティー違反の詳細を含む合格/不合格レポートを生成します。
--info
フラグを追加すると、違反に関する詳細と考えられる解決策がレポートに追加されます。
第5章 コンテナーイメージのアテストと検証
Enterprise Contract によって署名済みコンテナーイメージを検証する前に、まず SLSA 来歴を作成し、それをコンテナーイメージに関連付ける必要があります。来歴とは、サプライチェーン内の特定のソフトウェア "リンク" がどこで、いつ、どのように作成されたかなど、ソフトウェアアーティファクトに関する検証可能な情報です。Supply-chain Levels for Software Artifacts (SLSA) の来歴の詳細は、SLSA Provenance を参照してください。
前提条件
- 署名済みのコンテナーイメージ。
- OpenShift Web コンソールへのアクセス。
- バージョン 4.13 以降の OpenShift 上で実行中の動作している Red Hat Trusted Artifact Signer インストール。
-
cosign
およびoc
バイナリーファイルがインストールされたワークステーション。
手順
SLSA 来歴ファイル
predicate.json
を作成します。以下に例を示します。echo '{ "builder": { "id": "https://localhost/dummy-id" }, "buildType": "https://localhost/dummy-type", "invocation": {}, "buildConfig": {}, "metadata": { "buildStartedOn": "2023-09-25T16:26:44Z", "buildFinishedOn": "2023-09-25T16:28:59Z", "completeness": { "parameters": false, "environment": false, "materials": false }, "reproducible": false }, "materials": [] } ' > predicate.json
echo '{ "builder": { "id": "https://localhost/dummy-id" }, "buildType": "https://localhost/dummy-type", "invocation": {}, "buildConfig": {}, "metadata": { "buildStartedOn": "2023-09-25T16:26:44Z", "buildFinishedOn": "2023-09-25T16:28:59Z", "completeness": { "parameters": false, "environment": false, "materials": false }, "reproducible": false }, "materials": [] } ' > predicate.json
Copy to Clipboard Copied! 作成した
predicate.json
ファイルに署名してアテストします。以下に例を示します。cosign attest -y --fulcio-url=$FULCIO_URL \ --rekor-url=$REKOR_URL \ --oidc-issuer=$OIDC_ISSUER_URL \ --predicate predicate.json \ --type slsaprovenance $IMAGE
cosign attest -y --fulcio-url=$FULCIO_URL \ --rekor-url=$REKOR_URL \ --oidc-issuer=$OIDC_ISSUER_URL \ --predicate predicate.json \ --type slsaprovenance $IMAGE
Copy to Clipboard Copied! Keycloak が開き、コンテナーイメージに署名したときのログインに基づいて自動的に認証されます。
Enterprise Contract を使用して署名とアテステーションを検証します。以下に例を示します。
ec validate image --image $IMAGE \ --certificate-identity-regexp '.*' \ --certificate-oidc-issuer-regexp '.*' \ --output yaml --show-successes
ec validate image --image $IMAGE \ --certificate-identity-regexp '.*' \ --certificate-oidc-issuer-regexp '.*' \ --output yaml --show-successes
Copy to Clipboard Copied!
ec validity image
コマンドを実行するときは、各署名が期待される identity
と一致するように、できるだけ詳細に指定してください。
検証
- Enterprise Contract によってコンテナーイメージが検証され、Enterprise Contract のすべての検証と署名に関する詳細なレポートが開きます。
5.1. JSON および YAML 定義の検証
ソフトウェアサプライチェーンを保護するさまざまな選択肢を検討する際に、タスクまたはパイプラインの定義にポリシーを適用することを選択する場合があります。たとえば、Enterprise Contract を使用して、特定のパイプラインでどのタスクが実行されるかを確認する必要があるかもしれません。一部のパイプラインタスクを必須にしたり、特定のタスクのみの実行を許可したり、タスクやパイプラインを実行する前に適用するその他の規則を設定したりすることもあるでしょう。
前提条件
-
Enterprise Contract CLI がインストールされている。インストールの手順は、Enterprise Contract CLI のインストール ガイドを参照してください。必要なファイルは
ec-cli
GitHub リポジトリー にあります。
手順
Enterprise Contract の JSON または YAML 定義が有効であることを検証するには、次の手順を実行します。
-
Enterprise Contract CLI で、
ec validate input
コマンドを入力します。