Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

Red Hat Advanced Developer Suite - software supply chain のスタートガイド

Red Hat Advanced Developer Suite - software supply chain 1.6

Red Hat Advanced Developer Suite - software supply chain を使い始める方法を説明します。

Red Hat Advanced Developer Suite - software supply chain Documentation Team

概要

このドキュメントでは、すぐに使用できるソフトウェアテンプレートの使用方法を説明します。このテンプレートは、署名、アテステーション、ソフトウェア部品表 (SBOM)、SLSA 検証、CVE スキャン、リリースポリシーガードレールなどの安全なサプライチェーン機能が組み込まれたアプリケーションを構築するためのものです。

はじめに
リンクのコピー

RHADS - SSC を使用すると、従来のセキュリティー対策を超えた取り組みを開始し、最先端のソリューションと DevSecOps CI/CD フレームワークを、最初からデプロイまでの各段階に統合できます。このようなプロアクティブな戦略により、開発者のオンボーディング、プロセスの加速、および初期段階からのセキュリティーの組み込みを加速します。

第1章 開発ワークフロー
リンクのコピー

開発ワークフローには、アプリケーションの作成、更新、保護、およびデプロイが含まれます。また、柔軟性を高めるために、さまざまなリポジトリー、コンテナーレジストリー、CI/CD ツールとの統合も可能になります。

Expand
内容説明

RHADS - SSC のインストール

セキュアで効率的な DevSecOps ワークフローを有効にするには、RHADS - SSC をインストールします。

アプリケーションの作成

事前に構築されたテンプレートを使用してアプリケーションを作成します。これらのテンプレートはカスタマイズが可能で、開発プロセスを簡素にするパイプラインと設定が含まれています。アプリケーションを作成するときに、以下を選択できます。

  • リポジトリーには GitHub (デフォルト)、GitLab、または Bitbucket
  • レジストリーには Quay (デフォルト)、JFrog Artifactory、または Sonatype Nexus Repository
  • CI/CD ワークフローには Tekton (デフォルト)、GitHub Actions、Jenkins CI、または GitLab CI
注記

アプリケーションのセットアップ中に Bitbucket、GitLab CI、または Jenkins CI を選択した場合は、パイプラインの実行をトリガーするようにこれらのツールを設定する必要があります。

アプリケーションの更新

アプリケーションコードに更新をプッシュします。パイプラインは変更を自動的に処理して保護します。

セキュリティーインサイトの表示

パイプラインの実行により、すべてのタスクが視覚的に表現され、セキュリティーチェックとコンプライアンスに関する洞察が提供されます。

アプリケーションのデプロイ

アプリケーションを開発環境からステージング環境へ、そして実稼働環境へと昇格させます。

(オプション) テンプレートとパイプラインのカスタマイズ

組織の特定の要件を満たすようにテンプレートとパイプラインを変更します。

第2章 サンプルソフトウェアテンプレートを使用したアプリケーションの構築
リンクのコピー

RHADS - SSC のすぐに使用できるソフトウェアテンプレートには、開発エクスペリエンスを保護および最適化するための主要なテクノロジーとのデフォルトの統合が含まれています。

  • ACS (Advanced Cluster Security): 開発プロセスの早い段階で脆弱性を特定して軽減し、初期段階からデプロイ段階までアプリケーションを強化します。
  • Quay: コンテナーイメージのセキュアな保管場所として機能し、脆弱性を継続的にスキャンして、コンテナー化されたアプリケーションを安全に保ちます。
  • OpenShift Pipelines: ビルドおよびデプロイメントプロセスを自動化し、SDLC にシームレスに統合して実稼働環境への移行を加速する CI/CD フレームワークを提供します。
  • OpenShift GitOps: インフラストラクチャーとアプリケーションの設定を Git リポジトリーで管理し、すべての環境で一貫性のある自動デプロイメントを保証します。

さらに、RHADS - SSC は、Java、Python、Node.js、Go などの一般的なプログラミング言語でのアプリケーションの開発とコンテナー化をサポートします。

