Red Hat Trusted Application Pipeline のスタートガイド

Red Hat Trusted Application Pipeline 1.0

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

Red Hat Trusted Application Pipeline Documentation Team

概要

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

第1章 RHTAP の基礎について

ソフトウェア開発ライフサイクル (SDLC) 全体のサイバーセキュリティープラクティスを一新することを目的としたフレームワーク、Red Hat Trusted Application Pipeline (RHTAP) の堅牢な基盤を紹介します。RHTAP を使用すると、従来のセキュリティー対策を超えた取り組みを開始し、最先端のソリューションと DevSecOps CI/CD フレームワークを、計画からデプロイまでの各段階に統合できます。このようなプロアクティブな戦略により、開発者のオンボーディング、プロセスの加速、および初期段階からのセキュリティーの組み込みを加速します。

1.1. セキュアな CI/CD フレームワーク

RHTAP の中心となるのは、最高レベルのソフトウェア開発標準を遵守するように設計された、先駆的でセキュアな CI/CD フレームワークです。RHTAP は、Supply-chain Levels for Software Artifacts (SLSA) レベル 3 に準拠し、すべてのコード行がセキュリティーの堅牢化に寄与するようにして、脆弱性の早期検出と軽減を大幅に強化します。

1.2. RHTAP のセキュリティーツールの詳細

潜在的な脆弱性を軽減するには、ソフトウェア開発全体にわたってソフトウェアのセキュリティーを確保することが不可欠です。RHTAP は、セキュリティー対策を強化するために設計された強力なツール群を活用します。RHTAP のコンポーネント (RHDH、RHTAS、RHTPA) を活用して、セキュリティー脅威に対する強力な防御を提供する仕組みを紹介します。

Red Hat Developer Hub (RHDH)

Red Hat Developer Hub は、開発者向けのセルフサービスポータルです。オンボーディングプロセスを効率化し、セキュアなソフトウェア開発に必要な豊富なリソースとツールへのアクセスを提供します。このプラットフォームは、ベストプラクティスを推奨し、開発プロセスの最初からセキュリティー対策を組み込むことを容易にします。

Red Hat Trusted Artifact Signer (RHTAS)

Red Hat Trusted Artifact Signer は、署名およびアテステーションメカニズムを通じてソフトウェアインテグリティーを強化することに重点を置いています。RHTAS は、すべてのコードとアーティファクトが署名およびアテストされていることを確認することで、使用されているソフトウェアコンポーネントの信頼性とセキュリティーを確認する検証可能な信頼チェーンを実現します。

Red Hat Trusted Profile Analyzer (RHTPA)

Red Hat Trusted Profile Analyzer は、Software Bills of Materials (SBOM) の生成と管理を扱います。SBOM は、ソフトウェア製品に含まれるすべてのコンポーネント、ライブラリー、依存関係の詳細なリストを提供するため、透明性とコンプライアンスを維持する上で非常に重要です。RHTPA は、SBOM の作成を自動化し、ソフトウェアの構成に関する正確で最新の情報をステークホルダーに提供します。

1.3. すぐに使用できるソフトウェアテンプレートの活用

RHTAP は、すぐに使用できるソフトウェアテンプレートを備えており、開発ワークフローにセキュリティーを直接組み込みます。そのため、開発者はセキュリティー関連の煩わしさを最小限に抑えながらイノベーションに集中できます。すぐに使用できるソフトウェアテンプレートは、完全なカスタマイズが可能で、組織独自の要件にシームレスに対応できます。

すぐに使用できる統合機能のメリット:

Red Hat Advanced Cluster Security (RHACS): デプロイメントを脆弱性に対して強化します。
Quay: コンテナーイメージ用のセキュアなリポジトリーを提供します。
Tekton パイプライン: 正確な自動デプロイを実現します。
GitOps: 一貫性と自動化された設定管理を維持します。

1.4. 主なセキュリティープラクティス

RHTAP には、特定のセキュリティー上の懸念に効果的に対処するために、次のツールが組み込まれています。

脆弱性のスキャン: RHTAP は、各プルリクエストごとに、指定の CVE スキャナー (Advanced Cluster Security など) を使用して徹底的なスキャンを実行し、可能な限り早い段階で脆弱性を特定して対処します。
SBOM の生成: RHTAP の SBOM 自動生成は、ソフトウェアの透明性とコンプライアンスを維持する上で重要な役割を果たします。組織は、ソフトウェアコンポーネントの包括的なインベントリーを提供することで、ソフトウェアサプライチェーンをより適切に管理して保護することができます。
コンテナーイメージのセキュリティー: RHTAP は、コンテナーイメージが SLSA (Supply-chain Levels for Software Artifacts) ガイドラインに準拠していることを検証します。これは、41 を超えるルールを含む Enterprise Contract により実行されます。これにより、開発プロセスで使用されるコンテナーイメージを厳格なセキュリティー標準に準拠させることができます。

1.5. 今後の道筋

