第3章 コンテナーのコンテンツ
3.1. コンテナー内のセキュリティー
アプリケーションとインフラストラクチャーは、すぐに利用可能なコンポーネントで構成されています。その多くは、Linux オペレーティングシステム、JBoss Web Server、PostgreSQL、および Node.js などのオープンソースパッケージです。
これらのパッケージのコンテナー化されたバージョンも利用可能ですが、パッケージの出所や、ビルドした人、パッケージの中に悪質なコードが含まれているかどうかを確認する必要があります。
確認するべき点には以下が含まれます。
- コンテナーの内容がインフラストラクチャーを危険にさらす可能性はあるか?
- アプリケーション層に既知の脆弱性が存在するか?
- ランタイムおよび OS 層は最新の状態か?
関連資料
『OpenShift Container Platform Using Images』
- これは、OpenShift Container Platform で使用するために Red Hat が提供するフレームワーク、データベース、およびサービスコンテナーイメージに関する参照ドキュメントです。
3.2. コンテナーのコンテンツのスキャン
コンテナースキャンツールは、継続的に更新される脆弱性のデータベースを利用して、コンテナーのコンテンツの既知の脆弱性についての最新情報を常に利用可能にします。既知の脆弱性についての一覧は絶えず変更されるため、コンテナーイメージの初回ダウンロード時にそれらのコンテンツについて確認し、承認済みおよびデプロイ済みのすべてのイメージの脆弱性について継続的に追跡する必要があります。
RHEL はプラグ可能な API を提供し、複数のスキャナーをサポートします。Red Hat CloudForms を OpenSCAP と共に使用して、コンテナーイメージをスキャンしてセキュリティー問題の有無を確認することもできます。RHEL での OpenSCAP についての一般的な情報は、『コンプライアンスおよび OpenSCAP を使った脆弱性のスキャン』を参照してください。また、OpenSCAP 統合の詳細については、『Red Hat CloudForms Policies and Profiles Guide』を参照してください。
OpenShift Container Platform では、このようなスキャナーを CI/CD プロセスで利用することができます。たとえば、ソースコードのセキュリティー上の欠陥をテストする静的コード解析ツールや、既知の脆弱性などのメタデータを提供する必要のあるオープンソースライブラリーを特定するソフトウェアコンポジション解析ツールを統合することができます。詳細については、「ビルドプロセス」で説明されています。
3.3. 外部のスキャンツールの OpenShift への統合
OpenShift Container Platform は、オブジェクトのアノテーション (object annotations) を利用して機能を拡張します。脆弱性スキャナーなどの外部ツールはイメージオブジェクトにメタデータのアノテーションを付けることで、結果の要約を表示したり、Pod の実行を制御したりできます。本セクションでは、このアノテーションの認識される形式について説明します。この形式を使用することで、アノテーションをコンソールで安全に使用し、ユーザーに役立つデータを表示することができます。
3.3.1. イメージのメタデータ
イメージの品質データには、パッケージの脆弱性およびオープンソースソフトウェア (OSS) ライセンスのコンプライアンスなどの様々なタイプがあります。さらに、複数のプロバイダーがこのメタデータを提供する場合があります。このため、以下のアノテーションの形式が保持されています。
quality.images.openshift.io/<qualityType>.<providerId>: {}| コンポーネント | 説明 | 許可される値 |
|---|---|---|
|
|
メタデータのタイプ |
|
|
|
プロバイダー ID の文字列 |
|
3.3.1.1. アノテーションキーの例
quality.images.openshift.io/vulnerability.blackduck: {}
quality.images.openshift.io/vulnerability.jfrog: {}
quality.images.openshift.io/license.blackduck: {}
quality.images.openshift.io/vulnerability.openscap: {}イメージの品質アノテーションの値は、以下の形式に従った構造化データになります。
| フィールド | 必須? | 説明 | タイプ |
|---|---|---|---|
|
|
Yes |
プロバイダーの表示名 |
文字列 |
|
|
Yes |
スキャンのタイムスタンプ |
文字列 |
|
|
No |
簡単な説明 |
文字列 |
|
|
Yes |
情報ソースの URL および/または詳細情報。ユーザーのデータ検証に必要。 |
文字列 |
|
|
No |
スキャナーバージョン |
文字列 |
|
|
No |
コンプライアンスに合格/不合格 |
ブール値 |
|
|
No |
検出された問題の要約 |
一覧 (以下の表を参照) |
summary フィールドは、以下の形式に従う必要があります。
| フィールド | 説明 | タイプ |
|---|---|---|
|
|
コンポーネントの表示ラベル (例: 「critical」、「important」、「moderate」、「low」または「health」) |
文字列 |
|
|
このコンポーネントのデータ (例: 検出された脆弱性の数またはスコア) |
文字列 |
|
|
順序付けおよびグラフィック表示の割り当てを可能にするコンポーネントのインデックス。値は |
整数 |
|
|
情報ソースの URL および/または詳細情報。これはオプションです。 |
文字列 |
3.3.1.2. アノテーション値の例
以下の例は、脆弱性の要約データおよびコンプライアンスのブール値を含むイメージの OpenSCAP アノテーションを示しています。
OpenSCAP アノテーション
{
"name": "OpenSCAP",
"description": "OpenSCAP vulnerability score",
"timestamp": "2016-09-08T05:04:46Z",
"reference": "https://www.open-scap.org/930492",
"compliant": true,
"scannerVersion": "1.2",
"summary": [
{ "label": "critical", "data": "4", "severityIndex": 3, "reference": null },
{ "label": "important", "data": "12", "severityIndex": 2, "reference": null },
{ "label": "moderate", "data": "8", "severityIndex": 1, "reference": null },
{ "label": "low", "data": "26", "severityIndex": 0, "reference": null }
]
}
以下の例は、詳細情報として外部 URL と健全性のインデックスデータを含むイメージの Red Hat Container Catalog アノテーションを示しています。
Red Hat Container Catalog アノテーション
{
"name": "Red Hat Container Catalog",
"description": "Container health index",
"timestamp": "2016-09-08T05:04:46Z",
"reference": "https://access.redhat.com/errata/RHBA-2016:1566",
"compliant": null,
"scannerVersion": "1.2",
"summary": [
{ "label": "Health index", "data": "B", "severityIndex": 1, "reference": null }
]
}
3.3.2. イメージオブジェクトのアノテーション
OpenShift Container Platform のエンドユーザーは イメージストリームオブジェクトに対して操作を行いますが、セキュリティーメタデータでアノテーションが付けられるのはイメージオブジェクトです。イメージオブジェクトはクラスター全体でそのスコープが設定され、多くのイメージストリームおよびタグで参照される可能性のある単一イメージをポイントします。
3.3.2.1. アノテーションが使用されている CLI コマンドの例
<image> をイメージダイジェストに置き換えます (例: sha256:fec8a395afe3e804b3db5cb277869142d2b5c561ebb517585566e160ff321988)。
$ oc annotate image <image> \
quality.images.openshift.io/vulnerability.redhatcatalog='{ \
"name": "Red Hat Container Catalog", \
"description": "Container health index", \
"timestamp": "2016-09-08T05:04:46Z", \
"compliant": null, \
"scannerVersion": "1.2", \
"reference": "https://access.redhat.com/errata/RHBA-2016:1566", \
"summary": "[ \
{ "label": "Health index", "data": "B", "severityIndex": 1, "reference": null } ]" }'3.3.3. Pod 実行の制御
イメージが実行するかどうかをプログラムで制御するには、images.openshift.io/deny-execution イメージポリシーを使用できます。詳細については、「イメージポリシー」を参照してください。
3.3.3.1. アノテーションの例
annotations: images.openshift.io/deny-execution: true
3.3.4. 統合リファレンス
ほとんどの場合、脆弱性スキャナーなどの外部ツールはイメージの更新を監視し、スキャンを実施し、関連するイメージオブジェクトに結果のアノテーションを付けるスクリプトまたはプラグインを開発します。この自動化では通常、OpenShift Container Platform REST API を呼び出してアノテーションを作成します。REST API およびイメージの更新に使用する PATCH 呼び出しについての一般的な情報は、『REST API Reference』 を参照してください。
3.3.4.1. REST API 呼び出しの例
curl を使用するこの呼び出しの例では、アノテーションの値を上書きします。<token>、<openshift_server>、<image_id>、および <image_annotation> の値を置き換えてください。
パッチ API 呼び出し
$ curl -X PATCH \
-H "Authorization: Bearer <token>" \
-H "Content-Type: application/merge-patch+json" \
https://<openshift_server>:8443/oapi/v1/images/<image_id> \
--data '{ <image_annotation> }'
以下は、PATCH ペイロードデータの例です。
パッチ呼び出しデータ
{
"metadata": {
"annotations": {
"quality.images.openshift.io/vulnerability.redhatcatalog":
"{ 'name': 'Red Hat Container Catalog', 'description': 'Container health index', 'timestamp': '2016-09-08T05:04:46Z', 'compliant': null, 'reference': 'https://access.redhat.com/errata/RHBA-2016:1566', 'summary': [{'label': 'Health index', 'data': '4', 'severityIndex': 1, 'reference': null}] }"
}
}
}