注記

RHADS - SSC をインストールした後、クラスター管理者は特定のテンプレートと拡張機能を使用して Red Hat Developer Hub ポータルをカスタマイズできます。ただし、カスタマイズを行う前に、クラスター管理者はこのガイドを通じて利用可能なソフトウェアとパイプラインテンプレートを理解しておく必要があります。これらのテンプレートを理解することは、RHADS - SSC がセキュアなサプライチェーンをどのようにサポートしているかを把握し、その後のカスタマイズの基礎を築く鍵となります。

2.1. 準備
リンクのコピー

  • RHADS - SSC が正常にインストールされていることを確認します。

  • インストールプロセスの最後に RHADS - SSC インストーラーによって提供されるリンクを使用して、Red Hat Developer Hub (RHDH) にログインします。

2.2. アプリケーションの構築
リンクのコピー

RHDH ポータルで Create を選択し、適切なテンプレートを選択します。たとえば、Quarkus Java - Trusted Application Pipeline などです。

RHADS - SSC が提供するテンプレートを使用して RHDH で開発者向けのアプリケーションまたはマイクロサービスを構築するには、主に次の 3 つの手順を実行します。

  • アプリケーション情報の指定
  • アプリケーションリポジトリー情報の指定
  • デプロイメント情報の指定
アプリケーション情報の提供
  1. Name フィールドにアプリケーション名を入力します。名前には小文字 (a-z)、数字 (0-9)、ダッシュ (-) を使用できます。ただし、先頭と末尾が小文字の英数字である必要があります。有効な名前の例は my-name や abc-123 です。長さは 1 - 63 文字である必要があります。
  2. Owner ドロップダウンリストから、このアプリケーションに適切な RHDH コンポーネントの所有者を選択します。デフォルト値は user:guest で、システムに特定の所有者が登録されていない場合に表示されます。所有者を登録していない場合は、デフォルトの user:guest を選択したままにします。アプリケーションの所有権をカスタマイズするには、guest をユーザー名に置き換えます。
  3. Next を選択します。Application Repository Information フォームが表示されます。
アプリケーションリポジトリー情報の提供

  1. Host Type ドロップダウンリストから、リポジトリーのホストタイプを選択します。

    • GitHub
    • GitLab
    • Bitbucket
  2. Repository Name フィールドに、A-Z、a-z、0-9、アンダースコア (_)、ダッシュ (-) を使用してリポジトリー名を入力します。システムは、ホストリポジトリーサーバー上に作成するリポジトリーにこの名前を使用します。
  3. Repository Owner フィールドで、Git リポジトリーを所有する組織内のユーザー名、組織名、またはプロジェクトを指定します。たとえば、Bitbucket では、Personal Bitbucket 設定に移動してユーザー名を見つけることができます。

  4. Repository Server フィールドで、リポジトリーサーバーを指定します。

    Expand
    ホストタイプを選択した場合説明

    GitHub

    このフィールドには github.com が事前に入力されています。ただし、HTTP プロトコルと .git 拡張子なしでオンプレミスホスト URL を入力することもできます。たとえば、github-github.apps.cluster-ljg9z.sandbox219.opentlc.com です。

    GitLab

    このフィールドには gitlab.com が事前に入力されています。ただし、HTTP プロトコルと .git 拡張子なしでオンプレミスホスト URL を入力することもできます。たとえば、gitlab-gitlab.apps.cluster-ljg9z.sandbox219.opentlc.com です。

    Bitbucket

    このフィールドには bitbucket.org が事前に入力されています。

  5. Repository Default Branch フィールドで、リポジトリーのデフォルトブランチを指定します。デフォルトは main ですが、別のブランチ名を指定することもできます。

  6. Bitbucket のみ:

    1. Workspace フィールドに、プロジェクトが含まれているワークスペースの名前を入力します。
    2. Project フィールドにプロジェクトキーを入力します。プロジェクトキーは、Bitbucket のプロジェクト名の横にあります。

  7. CI Provider ドロップダウンリストから、システムがアプリケーションの構築、テスト、およびデプロイに使用する継続的インテグレーション (CI) ツールを選択します。

    Expand
    ホストタイプ利用可能な CI プロバイダー

    Bitbucket

    • Jenkins (SLSA 2)
    • Tekton (SLSA 3)
    • Azure Pipelines (SLSA2) (テクノロジープレビュー)

    GitHub

    • Jenkins (SLSA 2)
    • Github Actions (SLSA 2)
    • Tekton (SLSA 3)
    • Azure Pipelines (SLSA2) (テクノロジープレビュー)

    GitLab

    • Jenkins (SLSA 2)
    • GitLab CI (SLSA 2)
    • Tekton (SLSA 3)
    重要
  8. 手順 7 で CI プロバイダーとして Azure Pipelines を選択した場合、UI に Azure Project フィールドが表示されます。RHADS - SSC がパイプラインを実行する Azure プロジェクトの名前を入力します。
  9. Next を選択します。Deployment Information フォームが表示されます。