DevSecOps の考え方を取り入れ、RHTAP を活用することで、セキュアで効率的な開発環境が促進されます。このような継続的な評価と向上の取り組みにより、組織は現在と将来のサイバーセキュリティーの課題に効果的に対処できるようになります。

次のステップ

セキュアなアプリケーション開発に向けた準備

関連情報

Red Hat Developer Hub の詳細は、Red Hat Developer Hub のスタートガイドを参照してください。
Red Hat Trusted Artifact Signer の詳細は、RHTAS デプロイメントガイドを参照してください。
Red Hat Trusted Profile Analyzer の詳細は、クイックスタートガイドを参照してください。

第2章セキュアなアプリケーション開発に向けた準備

Red Hat Trusted Application Pipeline (RHTAP) を使用すると、アプリケーションのコンテナー化とデプロイの効率が大幅に向上し、開発者が数分以内に作業内容をデプロイできるようになります。この革新的なプラットフォームは、アプリケーションの変更を迅速にテストおよび統合するためのビルドパイプラインの作成を容易にするだけでなく、サプライチェーン攻撃に対するセキュリティー対策を強化します。RHTAP は、Supply-chain Levels for Software Artifacts (SLSA) セキュリティーフレームワークの厳格な標準に準拠することで、高い水準のセキュリティー要件への準拠を実現します。

2.1. インストールの概要

RHTAP が提供するさまざまな利点を活用するには、まず組織内に RHTAP をインストールする必要があります。RHTAP のインストールは、次の 7 つの主要な手順で構成されます。

RHTAP 用の GitHub アプリケーションの作成
テンプレートカタログのフォーク
GitOps git トークンの作成
Docker 設定値の作成
private-values.yaml ファイルの作成
クラスターへの RHTAP のインストール
GitHub アプリケーションの完成

2.2. 初期設定

インストールプロセスを開始する前に、スムーズで正常なセットアップを確実に行うために、次の前提条件を満たす必要があります。

クラスターへのアクセス: OpenShift Container Platform (OCP) クラスターへの ClusterAdmin アクセス権があり、CLI と Web コンソールの両方からアクセスできることを確認します。
Red Hat Advanced Cluster Security (ACS): ACS インスタンスから、以下を含む必要な値を取得します。
- ACS API トークン: API トークンを作成するには、こちらに記載されている手順に従います。
- ACS Central エンドポイント URL: こちらの手順を参照してエンドポイントを設定します。
ACS をプライベートリポジトリー用に設定する: Quay.io などのイメージレジストリーでプライベートリポジトリーを使用している場合は、それに応じて ACS を設定します。
- Quay.io の場合は、Integrations > Image Integrations に移動し、Quay.io カードを選択します。
- お使いの Quay.io インスタンスにアクセスするための OAuth トークンを追加します。
- テストボタンを使用してアクセスを検証し、必要なときに ACS がプライベートイメージをスキャンできるようにします。
Quay.io アカウント: 有効な Quay.io アカウントがあることを確認します。
Helm CLI ツール: こちらで提供されているガイドラインに従って、Helm CLI ツールをインストールします。
GitHub アカウント: 最後に、一部のインストール手順を容易にするために、GitHub アカウントがあることを確認します。

これらの前提条件を満たして、RHTAP インスタンス専用の新しい GitHub アプリケーションを作成すれば、インストールプロセスを開始する準備が整います。

次のステップ

Red Hat Trusted Application Pipeline のインストール

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

RHTAP は、Red Hat Developer Hub (RHDH) のすぐに使用できるソフトウェアテンプレートにより、開発環境を変革します。このテンプレートは、Red Hat の包括的なツール群 (RHDH、RHTAS、RHTPA) およびテクノロジーとシームレスに統合できるように細心の注意を払って設計されています。この統合により、オンプレミス環境内でセキュアで効果的な開発者向けの SDLC を実現するための強固なフレームワークが提供されます。

これらの基本要素に加えて、すぐに使用できる RHTAP のソフトウェアテンプレートには、開発エクスペリエンスをさらに保護し最適化する主要なテクノロジーとの統合機能がデフォルトで組み込まれています。

ACS (Advanced Cluster Security): 開発プロセスの早い段階で脆弱性を特定して軽減することで、デプロイメントを強化し、計画段階からデプロイ段階までアプリケーションを確実に強化します。
Quay: コンテナーイメージのセキュアな保管場所として機能します。脆弱性を継続的にスキャンする信頼性の高いリポジトリーを提供し、コンテナー化されたアプリケーションを安全に保ちます。
Tekton Pipelines: ビルドおよびデプロイプロセスを正確に自動化し、SDLC にシームレスに統合される CI/CD フレームワークを実現して、実稼働までの時間を短縮します。
GitOps: Git リポジトリーでインフラストラクチャーとアプリケーションの設定を維持することで GitOps 戦略を導入し、すべての環境で一貫性のある自動デプロイを実現します。

