Enterprise Contract によるコンプライアンス管理


Red Hat Trusted Application Pipeline 1.0

Enterprise Contract では、プロモートするコードのコンプライアンスをより適切に確認し、管理する方法を学ぶ。また、会社の基準に合わせてサンプルポリシーをカスタマイズする。

Red Hat Customer Content Services

概要

このドキュメントでは、コンテナーイメージの構築とテストに関するポリシーを定義および適用することで、ソフトウェアサプライチェーンのセキュリティーを管理および維持する方法を説明します。

はじめに

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 の役割は、コンテナーイメージが既知の信頼できるビルドシステムによって署名およびアテストされていることを検証することです。

署名およびアテストされたコンテナーイメージを検証するための一般的な手順は次のとおりです。

  1. Red Hat Trusted Application Pipeline を使用してコンテナーイメージを作成またはコピーします。
  2. Cosign を使用して署名鍵を生成します。
  3. Cosign を使用してコンテナーイメージに署名します。
  4. Cosign を使用してイメージをアテストします。
  5. 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 コンソールへのアクセス。

手順

  1. OpenShift クラスターから ec バイナリーファイルをダウンロードします。

    1. OpenShift Web コンソールにログインします。ホームページから ? アイコンをクリックし、Command line tools を選択して、ec ダウンロードセクションに移動してから、お使いのプラットフォームへのリンクをクリックします。
    2. ワークステーションでターミナルを開き、バイナリー .gz ファイルを展開して、実行ビットを設定します。

      gunzip ec-amd64.gz
      chmod +x ec-amd64
      Copy to Clipboard

  2. バイナリーを $PATH 環境内の場所に移動し、名前を変更します。

    sudo mv ec-amd64 /usr/local/bin/ec
    Copy to Clipboard

検証

  • 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 で定義されています。

手順

  1. 次の例のように、新しいポリシールールを定義する 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
    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
    Copy to Clipboard
  2. 次の例のように、新しいポリシールールを使用するポリシー設定を作成します。

    echo "
    ---
    sources:
      - policy:
          - $(pwd)/rules.rego
    " > policy.yaml
    Copy to Clipboard
  3. 次の例のように、新しいポリシーを使用してコンテナーイメージを検証し、成功と違反のレポートに追加情報を表示します。

    ec validate image --public-key cosign.pub --image "$REPOSITORY:latest" --policy policy.yaml \
        --show-successes --info --output yaml
    Copy to Clipboard

検証

  • 成功と違反のレポートをチェックして、新しいルールが successes リストに含まれていることを確認します。

3.1. ポリシーの設定

インライン JSON または YAML 文字列を使用して、Enterprise Contract ポリシーを設定できます。このポリシーは、config または contract とも呼ばれ、実行するポリシーを適用するために使用するルールとデータを Enterprise Contract で検索する場所を指定します。1 つのルールや特定のルールパッケージを追加または除外することもできます。

手順

  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"]
            }
        ]
    }' ...
    Copy to Clipboard
  2. (オプション) 次の例のように、Enterprise Contract ポリシーから特定のルールパッケージを除外します。

    exclude:
    - attestation_task_bundle
    - slsa_build_scripted_build
    Copy to Clipboard

    このコマンドにより、指定したパッケージ内のルールを除く全パッケージの全ルールが追加されます。

  3. (オプション) 次の例のように、1 つのルールを除外します。

    exclude:
    - attestation_task_bundle.unacceptable_task_bundle
    Copy to Clipboard

    このコマンドにより、unacceptable_task_bundle ルールを除く attestation_task_bundle パッケージのすべてのルールが追加されます。

  4. (オプション) 次の例のように、特定のパッケージのルールのみを追加します。

    include:
    - test
    - java
    Copy to Clipboard

    このコマンドにより、指定したパッケージのルールのみが追加されます。

  5. (オプション) 特定パッケージの一部のルールのみを追加します。つまり、次の例のように、includeexclude の両方を指定して、Enterprise Contract ポリシーに追加するルールのみを選択できます。

    include:
    - "*" 
    1
    
    - attestation_task_bundle.unacceptable_task_bundle
    exclude:
    - attestation_task_bundle.*
    Copy to Clipboard
    1
    アスタリスク (*) はワイルドカードとして機能し、すべてのパッケージにマッチします。名前の一部にはマッチしないことに注意してください。たとえば、"s*" を指定して、"s" で始まるすべてのパッケージにマッチさせることはできません。

    これらのコマンドにより、attestation_task_bundle パッケージの unacceptable_task_bundle ルール のみ を追加し、そのパッケージ内の他のルールをすべて除外することが指定されます。

  6. (オプション) 次の例のように、特定のチェックを除外して、そのチェックが失敗した場合や完了しなかった場合でも、Enterprise Contract がコンテナーイメージを検証できるようにします。

    exclude:
    - test:get-clair-scan
    - test:clamav-scan
    Copy to Clipboard

    このコマンドによって、特定のチェックのいずれかが失敗した場合や完了しなかった場合でも、Enterprise Contract がコンテナーイメージの検証を完了できるようになります。

  7. (オプション) 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) インストール。
  • eccosignoc バイナリーファイルがインストールされたワークステーション。