デプロイメント情報の提供
  1. Image Registry フィールドで、HTTP プロトコルなしでオンプレミスのイメージレジストリー URL を指定します。サポートされているレジストリーには、Quay (例: quay.io)、JFrog Artifactory (例: tssc.jfrog.io)、Sonatype Nexus Repository (例: nexus.mycompany.com) などがあります。
  2. Image Organization フィールドに、ステップ 1 で指定したイメージレジストリーのイメージ設定を入力します。

  3. Image Name フィールドに、小文字、数字、区切り文字のみを使用してイメージ名を入力します。区切り文字には、ピリオド (.)、最大 2 つのアンダースコア (_)、または 1 つ以上のハイフン (-) が含まれます。たとえば、my-app_1.2 と入力します。

    注記

    名前の先頭と末尾が区切り文字にならないようにする必要があります。

  4. Deployment Namespace フィールドに、アプリケーションをデプロイする namespace またはクラスターの接頭辞を入力します。システムは、tssc-app-development、tssc-app-stage、tssc-app-prod として namespace を作成します。

    注記

    tssc-app は、デフォルトのデプロイメント namespace の接頭辞です。クラスター管理者はこの接頭辞をカスタマイズできます。デフォルトのデプロイメント namespace の接頭辞をカスタマイズする方法の詳細は、サンプルソフトウェアテンプレートのカスタマイズ を参照してください。

  5. 追加したすべての情報を確認するには、Review を選択します。

  6. Create を選択します。RHADS - SSC は、次のようなアプリケーションのインフラストラクチャーとデプロイメントパイプラインをセットアップするための自動タスクを開始します。

    • リポジトリーの作成と設定: GitOps リポジトリーとソースリポジトリーを含む、指定したホスティングサービスに新しいリポジトリーを作成します。
    • Argo CD 統合: 指定された namespace 全体にわたってアプリケーションのデプロイメントを調整するために、Argo CD リソースを作成および設定します。
    • namespace の作成: 開発、ステージング、および実稼働環境の namespace を生成します。
    • パイプライン定義: パイプライン定義を追加し、アプリケーションの構築、テスト、およびデプロイのための "コードとしてのパイプライン" モデルを提供します。

2.3. アプリケーションのレビュー
リンクのコピー

RHADS - SSC を使用してアプリケーションを作成した後、そのコンポーネント、ソースコード、GitOps 設定、および関連ドキュメントを確認できます。

クイック分析

簡単に確認するには、"Run of …​" ページに表示されているリンクをクリックしてください。これらのリンクは、次のような重要なリソースへのアクセスを提供します。

  • ソースリポジトリー
  • GitOps リポジトリー

包括的な分析