さらに、RHTAP は、Java、Python、Node.js、Go などの幅広い一般的なプログラミング言語によるアプリケーションの開発とコンテナー化をサポートし、組織のアプリケーション開発能力を拡大します。

クラスター管理者は、RHTAP をインストールすると、特定のテンプレートと拡張機能を使用して Red Hat Developer Hub ポータルをカスタマイズできるようになります。このカスタマイズプロセスにより、開発ワークフローが簡素化され、パイプライン、脆弱性、ポリシーに関連する懸念が軽減されます。カスタマイズは、開発者がコーディングに集中できるようにする上で重要です。

クラスター管理者は、カスタマイズを進める前に、このガイドを通じて利用可能なソフトウェアとパイプラインテンプレートについて理解しておくことが重要です。この理解は、RHTAP によりセキュアなサプライチェーンをサポートする仕組みを把握する上で欠かせないものであり、後のカスタマイズ作業の土台となります。

3.1. 準備

RHTAP が正常にインストールされていることを確認します。
RHTAP が提供するリンクを使用して、Red Hat Developer Hub (RHDH) にログインします。RHDH は包括的な開発者プラットフォームとして機能し、開発者ポータルの作成を容易にします。開発プロセスを強化する統合プラットフォームをエンジニアリングチームに提供し、高品質のソフトウェアを効率的に作成するためのさまざまなツールとリソースを提供します。

3.2. アプリケーションの構築

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

RHDH で、RHTAP が提供するテンプレートを使用して開発者向けのアプリケーションまたはマイクロサービスを構築するプロセスは、基本的に次の 3 つのステップのみです。

アプリケーション情報の指定
アプリケーションリポジトリー情報の指定
デプロイメント情報の指定

アプリケーション情報の指定

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

アプリケーションリポジトリー情報の指定

Host Type ドロップダウンリストから、適切なリポジトリーホストタイプを選択します。
Repository Owner フィールドに、使用している Git アプリケーションを所有する組織の名前を入力します。これには、個人のユーザーアカウント、組織、または組織内のプロジェクトを指定できます。
Repository Name フィールドに適切なリポジトリー名を入力します。使用できる文字は、AZ、az、0-9、アンダースコア (_)、およびダッシュ (-) 文字に限られます。システムがこの情報を使用して、ホストリポジトリーサーバー上に作成するリポジトリーに名前を付けます。
Repository Default Branch フィールドに、リポジトリーのデフォルトブランチを入力します。このフィールドにはデフォルトで main が表示されます。これをそのまま使用できます。
Repository Server フィールドに、オンプレミスホストの URL を入力します。HTTP プロトコルと .git 拡張子は除外します。たとえば、gitlab-gitlab.apps.cluster-ljg9z.sandbox219.opentlc.com です。
Next を選択します。Deployment Information フォームが表示されます。

デプロイメント情報の指定

Image Registry フィールドに、オンプレミスのイメージレジストリー URL を入力します。HTTP プロトコルは除外します。たとえば、quay-tv2pb.apps.cluster-tv2pb.sandbox1194.opentlc.com などです。
Image Organization フィールドに、ステップ 1 で指定したイメージレジストリーのイメージ設定を入力します。
Image Name フィールドに適切なイメージ名を入力します。小文字、ピリオド、区切り文字のみを使用してください。区切り文字には、ピリオド (.)、最大 2 つのアンダースコア (_)、または 1 つ以上のハイフン (-) が含まれます。たとえば、my-app_1.2 と入力します。
注記
名前の先頭と末尾が区切り文字にならないようにする必要があります。
Deployment Namespace フィールドに、アプリケーションをデプロイする名前空間またはクラスターの接頭辞を入力します。システムにより、実際の名前空間が rhtap-app-development、rhtap-app-stage、および rhtap-app-prod という形で作成されます。
注記
rhtap-app は、デフォルトのデプロイメント名前空間の接頭辞です。クラスター管理者はこの接頭辞をカスタマイズできます。デフォルトのデプロイメント名前空間の接頭辞をカスタマイズする方法は、サンプルソフトウェアテンプレートのカスタマイズを参照してください。
追加したすべての情報を確認するには、Review を選択します。
Create を選択します。RHTAP が、アプリケーションのインフラストラクチャーとデプロイメントパイプラインの設定に不可欠な一連の自動タスクを開始します。このプロセスの裏で、次のような重要な操作がいくつか実行します。
- リポジトリーの作成と設定: 指定したホスティングサービス (GitLab または GitHub) に、アプリケーションに合わせてカスタマイズされた新しいリポジトリーが自動的に作成されます。これには、デプロイメント設定を保持する GitOps リポジトリーと、アプリケーションコードが存在するソースリポジトリーの両方のセットアップが含まれます。
- Argo CD 統合: リポジトリーがセットアップされると、Argo CD リソースが作成および設定されます。宣言型の GitOps 継続的デリバリーツールである Argo CD が動作し、指定された名前空間全体のアプリケーションのデプロイを調整します。
- 名前空間の作成: デプロイメント環境のセットアップの一環として、アプリケーションの要件に基づいてさまざまな名前空間が自動的に生成されます。このとき、開発、ステージング、および実稼働環境用の個別の名前空間が生成されるため、段階間の分離とセキュリティーが確保されます。
- パイプライン定義: 最後に、パイプライン定義が環境に追加され、'Pipeline as code' モデルが提供されます。これにより、ベストプラクティスとセキュリティー対策に沿って、アプリケーションの構築、テスト、およびデプロイの自動ワークフローが定義されます。