手順

  1. 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 をクリックします。

  2. RHTAS にログインします。コンテナーイメージに署名して検証するには、RHTAS シェル環境を必ず設定してください。以下に例を示します。

    cd sigstore-ocp
    source tas-env-variables.sh
    Copy to Clipboard

    環境変数を手動で設定する方法もあります。以下に例を示します。

    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

    $ source ./tas-env-vars.sh
    Copy to Clipboard

  3. oc logout コマンドを実行して、OpenShift クラスターからログアウトします。
  4. 署名およびアテストするコンテナーイメージを特定します (例: IMAGE=quay.io/lucarval/rhtas-test@sha256:6b95efc134c2af3d45472c0a2f88e6085433df058cc210abb2bb061ac4d74359)。
  5. パブリックの Sigstore デプロイメントではなく、Red Hat Trusted Artifact Signer を使用してコンテナーイメージに署名およびアテストすることを RHTAP に指定します。cosign initialize --mirror=$TUF_URL --root=$TUF_URL/root.json コマンドを入力します。
  6. 次のコマンドを使用してコンテナーイメージに署名します。

    cosign sign -y --fulcio-url=$FULCIO_URL --rekor-url=$REKOR_URL \
         --oidc-issuer=$OIDC_ISSUER_URL $IMAGE
    Copy to Clipboard
  7. プロンプトが表示されたら、RHTAS をインストールしたときに RHTAP によってインストールされた Keycloak インスタンスにログインします。これは、Keycloak がユーザーを認証できるようにするためです。

次のステップ

これでイメージが署名されました。これで、以下が可能になります。

  1. SLSA の来歴アテステーションを作成し、コンテナーイメージに関連付けます。
  2. Red Hat Enterprise Contract でコンテナーイメージを検証します。

4.1. コンテナーイメージに署名してアテストするための署名鍵の生成

コンテナーイメージに署名してアテストするには、署名鍵が必要です。

前提条件

  • cosign バイナリーファイルがインストールされたワークステーション。

手順

  1. CLI で、cosign generate-key-pair コマンドを実行します。
  2. プロンプトが表示されたら、キーペアの新しいパスワードを入力します。パスワードは覚えやすく強力なものにしてください。

検証

  • これで、作業ディレクトリーに cosign.pubcosign.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 バイナリーファイルがインストールされたワークステーション。

手順

  1. OpenShift クラスターから ec バイナリーファイルをダウンロードします。

    1. OpenShift Web コンソール にログインします。ホームページから、右上の ? アイコンをクリックし、Command Line Tools を選択します。
    2. ec download セクションから、プラットフォームのリンクをクリックします。
    3. ターミナルを開き、.gz ファイルを展開し、ec バイナリーファイルに実行ビットを設定します。

      Linux および macOS の例

      • $ gunzip ec-amd64.gz
      • $ chmod +x ec-amd64
    4. ec バイナリーファイルを $PATH 環境内のディレクトリーに移動します。

      $ sudo mv ec-amd64 /usr/local/bin/ec

ヒント

他のイメージ検証コマンドオプションをすべて確認するには、ec validate image --help コマンドを実行します。

  1. コンテナーイメージの署名および検証用にシェル環境を設定します。

    1. ターミナルを開き、sigstore-ocp ディレクトリーから tas-env-variables.sh スクリプトを実行します。

      cd sigstore-ocp
      source tas-env-variables.sh
      Copy to Clipboard

    2. (オプション) 環境変数を手動で設定します。

      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

      $ source ./tas-env-vars.sh

  2. Update Framework (TUF) システムを初期化します。

    cosign initialize --mirror=$TUF_URL --root=$TUF_URL/root.json

  3. コンテナーイメージに署名します。

    構文

    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 ブラウザーで、メールアドレスを使用してコンテナーイメージに署名します。

  4. 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": []
    }
    Copy to Clipboard

  5. predicate.json ファイルをコンテナーイメージに関連付けます。

    構文

    cosign attest -y --predicate ./predicate.json \
    --type slsaprovenance IMAGE_NAME:TAG
    Copy to Clipboard

    $ cosign attest -y --predicate ./predicate.json \
    --type slsaprovenance example.io/hello-world:latest
    Copy to Clipboard

  6. コンテナーイメージにアテステーションと署名が 1 つ以上含まれていることを確認します。

    構文

    cosign tree IMAGE_NAME:TAG

    $ 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

  7. 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
    Copy to Clipboard

    $ 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

    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 バイナリーファイルがインストールされたワークステーション。

手順

  1. 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
    Copy to Clipboard
  2. 作成した predicate.json ファイルに署名してアテストします。以下に例を示します。

    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

    Keycloak が開き、コンテナーイメージに署名したときのログインに基づいて自動的に認証されます。

  3. Enterprise Contract を使用して署名とアテステーションを検証します。以下に例を示します。

    ec validate image --image $IMAGE \
       --certificate-identity-regexp '.*' \
       --certificate-oidc-issuer-regexp '.*' \
       --output yaml --show-successes
    Copy to Clipboard
重要

ec validity image コマンドを実行するときは、各署名が期待される identity と一致するように、できるだけ詳細に指定してください。

検証

  • Enterprise Contract によってコンテナーイメージが検証され、Enterprise Contract のすべての検証と署名に関する詳細なレポートが開きます。

5.1. JSON および YAML 定義の検証

ソフトウェアサプライチェーンを保護するさまざまな選択肢を検討する際に、タスクまたはパイプラインの定義にポリシーを適用することを選択する場合があります。たとえば、Enterprise Contract を使用して、特定のパイプラインでどのタスクが実行されるかを確認する必要があるかもしれません。一部のパイプラインタスクを必須にしたり、特定のタスクのみの実行を許可したり、タスクやパイプラインを実行する前に適用するその他の規則を設定したりすることもあるでしょう。

前提条件

手順

Enterprise Contract の JSON または YAML 定義が有効であることを検証するには、次の手順を実行します。

  • Enterprise Contract CLI で、ec validate input コマンドを入力します。

法律上の通知

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

Theme

© 2025 Red Hat