詳細な分析を行うには、次の手順に従ってください。

  • カタログで Open Component を選択するか、新しく作成したアプリケーションがリストされている Catalog に移動します。

  • ソースコードの調査:

    1. Overview タブに移動し、View Source を選択して、アプリケーションのソースコードを含むリポジトリーを開きます。

  • デプロイメント履歴の確認:

    1. Overview タブで、Deployment の概要セクションに移動して、namespace 全体にわたるアプリケーションのデプロイメントを確認します。任意の Argo CD アプリケーションを選択して Argo CD のデプロイメントの詳細を表示するか、リビジョン列からコミット ID をクリックして GitLab または GitHub での変更を確認します。

  • GitOps リポジトリーの確認:

    1. Overview タブで、Kind ドロップダウンを使用して Resource を選択し、関連する GitOps リポジトリーを見つけます。
    2. GitOps 設定を直接調べるには、View Source を選択します。または、技術ドキュメントを含むより広範な概要に対して、カタログセクションから View TechDocs を選択し、Home > Repository の下にある GitOps リポジトリーを選択します。

  • ドキュメントの確認:

    1. Overview タブから、View Tech Docs を選択します。これにより、アプリケーションの技術ドキュメントが開き、その機能、設定手順、および使用方法の詳細な情報が提供されます。

2.4. (オプション) アプリケーションの登録解除
リンクのコピー

このプロセスを実行すると、アプリケーションのソースと GitOps リポジトリーがカタログとリソースビューから削除され、実質的に非表示になります。アプリケーションはクラスター内で機能し続けます。元のソースと GitOps リポジトリーは削除されないため、登録解除されたアプリケーションはいつでも再登録できます。

  1. Catalog に移動し、登録解除するコンポーネントを選択します。

  2. コンポーネントに関連する縦の省略記号のメニューを選択し、Unregister entity を選択します。確認ダイアログボックスが表示されます。

    登録解除
  3. Unregister Location 選択します。アプリケーションの Git リポジトリーがカタログビューから削除されます。
  4. Catalog に移動し、Kind ドロップダウンリストから Resource を選択して、対応する GitOps リソースを登録解除します。

  5. 次のコマンドを実行して、クラスターからアプリケーションを削除します。 

    oc delete application your-app-name-app-of-apps -n tssc-gitops
    1
    1
    tssc を異なる namespace に置き換え、your-app-name をアプリケーションの名前に置き換えます。

第3章 コードを更新してセキュリティーの洞察を表示する
リンクのコピー

RHADS - SSC を使用してコンポーネントを作成すると、システムによってビルドパイプラインがトリガーされます。ビルドパイプラインが完了すると、アプリケーションの最新バージョンが開発の namespace にデプロイされます。デフォルトでは、開発 namespace は tssc-app-development です。

パイプラインを表示するには、次のコマンドを実行します。

  1. RHADS - SSC を開いて、Catalog に移動します。
  2. 変更されたコンポーネントを選択し、CI タブに移動してパイプライン実行の詳細を表示します。

  3. 必要に応じて、追加の分析情報を得るには次のタブを使用します。

    1. CD: ArgoCD によって管理されるデプロイメントデータを表示します。
    2. Topology: 開発の namespace でのアプリケーションのデプロイメントを視覚的に表示します。
注記

場合によっては、コンポーネントがビルドされた直後にパイプラインの実行が表示されないことがあります。1 分経ってもパイプラインの実行が表示されない場合は、コンポーネントのソースコードを更新して、新しいパイプラインの実行をトリガーします。

3.1. ソースコードの更新
リンクのコピー

  1. Catalog に移動し、更新するコンポーネントを選択します。
  2. Overview タブで View Source を選択して、GitLab または GitHub でプロジェクトを開きます。
  3. 必要に応じて、View Tech Docs を選択してプロジェクトのドキュメントを開きます。ソースはリポジトリーの docs/ ディレクトリーにあります。このディレクトリーを更新すると、Tech Docs を更新するためにパイプライン実行がトリガーされます。

  4. コードに必要な変更を加えます。

    1. リポジトリーをクローンします。
    2. ファイルを変更します。たとえば、技術ドキュメントを更新するか、index.html を編集します。
    3. 変更をコミットしてプッシュします。