3.3. アプリケーションの確認

RHTAP を使用してアプリケーションを正常に作成したら、そのコンポーネント、ソースコード、GitOps 設定、および関連ドキュメントを簡単に確認できます。包括的な分析を実行する方法は次のとおりです。

アプリケーションへのアクセス:
- アプリケーションを見つけるには、Open Component in catalog を選択します。新しく作成されたアプリケーションがリスト表示される Catalog に移動することもできます。
ソースコードの確認:
1. Overview タブに移動します。
2. View Source を選択して、アプリケーションのソースコードが格納されているリポジトリーを開きます。このステップで、アプリケーションの構築とロジックを詳しく把握できます。
GitOps リポジトリーの確認:
1. Overview タブで、Kind ドロップダウンを使用して Resource を選択し、関連する GitOps リポジトリーを見つけます。
2. GitOps 設定を直接調べるには、View Source を選択します。または、技術ドキュメントを含むより広範な概要情報を確認するために、Catalog セクションから View TechDocs を選択し、Home > Repository セクションの GitOps リポジトリーを選択します。
ドキュメントの確認:
1. Overview タブから、View Tech Docs をクリックします。
2. これにより、アプリケーションの技術ドキュメントが開き、アプリケーションの機能、設定手順、効果的な活用方法に関する詳細な情報が表示されます。

3.4. アプリケーションの登録解除

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

Catalog に移動し、登録解除するコンポーネントを選択します。
コンポーネントに関連する縦の省略記号のメニューを選択し、Unregister entity を選択します。確認ダイアログが表示されます。
Unregister Location 選択します。アプリケーションの Git リポジトリーがカタログビューから削除されます。
Catalog に移動し、Kind ドロップダウンリストから Resource を選択して、対応する GitOps リソースを登録解除します。
次のコマンドを実行して、クラスターからアプリケーションを削除します。
```
oc delete application your-app-name-app-of-apps -n rhtap 1
```
1
rhtap はデフォルトの名前空間です。また、your-app-name はアプリケーションの名前です。

次のステップ

コードを更新とセキュリティーインサイトの表示

第4章コードを更新とセキュリティーインサイトの表示

RHTAP を使用してコンポーネントを正常に構築したら、次のステップとして、コードを変更し、セキュリティーインサイトを詳しく調べます。

4.1. コード更新の開始

RHTAP では、このプロセスは簡単です。

Catalog を選択し、セキュリティーインサイトを表示する適切なコンポーネントを選択します。
Overview タブで View Source タブを選択して、GitLab または GitHub のプロジェクトを表示します。ここで、View Tech Docs を選択して、プロジェクトのドキュメントを表示することもできます。ドキュメントのソースは、リポジトリー内の docs ディレクトリーです。これらのファイルを更新し、パイプラインが正常に実行されると、技術ドキュメントも更新されます。

4.2. コードの変更

リポジトリーにアクセスすれば、Git リポジトリーを操作するというお馴染みのプロセスをすぐに実行できます。手順は次のとおりです。

リポジトリーを複製し、ローカルまたは開発環境で作業を開始します。
技術ドキュメントや index.html を更新したり、新しい機能やバグ修正を追加したりして、アプリケーションを変更します。
変更を コミット します。
変更をリポジトリーに プッシュ します。

注記

GitLab または GitHub UI を使用して、Web インターフェイス内でコードを直接更新することもできます。
GitLab ユーザーのみ: コードの更新時にパイプラインの実行を自動的にトリガーするには、GitLab で Webhook とシークレットを設定する必要があります。GitLab で Webhook とシークレットを設定する方法は、パイプラインの自動トリガーのために GitLab Webhook を設定するを参照してください。

4.3. パイプライン実行の表示

コードを変更した後にパイプライン実行を表示するには、以下を実行します。

RHDH プラットフォームに戻り、変更がどのように進行したかを確認します。
Catalog に移動し、変更した特定のコンポーネントを選択します。
CI タブを開き、パイプライン実行にアクセスします。

パイプライン実行以外にも、RHDH は他のタブを通じて貴重な情報を提供します。

CD: CD タブを使用して、ArgoCD と GitOps によって管理されるデプロイメントに関する詳細情報を確認します。
Topology: Topology タブを使用して、開発名前空間内のアプリケーションのデプロイメントを視覚的に表示します。

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