注記
  • GitLab または GitHub UI を使用して、ブラウザーで直接コードを変更できます。

  • GitLab および Bitbucket を使用する場合: コードの更新後にパイプラインの実行を自動的にトリガーするには、GitLab または Bitbucket で Webhook とシークレットを設定する必要があります。

3.2. セキュリティーインサイトの表示
リンクのコピー

コードを更新して変更をプッシュすると、システムは自動的に on-push パイプラインをトリガーします。デフォルトでは、RHADS - SSC は ソフトウェアアーティファクト (SLSA) レベル 3 仕様を満たすコンテナー化されたデプロイメントに標準ビルドパイプラインを使用します。

図3.1 正常なパイプライン実行

パイプライン実行

パイプラインの実行では、次のタスクが実行します。

  • init: 再構築フラグ、認証を設定し、イメージリポジトリーシークレットを作成します。
  • clone-repository: ビルドの準備のためにリポジトリーのクローンを作成します。

  • build-container:

    • Buildah を使用してソースコードからコンテナーイメージを作成し、レジストリーにプッシュします。
    • すべてのコンポーネントと依存関係を文書化するために Software Bill of Materials (SBOM) を生成します。
    • イメージ署名やアテステーションなどのセキュリティーアーティファクトを公開します。
  • update-deployment: GitOps リポジトリーを更新して新しいイメージをデプロイします。
  • acs タスク: ポリシーへの準拠を確認するためにセキュリティーチェックを実行します。
  • show-sbom: 透明性のためにすべてのソフトウェアコンポーネントとライブラリーをリスト表示します。
  • summary: リソースをクリーンアップし、パイプラインの実行の概要を提供します。
注記

パイプライン実行内の任意のタスクをクリックすると、ログが表示されます。

3.2.1. Red Hat Advanced Cluster Security のタスク
リンクのコピー

パイプライン内の RHACS タスクは、RHADS - SSC インストールプロセス中に RHACS をインストールして設定した場合にのみ成功します。RHACS がインストールまたは設定されていない場合、パイプラインはこれらのタスクをスキップします。

注記

図3.2 パイプライン実行内の RHACS タスク

ACS タスク

パイプラインには、roxctl を使用してセキュリティーチェックを実行する 3 つの RHACS タスクが含まれています。

  • roxctl image scan - イメージ内のコンポーネントと脆弱性を識別し、結果を JSON 形式で返します。
  • roxctl image check - イメージ内のビルド時のセキュリティー違反を検証します。たとえば、'No log4j allowed' などのポリシーや、実稼働イメージに curl、wget、パッケージマネージャーを含めることに対する制限などです。
  • roxctl deployment check - YAML デプロイメントファイル内のビルド時およびデプロイ時のセキュリティー違反をチェックします。
RHACS レポートの視覚化

RHDH の CI タブのパイプライン実行セクションには、構造化されたポップアップインターフェイスに詳細なタスクレポートが表示されます。ポップアップには次の内容が含まれます。

  • Red Hat Advanced Cluster Security (RHACS タスクの有無に応じて条件付きで表示されます): すべての RHACS タスクの個別のタブを表示し、特定されたセキュリティーの問題の概要を示します。
  • その他: PipelineRun からの結果 (IMAGE_URL、IMAGE_DIGEST など) を提供します。このセクションは、ポップアップで複数のセクション (たとえば、Enterprise Contract や RHACS) が使用可能な場合にのみ表示されます。

RHACS レポートを表示するには、以下を実行します。

  1. Catalog を選択し、確認するコンポーネントを選択します。

  2. CI タブ > Actions 列 > View output アイコンを選択し、選択したコンポーネントの詳細な RHACS レポートを確認します。

    図3.3 詳細な RHACS レポート

    ACS レポート
    注記

    必要な権限がある場合は、RHACS コンソールで脆弱性やポリシーを管理し、特定のイメージの詳細な脆弱性レポートを確認できます。詳細は、ダッシュボードの表示 を参照してください。

RHACS レポートの解釈

RHACS タスクからのレポートは、強力なセキュリティー体制を維持するために重要なセキュリティーの洞察を提供します。

以下は、roxctl image scan (イメージスキャン) レポートを解釈する例です。roxctl image check (イメージチェック) レポートおよび roxctl deployment check (デプロイメントチェック) レポートにも同じアプローチを使用します。

  • 脆弱性の内訳: RHACS は、検出された脆弱性を重大度別 (重大、重要、中程度、低)、ステータス別 (修正可能、修正不可能) に分類し、スキャン結果の概要を提供します。この分類には、分析された脆弱性とコンポーネントの総数と、Common Vulnerabilities and Exposures (CVE) が含まれます。

  • 表示される詳細情報: レポートには、特定された脆弱性ごとに次の内容が含まれています。

    • CVE ID: 脆弱性の一意の識別子。
    • 重大度: 脆弱性によってもたらされる脅威のレベル。
    • コンポーネント: 脆弱性の影響を受けるソフトウェアコンポーネント。
    • コンポーネントバージョン: 影響を受けるコンポーネントのバージョン。
    • 修復の提案: 脆弱性に対処するための推奨事項。該当する場合は、脆弱性が修正されたバージョンが含まれています。

3.2.2. SBOM について
リンクのコピー

show-sbom タスクは、アプリケーションで使用されるすべてのソフトウェアライブラリーのリストを作成します。これは、脆弱性を特定し、セキュリティーへの影響を評価するのに役立ちます。

図3.4 パイプライン実行内の show-sbom タスク

sbom
SBOM の表示

手順

  1. Catalog を選択し、コンポーネントを選択します。

  2. CI タブを選択し、show-sbom タスクのリンクアイコンを選択します。システムは SBOM タスクログを表示します。ブラウザーで SBOM を確認し、log4j などの脆弱性を検索します。

    図3.5 SBOM の詳細

    sbom の表示
CLI での SBOM のダウンロード

前提条件

  • Cosign CLI ツールがインストールされている。
  • build-container および show-sbom タスクが正常に実行されている。

手順

  1. 成功したパイプライン実行を展開し、show-summary タスクを選択します。

  2. SBOM イメージ URL を検索してコピーし、ターミナルで次のコマンドを実行します。

    cosign コマンドの例

    $ cosign download sbom <the-sbom-url-you-copied>

    1. (オプション) 詳細な分析のために出力をファイルに保存します。

      cosign コマンドの例

      $ cosign download sbom <the-sbom-url-you-copied> > sbom.txt

SBOM の解釈

SBOM には、プロジェクトで使用される各ライブラリーに関する次のような情報が含まれます。

  • ライブラリー、著者、またはパブリッシャーのソース
  • ライブラリー名
  • ライブラリーのバージョン
  • ライセンスの種類

この情報は、個々のライブラリーが安全に提供され、更新され、準拠していることを保証するのに役立ちます。

SBOM の例