コードを更新して変更をプッシュすると、システムが自動的に on-push パイプラインをトリガーします。RHTAP は、デフォルトで標準のビルドパイプラインを使用してコンテナーによるデプロイを迅速に実行し、Software Artifacts (SLSA) レベル 3 仕様に準拠してサプライチェーンのセキュリティーを強化します。

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

この図は、各パイプラインタスクの概要を示しています。緑色のステータスは、正常に完了したことを示しています。細かく監視する必要をなくし、ワークフローを効率化します。

初期ビルドパイプラインのタスクは、次のもので構成されます。

init: パイプラインを初期化し、再構築フラグと認証を設定して、PipelineRun のイメージリポジトリーシークレットを生成します。
clone-repository: 指定されたリポジトリーをワークスペースに複製し、git-clone タスクで実行できるように準備します。
build-container: このタスクは Buildah を使用してソースコードをコンテナーイメージに変換し、指定されたレジストリーにプッシュします。このタスクの主なアクションと結果は次のとおりです。
- コンテナーイメージの作成とデプロイメント: Buildah がソースコードをコンテナーイメージにコンパイルします。作成が成功すると、イメージが指定されたイメージレジストリーにプッシュされます。
- Software Bill of Materials (SBOM) の生成: 透明性とコンプライアンスを確保する一環として、コンテナーイメージに含まれるコンポーネント、ライブラリー、依存関係の詳細を示す SBOM が生成されます。この SBOM は最終的なコンテナーイメージ内に埋め込まれ、簡単にアクセスして検証できるようになります。
- SBOM の公開: このタスクでは、SBOM をコンテナーイメージに組み込むだけでなく、Cosign を使用して SBOM を独立したイメージとしてプッシュします。これにより、セキュリティーチームとコンプライアンスチームによる SBOM の管理と検証が容易になります。
- アーティファクトの作成: このタスクでは、イメージ署名 (.sig) やアテステーション (.att) などの重要なセキュリティーアーティファクトを生成します。これらのアーティファクトは、コンテナーイメージとそのコンテンツの整合性と信頼性を検証するために不可欠であり、デプロイメントパイプライン内で信頼性とセキュリティーを検証するための堅牢なメカニズムを提供します。
update-deployment: 新しくビルドされたイメージを使用してデプロイメント環境を更新します。この更新は、Overlay > Development ディレクトリーの GitOps リポジトリーで実行されます。
acs タスク: コードとデプロイメント設定のセキュリティー評価を実施し、確立されたセキュリティーポリシーとベストプラクティスに準拠していることを確認します。
show-sbom: アプリケーションで使用されるすべてのソフトウェアコンポーネントとライブラリーの包括的なリストを作成し、透明性を向上させ、脆弱性管理をサポートします。
summary: PipelineRun の概要を提供し、PipelineRun の情報を追加して、PipelineRun によって使用されるイメージリポジトリーシークレットを削除します。

注記

パイプライン実行内のタスクをクリックすると、タスクが正常に完了したときに生成されたログやその他の詳細にアクセスできます。正常に完了したタスクは、緑色のチェックで示されます。

4.4.1. Red Hat Advanced Cluster Security のタスク

RHTAP は、パイプライン内で Red Hat Advanced Cluster Security (RHACS) とそのセキュリティーチェックを活用します。RHACS がインストールおよび設定されている場合、パイプラインは RHACS タスク (roxctl image scan など) を実行します。完了すると緑色のチェックが表示されます。ただし、RHACS がインストールまたは設定されていない場合、パイプラインは RHACS タスクをスキップします。

注記

パイプライン内の RHACS タスクは、RHTAP のインストールプロセス中に RHACS をインストールおよび設定した場合にのみ、正常に実行します。RHACS のインストールの詳細な手順については、Red Hat Red Hat Advanced Cluster Security for Kubernetes のインストールを参照してください。
RHTAP のインストールプロセス中に RHACS をインストールおよび設定しなかった場合は、ACS の設定を参照してください。

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

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

roxctl image scan - イメージ内で検出されたコンポーネントと脆弱性を JSON 形式で返します。
roxctl image check - イメージに含まれるセキュリティーポリシーのビルド時の違反をチェックします。たとえば、'log4j の禁止' や、curl、wget、パッケージマネージャーが実稼働環境のイメージに含まれていないかどうかをチェックします。
roxctl deployment check - YAML デプロイメントファイルに含まれるセキュリティーポリシーのビルド時およびデプロイ時の違反をチェックします。

これらのタスクにより、開発段階からセキュリティーポリシーと設定を確実に遵守できます。

RHACS レポートの視覚化

Red Hat Developer Hub の CI タブの Pipeline Runs セクションには、構造化されたポップアップインターフェイスから詳細なタスクレポートにアクセスして解釈できる機能があります。ポップアップは次のセクションで構成されています。

Red Hat Advanced Cluster Security (RHACS タスクが利用可能かどうかに応じて条件付きで表示されます): このセクションには、イメージスキャン、イメージチェック、デプロイメントチェックなど、すべての RHACS タスク用の個別のタブが表示され、セキュリティー問題の最初の概要が表示されます。
Others: このセクションには、PipelineRun の結果 (IMAGE_URL、IMAGE_DIGEST など) が表示されます。このセクションは、ポップアップに複数のセクション (たとえば、Enterprise Contract または {RHRHACSLongName}) がある場合にのみ表示されます。

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

Catalog を選択し、RHACS レポートを確認する適切なコンポーネントを開きます。
CI タブ > Actions 列 > View output アイコンを選択し、ソフトウェアコンポーネントの詳細な RHACS レポートを確認します。
図4.3 詳細な RHACS レポート

注記

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

RHACS レポートの解釈

Red Hat Advanced Cluster Security (RHACS) タスクによって生成される詳細なレポートは、堅牢なセキュリティー体制を維持する上で重要なセキュリティーインサイトを提供するのに役立ちます。

roxctl image scan (イメージスキャン) レポートを解釈する方法の例を以下に示します。roxctl image check (イメージチェック) および roxctl deployment check (デプロイメントチェック) からのレポートを解釈する場合にも、同様のアプローチを適用できます。

脆弱性の内訳: RHACS は、検出された脆弱性を重大度別 (重大、重要、中程度、低)、ステータス別 (修正可能、修正不可能) に分類し、スキャン結果の概要を提供します。この分類には、分析された脆弱性とコンポーネントの総数と、Common Vulnerabilities and Exposures (CVE) が含まれます。
表示される詳細情報: レポートには、特定された脆弱性ごとに次の内容が含まれています。
- CVE ID: 脆弱性の一意の識別子。
- 重大度: 脆弱性によってもたらされる脅威のレベル。
- コンポーネント: 脆弱性の影響を受けるソフトウェアコンポーネント。
- コンポーネントバージョン: 影響を受けるコンポーネントのバージョン。
- 修復の提案: 脆弱性に対処するための推奨事項。該当する場合は、脆弱性が修正されたバージョンが含まれています。

4.4.2. SBOM について

show-sbom タスクは、コンポーネントが使用するすべてのソフトウェアライブラリーをリスト表示します。これにより、ソフトウェアサプライチェーンの透明性に貢献し、脆弱性の特定とセキュリティーへの影響の評価を容易にします。

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

SBOM の表示

手順

Catalog を選択し、SBOM を表示する適切なコンポーネントを開きます。
CI タブを選択し、リンクアイコンを選択します。SBOM タスクのログが表示されます。Web ブラウザーを使用して、ソフトウェアサプライチェーンの脆弱性を示す用語を SBOM ですぐに検索できます。たとえば、log4j を検索してみてください。
図4.5 SBOM の詳細

CLI での SBOM のダウンロード

前提条件

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

手順

正常に実行された適切なパイプライン実行を展開し、show-summary タスクを選択します。
SBOM イメージの URL を見つけてコピーし、ターミナルで次のコマンドを実行します。
cosign コマンドの例
```
$ cosign download sbom <the-sbom-url-you-copied>
```
1. (オプション) 完全な SBOM を検索可能な形式で表示するには、次のコマンドを実行して出力をリダイレクトします。
  cosign コマンドの例
```
$ cosign download sbom <the-sbom-url-you-copied> > sbom.txt
```

SBOM の確認

SBOM では、次の抜粋例に示すように、プロジェクトが使用する各ライブラリーの 4 つの特性を確認できます。

作成者または公開者
名前
バージョン
ライセンス

この情報は、個々のライブラリーが安全なソースからのものであり、更新済みで、コンプライアンスに準拠したものであることを確認するのに役立ちます。

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"
                    ...

第5章アプリケーションのデプロイとセキュリティーインサイトの表示

組織は、通常、開発、実稼働前、および実稼働の各段階を含む構造化されたアプローチを使用してアプリケーションをデプロイします。このプロセスは、多くの場合、自動化され、定義されたルールとトリガーによって管理されます。

このガイドでは、OpenShift GitOps で ArgoCD を介してアプリケーションをデプロイし、すべての段階で継続的デプロイメントを実現する方法を説明します。ArgoCD は、GitOps ベースのデプロイ戦略を促進し、Git リポジトリーを、インフラストラクチャー設定の信頼できる唯一の情報源として扱います。このリポジトリーを更新すると、環境全体のデプロイがトリガーされます。

注記

このガイドでは、デプロイ方法の例を示します。組織のワークフローに適した方法を採用してください。

5.1. ビルドを実稼働前の環境または実稼働環境にプロモートする

ある環境から別の環境 (開発環境からステージ環境または実稼働環境など) にビルドをプロモートするには、プルリクエスト (PR) を通じて GitOps リポジトリーを更新する必要があります。