{
    "bomFormat": "CycloneDX",
    "specVersion": "1.4",
    "serialNumber": "urn:uuid:89146fc4-342f-496b-9cc9-07a6a1554220",
    "version": 1,
    "metadata": {
        ...
    },
    "components": [
        {
            "bom-ref": "pkg:pypi/flask@2.1.0?package-id=d6ad7ed5aac04a8",
            "type": "library",
            "author": "Armin Ronacher <armin.ronacher@active-4.com>",
            "name": "Flask",
            "version": "2.1.0",
            "licenses": [
                {
                    "license": {
                        "id": "BSD-3-Clause"
                    }
                }
            ],
            "cpe": "cpe:2.3:a:armin-ronacher:python-Flask:2.1.0:*:*:*:*:*:*:*",
            "purl": "pkg:pypi/Flask@2.1.0",
            "properties": [
                {
                    "name": "syft:package:foundBy",
                    "value": "python-package-cataloger"
                    ...

第4章 アプリケーションの導入とセキュリティーの分析情報の表示
リンクのコピー

OpenShift GitOps で Argo CD を使用してアプリケーションをデプロイし、継続的なデプロイメントを有効にします。Argo CD は、インフラストラクチャー設定の唯一の信頼できるソースとして Git リポジトリーを使用します。リポジトリーを更新すると、開発環境、ステージング環境、実稼働環境全体にわたってデプロイメントがトリガーされます。

注記

手順では、デプロイメントワークフローの例を示します。組織の要件に合わせてカスタマイズします。

4.1. 実稼働前の環境または実稼働環境へのビルドのプロモート
リンクのコピー

プルリクエスト (PR) を通じて GitOps リポジトリーを更新し、ビルドをプロモートします。

  1. RHDH で、Catalog を選択します。
  2. Kind ドロップダウンリストから Resource を選択し、GitOps リポジトリーを選択します。
  3. Overview タブを開き、View Source を選択してリポジトリーにアクセスします。

  4. (オプション) または、Catalog を選択し、Overview タブを開いて、View TechDocs を選択します。

    1. Home > Repository セクションで、GitOps リポジトリーを選択します。

  5. GitOps リポジトリーのクローンを作成します。

    注記

    ローカルの複製が最新であることを確認してください。

  6. 新しいブランチを作成します。
  7. component/<app-name>/overlays ディレクトリーに移動します。このディレクトリーには、development、stage、prod のサブディレクトリーが含まれています。

  8. アプリケーションを宣伝するには、次の手順に従ってください。

    Expand
    アプリケーションの移動先実行する手順

    開発環境からステージ環境

    1. development/deployment-patch.yaml ファイルを開き、コンテナーイメージの URL をコピーします。たとえば、quay.io/<username>/imageName:imageHash です。
    2. stage/deployment-patch.yaml ファイルを開き、コンテナーイメージの URL をコピーした URL に置き換えます。
    注記

    追加の設定変更 (レプリカなど) を含めるには、development/deployment-patch.yaml ファイルから stage/deployment-patch.yaml ファイルにコピーします。

    ステージ環境から実稼働環境

    1. stage/deployment-patch.yaml ファイルを開き、コンテナーイメージの URL をコピーします。たとえば、quay.io/<username>/imageName:imageHash です。
    2. prod/deployment-patch.yaml ファイルを開き、コンテナーイメージの URL をコピーした URL に置き換えます。
    注記

    追加の設定変更 (レプリカなど) を含めるには、それらを stage/deployment-patch.yaml ファイルから prod/deployment-patch.yaml ファイルにコピーします。

  9. 更新をコミットしてプッシュします。

  10. プロモーションパイプラインを開始するための PR を作成します。パイプラインは、Enterprise Contract ポリシーに対して変更を検証します。

    1. RHDH の CI タブでパイプラインの実行を確認します。
  11. PR をマージして Argo CD をトリガーし、変更を適用してビルドを次の環境にプロモートします。

検証

  • RHDH の Topology タブを使用して、namespace 全体にわたるアプリケーションの分散を確認します。
  • CD タブを使用して、ステータス、更新、コミットメッセージ (Promote stage to prod など)、コンテナーイメージの変更などのデプロイメントの詳細を表示します。

4.2. セキュリティーインサイトの表示
リンクのコピー

プロモーションパイプラインには、安全で準拠したデプロイメントを保証するためのいくつかのタスクが含まれています。パイプラインタスクには次のものが含まれます。

  • git-clone: git-clone タスクを使用してリポジトリーのクローンをワークスペースに作成します。
  • gather-deploy-images: 検証のためにデプロイメント YAML ファイルからコンテナーイメージを抽出します。
  • verify-enterprise-contract: Enterprise Contract ポリシーと Sigstore の cosign ツールを使用してコンテナーイメージを検証します。
  • deploy-images: デプロイはターゲット環境へのイメージを検証します。
  • download-sbom-from-url-in-attestations: イメージのアテステーションで参照される OCI Blob をダウンロードして、イメージの SBOM を取得します。
  • upload-sbom-to-trustification: BOMbastic API を使用して SBOM を Trustification にアップロードします。

4.2.1. Enterprise Contract タスク
リンクのコピー

Enterprise Contract は、ソフトウェアサプライチェーンのセキュリティーを維持するために設計されたツール群です。コンテナーイメージが実稼働環境に昇格される前に定義された要件を満たしていることを確認することで、コンテナーイメージの整合性を維持するのに役立ちます。イメージが設定されたポリシーに準拠していないと、解決する必要がある問題を特定するレポートを Enterprise Contract が生成します。

Red Hat Advanced Developer Suite - software supply chain ビルドプロセスでは、ビルドパイプラインの署名済み in-toto アテステーションが生成されます。これらのアテステーションは、ビルドの整合性を暗号的に検証します。次に、Enterprise Contract は定義されたポリシーに照らしてビルドを評価し、組織のセキュリティー標準に準拠していることを確認します。

Enterprise Contract レポートの視覚化

Red Hat Developer Hub の CI タブの Pipeline Runs セクションには、構造化されたポップアップインターフェイスで詳細なコンプライアンスレポートが表示されます。Enterprise Contract コンプライアンスレポートから得られる情報は、セキュリティーとコンプライアンスのタスクの優先順位付けに役立ちます。

  • ポリシーのコンプライアンスを確認する: アプリケーションがソフトウェアアーティファクトのサプライチェーンレベル (SLSA) などの標準を満たしていることを確認します。レポートの推奨事項に基づいて、コンプライアンスのギャップに対処します。
  • レビューを効率化する: フィルターを適用して重要な問題に焦点を合わせます。このアプローチにより、より迅速で効率的なレビュープロセスが可能になります。

Tekton を CI プロバイダーとして使用している場合の Enterprise Contract レポートの表示

  1. Catalog を選択し、確認するコンポーネントを選択します。
  2. CI タブを選択し、Actions 列で View output を選択して、選択したコンポーネントの詳細な Enterprise Contract レポートを確認します。

図4.1 Enterprise Contract レポート

Enterprise Contract

他の CI プロバイダーを使用する場合の Enterprise Contract レポートの表示

Jenkins や GitLab などの別の CI プロバイダーを使用する場合:

  1. それぞれのアプリケーションのビルドログに移動します。
  2. Step: verify-enterprise-contract を検索して、詳細な Enterprise Contract レポートを確認します。
コンプライアンスレポートの解釈

Enterprise Contract コンプライアンスレポートは、アプリケーションのセキュリティーとポリシーの遵守に関する詳細な情報を提供します。これらのレポートを理解する方法は次のとおりです。

  • ポリシーコンプライアンスの概要: 実行したチェック、そのステータス (成功、警告、または失敗)、および警告または失敗を説明するメッセージが表示されます。

  • 表示される詳細情報: ポリシーレポートの詳細:

    • 成功したチェック: 検証に合格したポリシーをリスト表示します。
    • 警告と失敗: 警告をトリガーしたポリシーやチェックに失敗したポリシーを説明とともに強調表示します。
    • ルールのコンプライアンス: ソースコードの参照やアテステーションの検証など、アプリケーションが個々のポリシールールにどのように準拠しているかを示します。
コンプライアンスの洞察の使用

Enterprise Contract コンプライアンスレポートから得られる情報は、セキュリティーとコンプライアンスのタスクの優先順位付けに役立ちます。

  • ポリシーのコンプライアンスを確認する: アプリケーションがソフトウェアアーティファクトのサプライチェーンレベル (SLSA) などの標準を満たしていることを確認します。レポートの推奨事項に基づいて、コンプライアンスのギャップに対処します。
  • レビューの合理化: レポート内のフィルターを使用して重要な問題に焦点を絞り、より迅速かつ効率的なレビュープロセスを実現します。





改訂日時: 2025-09-06

法律上の通知
リンクのコピー

Copyright © 2025 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

© 2026 Red Hatトップに戻る