RHDH プラットフォームで、Catalog を選択します。
Kind ドロップダウンリストから Resource を選択し、適切な GitOps リポジトリーを選択します。
Overview タブで、View Source を選択します。
(オプション) または、Catalog を選択し、Overview タブで View TechDocs を選択します。
1. Home > Repository セクションで、GitOps リポジトリーを選択します。
GitOps リポジトリーを複製し、component/<app-name> ディレクトリーに移動します。
注記
ローカルの複製が最新であることを確認してください。
新しいブランチをチェックアウトします。
リポジトリー内で、component/<app-name>/overlays ディレクトリーを見つけます。ここには、各環境に対応する development、stage、および prod サブディレクトリーがあります。

アプリケーションを、開発環境からステージ環境または実稼働環境に手動で移動します。

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

アプリケーションの移動先	実行する手順
開発環境からステージ環境	`development` ディレクトリーを展開し、`deployment-patch.yaml` を選択します。コンテナーイメージの URL をコピーします。たとえば、quay.io/<username>/<app-name>/imageurl です。 `stage` ディレクトリーに移動し、`deployment-patch.yaml` を選択して、既存のコンテナーイメージ URL を、コピーした URL に置き換えます。注記コンテナーイメージに加えて、その他の設定変更 (レプリカなど) を開発環境からステージ環境にプロモートする場合は、`development` ディレクトリーにある `deployment-patch.yaml` ファイルから変更内容をコピーし、`stage` ディレクトリーの `deployment-patch.yaml` ファイルに貼り付けてください。
ステージ環境から実稼働環境	`stage` ディレクトリーを展開し、`deployment-patch.yaml` を選択します。コンテナーイメージの URL をコピーします。たとえば、quay.io/<username>/<app-name>/imageurl です。 `prod` ディレクトリーに移動し、`deployment-patch.yaml` を選択して、既存のコンテナーイメージ URL を、コピーした URL に置き換えます。注記コンテナーイメージに加えて、その他の設定変更 (レプリカなど) をステージ環境から実稼働環境にプロモートする場合は、`stage` ディレクトリーにある `deployment-patch.yaml` ファイルから変更内容をコピーし、`prod` ディレクトリーの `deployment-patch.yaml` ファイルに貼り付けてください。

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

development ディレクトリーを展開し、deployment-patch.yaml を選択します。
コンテナーイメージの URL をコピーします。たとえば、quay.io/<username>/<app-name>/imageurl です。
stage ディレクトリーに移動し、deployment-patch.yaml を選択して、既存のコンテナーイメージ URL を、コピーした URL に置き換えます。

注記

コンテナーイメージに加えて、その他の設定変更 (レプリカなど) を開発環境からステージ環境にプロモートする場合は、development ディレクトリーにある deployment-patch.yaml ファイルから変更内容をコピーし、stage ディレクトリーの deployment-patch.yaml ファイルに貼り付けてください。

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

stage ディレクトリーを展開し、deployment-patch.yaml を選択します。
コンテナーイメージの URL をコピーします。たとえば、quay.io/<username>/<app-name>/imageurl です。
prod ディレクトリーに移動し、deployment-patch.yaml を選択して、既存のコンテナーイメージ URL を、コピーした URL に置き換えます。

注記

コンテナーイメージに加えて、その他の設定変更 (レプリカなど) をステージ環境から実稼働環境にプロモートする場合は、stage ディレクトリーにある deployment-patch.yaml ファイルから変更内容をコピーし、prod ディレクトリーの deployment-patch.yaml ファイルに貼り付けてください。

更新をコミットしてプッシュします。
プルリクエスト (PR) を作成します。この操作により、プロモーションパイプライン実行が開始し、更新されたコンテナーイメージが Red Hat Enterprise Contract (Enterprise Contract) のポリシーに照らして検証されます。パイプライン実行はすべてのタスクを視覚的に表します。緑色のステータスは正常に完了したことを示します。
1. RHDH 内の CI タブでプロモーションパイプラインを確認します。
PR を確認してマージします。PR をマージすると、ArgoCD がトリガーされ、ビルドを次の環境にプロモートするために必要な変更が自動的に適用されます。
1. RHDH 内の CD タブで最新のデプロイメント更新を確認します。アプリケーションの現在のステータス、デプロイメントの詳細、パイプライン実行の作成者、コミットメッセージ (ステージ環境から実稼働環境へのプロモートなど)、実稼働環境に進んだコンテナーイメージに関する更新が表示されます。

検証

アプリケーションのプロモートが成功したかどうかを評価するには、Topology タブに移動します。ここで、指定した名前空間全体のアプリケーションの配布状況を確認できます。

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

プロモーションパイプライン実行は、パイプライン内のすべてのタスクを視覚的に表します。緑色のステータスは、正常に完了したことを示しています。細かく監視する必要をなくし、ワークフローを効率化します。

プロモーションパイプラインのタスクは、次のもので構成されます。

clone-repository: 指定されたリポジトリーをワークスペースに複製し、git-clone タスクで実行できるように準備します。
gather-deploy-images: PR の変更に基づいて、スキャンするコンテナーイメージを検出します。
verify-enterprise-contract: 変更されたコンテナーイメージを検証します。このタスクにより、企業の標準ビルドシステムまたは承認済みのビルドシステムから生成されたイメージであることが確認されます。このタスクでは、Enterprise Contract (EC) ポリシーと Sigstore の cosign ツールを活用し、イメージ署名とアテステーションの整合性を評価します。

注記

パイプライン実行内のタスクをクリックすると、そのタスクに関連するログやその他の詳細にアクセスできます。

5.2.1. Enterprise Contract タスク

Enterprise Contract は、ソフトウェアサプライチェーンのセキュリティーを維持するために設計されたツール群です。コンテナーイメージのビルドおよびテスト方法に関するポリシーを定義および適用できます。

Enterprise Contract は、Red Hat Trusted Application Pipeline によって生成されたコンテナーイメージを実稼働環境にリリースする前に、イメージが明確に定義された要件を満たしていることを確認します。イメージが該当する基準を満たしていない場合、EC は対処する必要がある具体的な問題を概説したレポートを生成します。

Red Hat Trusted Application Pipeline のビルドプロセスでは、Tekton Chains を使用して、ビルドパイプラインの署名済みの in-toto アテステーションを作成します。次に、EC がこの署名済みのアテステーションを活用して、ビルドの整合性を暗号的に検証し、一連のポリシーに照らして評価します。これらのポリシーにより、規定されたベストプラクティスと組織固有のセキュリティーガイドラインにビルドプロセスが準拠していることが確認されます。

コンプライアンスレポートの解釈

Enterprise Contract (EC) スキャンによって生成される詳細なレポートは、堅牢なセキュリティー体制を維持する上で重要なセキュリティーインサイトを提供するのに役立ちます。このレポートを解釈する方法を以下に示します。

ポリシーコンプライアンスの概要: EC スキャンは、Supply Chain Levels for Software Artifacts (SLSA) セキュリティーフレームワークへのアプリケーションのコンプライアンスを評価します。レポートには、実行されたチェック、各チェックのステータス (成功、警告、失敗) がリスト表示され、観察された警告または失敗に関するメッセージが表示されます。
表示される詳細情報: ポリシーレポートの詳細:
- 成功したチェック: 満たされたポリシールールの数と詳細。
- 警告と失敗: 警告または失敗の原因となったポリシールールと、理由を説明するメッセージ。
- ルールへの準拠: ソースコードの参照やアテステーションチェックなど、アプリケーションが個々のポリシールールにどの程度準拠しているかの詳細。

図5.1 EC レポート

コンプライアンスレポートの詳細情報の活用

EC スキャンレポートから得られる詳細情報は、セキュリティーおよびコンプライアンスの取り組みの優先順位を付ける上で重要です。

ポリシーへの準拠の確認: SLSA およびその他の関連する標準への準拠を綿密に確認して、アプリケーションのインテグリティーを確保します。EC スキャンの推奨事項に従って、コンプライアンスのギャップに対処します。
レポート確認の効率化: レポート内に用意されているフィルターを使用して重要な領域に焦点を当てることで、確認プロセスの効率化を促進し、重要な問題やコンプライアンスのギャップを迅速に特定できます。

関連情報

EC ポリシーと設定の詳細は、Enterprise Contract によるコンプライアンスの管理を参照してください。

改訂日時: 2024-07-16

法律上の通知

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 Trusted Application Pipeline のスタートガイド

第1章 RHTAP の基礎について

1.1. セキュアな CI/CD フレームワーク

1.2. RHTAP のセキュリティーツールの詳細

1.3. すぐに使用できるソフトウェアテンプレートの活用

1.4. 主なセキュリティープラクティス

1.5. 今後の道筋

第2章 セキュアなアプリケーション開発に向けた準備

2.1. インストールの概要

2.2. 初期設定

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

3.1. 準備

3.2. アプリケーションの構築

アプリケーション情報の指定

アプリケーションリポジトリー情報の指定

デプロイメント情報の指定

3.3. アプリケーションの確認

3.4. アプリケーションの登録解除

第4章 コードを更新とセキュリティーインサイトの表示

4.1. コード更新の開始

4.2. コードの変更

4.3. パイプライン実行の表示

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

4.4.1. Red Hat Advanced Cluster Security のタスク

RHACS レポートの視覚化

RHACS レポートの解釈

4.4.2. SBOM について

SBOM の表示

CLI での SBOM のダウンロード

SBOM の確認

第5章 アプリケーションのデプロイとセキュリティーインサイトの表示

5.1. ビルドを実稼働前の環境または実稼働環境にプロモートする

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

5.2.1. Enterprise Contract タスク

コンプライアンスレポートの解釈

コンプライアンスレポートの詳細情報の活用

法律上の通知

詳細情報

試用、購入および販売

コミュニティー

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

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

会社概要

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links

第2章セキュアなアプリケーション開発に向けた準備

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

第4章コードを更新とセキュリティーインサイトの表示

第5章アプリケーションのデプロイとセキュリティーインサイトの表示