検索

セキュリティーおよびコンプライアンス

download PDF
OpenShift Container Platform 4.13

OpenShift Container Platform のセキュリティーに関する理解および管理

Red Hat OpenShift Documentation Team

概要

このドキュメントでは、クラスターのセキュリティー保護に役立つコンテナーのセキュリティー、証明書の設定、および暗号の有効化を説明します。

第1章 OpenShift Container Platform のセキュリティーおよびコンプライアンス

1.1. セキュリティーの概要

OpenShift Container Platform クラスターの各種の側面を適切に保護する方法を理解しておくことが重要です。

コンテナーのセキュリティー

OpenShift Container Platform セキュリティーを理解するためのスタート地点として、コンテナーのセキュリティーについて の概念を確認すると良いでしょう。このセクションとこの後のセクションでは、OpenShift Container Platform で有効なコンテナーのセキュリティー対策に関する概要を説明します。これには、ホスト層、コンテナーとオーケストレーション層、およびビルドとアプリケーション層の各種ソリューションが含まれます。これらのセクションでは、以下のトピックについても説明します。

  • コンテナーのセキュリティーが重要である理由、および既存のセキュリティー標準との違い。
  • ホスト (RHCOS および RHEL) 層で提供されるコンテナーのセキュリティー対策と OpenShift Container Platform で提供されるコンテナーのセキュリティー対策。
  • 脆弱性についてコンテナーのコンテンツとソースを評価する方法。
  • コンテナーのコンテンツをプロアクティブに検査できるようにビルドおよびデプロイメントプロセスを設計する方法。
  • 認証および認可によってコンテナーへのアクセスを制御する方法。
  • OpenShift Container Platform でネットワークと割り当て済みストレージのセキュリティーを保護する方法。
  • API 管理および SSO のコンテナー化ソリューション。
監査

OpenShift Container Platform 監査は、システムに影響を与えた一連のアクティビティーを個別のユーザー、管理者その他システムのコンポーネント別に記述したセキュリティー関連の時系列のレコードを提供します。管理者は 監査ログポリシーの設定監査ログの表示 が可能です。

証明書

証明書は、クラスターへのアクセスを検証するためにさまざまなコンポーネントによって使用されます。管理者は、デフォルトの Ingress 証明書の置き換えAPI サーバー証明書の追加、または サービス証明書の追加 が可能です。

クラスターで使用される証明書の種類の詳細を確認することもできます。

データの暗号化

クラスターの etcd 暗号化を有効 にして、データセキュリティーのレイヤーを追加で提供することができます。たとえば、etcd バックアップが正しくない公開先に公開される場合に機密データが失われないように保護することができます。

脆弱性スキャン

管理者は Red Hat Quay Container Security Operator を使用して vulnerability scans を実行し、検出された脆弱性の情報を確認できます。

1.2. コンプライアンスの概要

多くの OpenShift Container Platform のお客様においては、システムが実稼働環境で使用される前に、一定レベルでの規制への対応またはコンプライアンスが必要になります。この規制対応は、国家標準、業界標準または組織の企業ガバナンスフレームワークによって課せられます。

コンプライアンスの確認

管理者は Compliance Operator を使用してコンプライアンススキャンを実行し、検出された問題の修復を提案できます。oc-compliance プラグイン は、Compliance Operator を簡単に操作するための一連のユーティリティーを提供する OpenShift CLI (oc) プラグインです。

ファイルの整合性チェック

管理者は File Integrity Operator を使用して、クラスターノードでファイルの整合性チェックを継続的に実行し、変更されたファイルのログを提供できます。

1.3. 関連情報

第2章 コンテナーのセキュリティー

2.1. コンテナーのセキュリティーについて

コンテナー化されたアプリケーションのセキュリティー保護においては、複数のセキュリティーレベルが関係します。

  • コンテナーのセキュリティーは、信頼できるベースコンテナーイメージから始まり、CI/CD パイプラインを通過するためにコンテナーのビルドプロセスまで適用されます。

    重要

    デフォルトでは、イメージストリームは自動的に更新されません。このデフォルトの動作では、イメージストリームによって参照されるイメージに対するセキュリティー更新は自動的に行われないため、セキュリティーの問題が発生する可能性があります。このデフォルト動作のオーバーライド方法の詳細は、イメージストリームタグの定期的なインポートの設定 を参照してください。

  • コンテナーがデプロイされると、そのセキュリティーはセキュアなオペレーティングシステムやネットワーク上で実行されているかどうかに依存し、コンテナー自体とこれと対話するユーザーやホスト間に明確な境界を確立することが必要です。
  • セキュリティーを継続して保護できるかどうかは、コンテナーイメージをスキャンして脆弱性の有無を確認でき、脆弱なイメージを効率的に修正し、置き換える効率的な方法があるかどうかに依存します。

OpenShift Container Platform などのプラットフォームが追加設定なしで提供する内容のほかに、各組織には独自のセキュリティー需要がある可能性があります。OpenShift Container Platform をデータセンターにデプロイする前にも、一定レベルのコンプライアンス検証が必要になる場合があります。

同様に、独自のエージェント、特殊ハードウェアドライバーまたは暗号化機能を OpenShift Container Platform に追加して組織のセキュリティー基準を満たす必要がある場合があります。

このガイドでは、OpenShift Container Platform で有効なコンテナーのセキュリティー対策に関する概要を説明します。これには、ホスト層、コンテナーとオーケストレーション層、およびビルドとアプリケーション層の各種ソリューションが含まれます。次に、これらのセキュリティー対策を実行するのに役立つ特定の OpenShift Container Platform ドキュメントを参照します。

このガイドには、以下の情報が記載されています。

  • コンテナーのセキュリティーが重要である理由、および既存のセキュリティー標準との違い。
  • ホスト (RHCOS および RHEL) 層で提供されるコンテナーのセキュリティー対策と OpenShift Container Platform で提供されるコンテナーのセキュリティー対策。
  • 脆弱性についてコンテナーのコンテンツとソースを評価する方法。
  • コンテナーのコンテンツをプロアクティブに検査できるようにビルドおよびデプロイメントプロセスを設計する方法。
  • 認証および認可によってコンテナーへのアクセスを制御する方法。
  • OpenShift Container Platform でネットワークと割り当て済みストレージのセキュリティーを保護する方法。
  • API 管理および SSO のコンテナー化ソリューション。

このガイドの目的は、コンテナー化されたワークロードに OpenShift Container Platform を使用するセキュリティー上の重要な利点と、Red Hat エコシステム全体がコンテナーのセキュリティーを確保し、維持する際にどのようなロールを果たしているかについて理解を促すことにあります。また、OpenShift Container Platform の使用により組織のセキュリティー関連の目標を達成する方法について理解するのに役立ちます。

2.1.1. コンテナーについて

コンテナーは、アプリケーションとそのすべての依存関係を 1 つのイメージにパッケージ化します。このイメージは、変更なしに開発環境からテスト環境、実稼働環境へとプロモートすることができます。コンテナーは、他のコンテナーと密接に動作する大規模なアプリケーションの一部である可能性があります。

コンテナーは、複数の環境、および物理サーバー、仮想マシン (VM)、およびプライベートまたはパブリッククラウドなどの複数のデプロイメントターゲット間に一貫性をもたらします。

コンテナーを使用するメリットには以下が含まれます。

インフラストラクチャーアプリケーション

共有される Linux オペレーティングシステムのカーネル上でのアプリケーションプロセスのサンドボックス化

アプリケーションとそのすべての依存関係のパッケージ化

仮想マシンを上回る単純化、軽量化、高密度化の実現

すべての環境に数秒でデプロイが可能。 CI/CD の実現

複数の異なる環境間での移植性

コンテナー化されたコンポーネントへのアクセスと共有が容易になる

Linux コンテナーの詳細は、Red Hat カスタマーポータル上にある Understanding Linux containers を参照してください。RHEL コンテナーの詳細は、RHEL 製品ドキュメントの Building, running, and managing containers を参照してください。

2.1.2. OpenShift Container Platform について

コンテナー化されたアプリケーションがデプロイされ、実行され、管理される方法を自動化することは、OpenShift Container Platform をはじめとするプラットフォームのジョブです。OpenShift Container Platform は、コアとして Kubernetes プロジェクトに依存し、スケーラブルなデータセンターの多数のノード間でコンテナーをオーケストレーションするエンジンを提供します。

Kubernetes は、複数の異なるオペレーティングシステムおよびアドオンのコンポーネントを使用して実行できるプロジェクトです。これらのオペレーティングシステムおよびアドオンコンポーネントは、プロジェクトでのサポート容易性を保証していません。そのため、Kubernetes プラットフォームによって、セキュリティーの内容が異なる可能性があります。

OpenShift Container Platform は、Kubernetes セキュリティーをロックダウンし、プラットフォームを各種の拡張コンポーネントと統合するように設計されています。このため、OpenShift Container Platform は、オペレーティングシステム、認証、ストレージ、ネットワーク、開発ツール、ベースコンテナーイメージ、その他の多くのコンポーネントを含む、各種オープンソース技術の大規模な Red Hat エコシステムを利用します。

OpenShift Container Platform には、プラットフォーム自体およびプラットフォーム上で実行されるコンテナー化されたアプリケーションの脆弱性の発見、およびその脆弱性に対する修正の迅速なデプロイにおける Red Hat の豊富な経験が最大限に活用されます。また、Red Hat は、新規コンポーネントが利用可能になる時点でそれらのコンポーネントを OpenShift Container Platform に効率的に統合し、各種テクノロジーをお客様の個々のニーズに適応させる点においても多くの経験があります。

2.2. ホストおよび仮想マシンのセキュリティーについて

コンテナーと仮想マシンはいずれも、ホストで実行されているアプリケーションをオペレーティングシステム自体から分離する方法を提供します。RHCOS (OpenShift Container Platform で使用されるオペレーティングシステム) に関する理解は、ホストシステムがコンテナーおよびホストを相互から保護する方法を確認する際に役立ちます。

2.2.1. Red Hat Enterprise Linux CoreOS (RHCOS) でのコンテナーのセキュリティー保護

コンテナーは、それぞれのコンテナーを起動するために同じカーネルおよびコンテナーランタイムを使用して、同じホストで実行される多数のアプリケーションのデプロイメントを単純化します。アプリケーションは多くのユーザーが所有できます。これらのアプリケーションを分離した状態に維持し、これらのアプリケーションの別々のバージョン、また互換性のないバージョンも問題なく同時に実行できるためです。

Linux では、コンテナーは特殊なタイプのプロセスに過ぎないため、コンテナーのセキュリティーを保護することは、他の実行中のプロセスのセキュリティーを保護することと同じです。コンテナーを実行する環境は、オペレーティングシステムで起動します。このオペレーティングシステムでは、ホストで実行しているコンテナーや他のプロセスからホストカーネルのセキュリティーを保護するだけでなく、複数のコンテナーのセキュリティーを相互から保護できる必要があります。

OpenShift Container Platform 4.13 は RHCOS ホストで実行され、Red Hat Enterprise Linux (RHEL) をワーカーノードとして使用するオプションが指定されるため、デフォルトで以下の概念がデプロイされた OpenShift Container Platform クラスターに適用されます。これらの RHEL セキュリティー機能は、OpenShift Container Platform で実行中のコンテナーのセキュリティーを強化するためのコアとなる機能です。

  • Linux namespace は特定のグローバルシステムリソースを抽象化し、これを namespace 内の複数のプロセスに対して分離したインスタンスとして表示できます。これにより、複数のコンテナーが競合せずに同じコンピューティングリソースを同時に使用することができます。デフォルトでホストから分離されているコンテナーの namespace には、マウントテーブル、プロセステーブル、ネットワークインターフェイス、ユーザー、コントロールグループ、UTS、および IPC namespace が含まれます。ホスト namespace に直接アクセスする必要のあるコンテナーには、そのアクセスを要求するために特権昇格が必要です。namespace のタイプの詳細は、RHEL 8 コンテナーのドキュメントの Overview of Containers in Red Hat Systems を参照してください。
  • SELinux はセキュリティーの層を追加し、コンテナーを相互に、またホストから分離させます。SELinux により、管理者は、それぞれのユーザー、アプリケーション、プロセスおよびファイルに対して強制アクセス制御 (MAC) を実施できます。
警告

RHCOS での SELinux の無効化はサポートされていません。

  • CGroup (コントロールグループ) はプロセスのコレクションに関するリソースの使用 (CPU、メモリー、ディスク I/O、ネットワークなど) を制限し、設定し、分離します。CGroup は、同じホスト上のコンテナーが相互に影響を与えないようにするために使用されます。
  • Secure computing mode (seccomp) プロファイルは、利用可能なシステム呼び出しを制限するためにコンテナーに関連付けることができます。seccomp の詳細は、OpenShift Security Guide の 94 ページを参照してください。
  • RHCOS を使用したコンテナーのデプロイは、ホスト環境を最小化してコンテナー向けに調整することで、攻撃される対象の規模を縮小します。CRI-O コンテナーエンジン は、デスクトップ指向のスタンドアロン機能を実装する他のコンテナーエンジンとは対照的に、Kubernetes および OpenShift Container Platform が必要とする機能のみを実装してコンテナーを実行し、管理することで、その攻撃対象領域をさらに削減します。

RHCOS は、OpenShift Container Platform クラスターでコントロールプレーン (マスター) およびワーカーノードとして機能するように特別に設定された Red Hat Enterprise Linux (RHEL) のバージョンです。そのため、RHCOS は、Kubernetes および OpenShift Container Platform サービスと共にコンテナーのワークロードを効率的に実行するように調整されます。

OpenShift Container Platform クラスターの RHCOS システムをさらに保護するには、ホストシステム自体の管理またはモニタリングを行うコンテナーを除き、ほとんどのコンテナーを root 以外のユーザーとして実行する必要があります。権限レベルを下げたり、付与する権限を可能な限り低くしてコンテナーを作成することが、独自の OpenShift Container Platform クラスターを保護する方法として推奨されます。

2.2.2. 仮想化とコンテナーの比較

従来の仮想化は、アプリケーション環境を同じ物理ホスト上で分離させた状態にするためのもう 1 つの方法です。ただし、仮想マシンはコンテナーとは異なる方法で動作します。仮想化は、ゲスト仮想マシン (VM) を起動するハイパーバイザーを使用します。 仮想マシンにはそれぞれ、実行中のカーネルで代表される独自のオペレーティングシステム (OS) のほか、実行されるアプリケーションとその依存関係があります。

仮想マシンの場合、ハイパーバイザーはゲスト同士を分離させ、ゲストをホストカーネルから分離します。ハイパーバイザーにアクセスする個々のユーザーおよびプロセスの数は少ないため、物理サーバーで攻撃される対象の規模が縮小します。ただし、この場合もセキュリティーの監視が依然として必要になります。あるゲスト仮想マシンがハイパーバイザーのバグを利用して、別の仮想マシンまたはホストカーネルにアクセスできる可能性があります。また、OS にパッチを当てる必要がある場合は、その OS を使用するすべてのゲスト仮想マシンにパッチを当てる必要があります。

コンテナーはゲスト仮想マシン内で実行可能であり、これが必要になる場合のユースケースもあるでしょう。たとえば、リフトアンドシフト方式でアプリケーションをクラウドに移行するなど、コンテナーに従来型のアプリケーションをデプロイする場合などです。

しかし、単一ホストでのコンテナーの分離は、柔軟性があり、スケーリングしやすいデプロイメントソリューションを提供します。このデプロイメントモデルは、クラウドネイティブなアプリケーションにとくに適しています。コンテナーは通常、仮想マシンよりもはるかに小さいため、メモリーと CPU の消費量が少なくなります。

コンテナーと仮想マシンの違いについては、RHEL 7 コンテナードキュメントの Linux Containers Compared to KVM Virtualization を参照してください。

2.2.3. OpenShift Container Platform のセキュリティー保護

OpenShift Container Platform をデプロイする際に、インストーラーでプロビジョニングされるインフラストラクチャー (利用可能ないくつかのプラットフォーム) またはユーザーによってプロビジョニングされるインフラストラクチャーを選択できます。初回の起動時に必要なカーネルモジュールの追加など、セキュリティーに関連する一部の低レベルの設定は、ユーザーによってプロビジョニングされるインフラストラクチャーの恩恵を受ける可能性があります。同様に、ユーザーによってプロビジョニングされるインフラストラクチャーは、非接続の OpenShift Container Platform デプロイメントに適しています。

セキュリティーが強化され、OpenShift Container Platform に他の設定変更が行われる場合、以下を含む目標を明確にするようにしてください。

  • 基礎となるノードを可能な限り汎用的な状態で維持する。同様のノードをすぐ、かつ指定した方法で破棄したり起動したりできるようにする必要があります。
  • ノードに対して直接的に 1 回限りの変更を行うのではなく、OpenShift Container Platform でのノードへの変更をできる限り管理する。

上記を目標とすると、ほとんどのノードの変更はインストール時に Ignition で行うか、Machine Config Operator によってノードのセットに適用される MachineConfig を使用して後で行う必要があります。この方法で実行できるセキュリティー関連の設定変更の例を以下に示します。

  • カーネル引数の追加
  • カーネルモジュールの追加
  • ディスク暗号化の設定
  • chrony タイムサービスの設定

Machine Config Operator のほかにも、Cluster Version Operator (CVO) によって管理される OpenShift Container Platform インフラストラクチャーの設定に使用できる他の Operator が複数あります。CVO は、OpenShift Container Platform クラスター更新の多くの部分を自動化できます。

2.3. RHCOS のハードニング

RHCOS は、OpenShift Container Platform にデプロイするように作成され、調整されました。RHCOS ノードへの変更はほとんど不要です。OpenShift Container Platform を採用するすべての組織には、システムハードニングに関する独自の要件があります。OpenShift 固有の変更および機能 (Ignition、ostree、読み取り専用 /usr など) が追加された RHEL システムとして、RHCOS を RHEL システムと同様に強化できます。ハードニングの管理方法には違いがあります。

OpenShift Container Platform およびその Kubernetes エンジンの主要機能は、必要に応じてアプリケーションおよびインフラストラクチャーを迅速にスケールアップおよびダウンできることです。避けられない状況でない限り、ホストにログインしてソフトウェアを追加したり設定を変更したりして RHCOS に直接変更を加える必要はありません。OpenShift Container Platform インストーラーおよびコントロールプレーンで RHCOS への変更を管理し、手動による介入なしに新規ノードを起動できるようにする必要があります。

そのため、独自のセキュリティー上のニーズに対応するために OpenShift Container Platform で RHCOS ノードをハードニングする場合、ハードニングする内容とハードニング方法の両方を考慮する必要があります。

2.3.1. RHCOS でのハードニングの内容の選択

RHEL 8 セキュリティー強化 ガイドでは、RHEL システムのセキュリティーのアプローチを説明しています。

このガイドでは、暗号化のアプローチ、脆弱性の評価方法、および各種サービスへの脅威の評価方法を説明します。また、コンプライアンス基準に関するスキャン、ファイルの整合性の確認、監査の実行、およびストレージデバイスの暗号化の方法を確認することができます。

ハードニングする機能の理解に基づいて、RHCOS でそれらをハードニングする方法を決定することができます。

2.3.2. RHCOS のハードニング方法の選択

OpenShift Container Platform での RHCOS システムの直接的な変更は推奨されません。代わりに、ワーカーノードやコントロールプレーンノードなどのノードのプールにあるシステムを変更することについて考慮する必要があります。新規ノードが必要な場合、ベアメタル以外のインストールでは、必要なタイプの新規ノードを要求でき、ノードは RHCOS イメージおよび先に行った変更に基づいて作成されます。

インストール前や、インストール時、およびクラスターの稼働後に RHCOS を変更することができます。

2.3.2.1. インストール前のハードニング

ベアメタルのインストールでは、OpenShift Container Platform のインストールを開始する前にハードニング機能を RHCOS に追加できます。たとえば、RHCOS インストーラーの起動時に、SELinux ブール型や対称マルチスレッドなどの各種の低レベル設定などのセキュリティー機能をオンまたはオフにするためにカーネルオプションを追加できます。

警告

RHCOS ノードでの SELinux の無効化はサポートされていません。

ベアメタル RHCOS のインストールの場合は難易度が上がりますが、この場合、OpenShift Container Platform インストールを開始する前にオペレーティングシステムの変更を取得することができます。これは、ディスクの暗号化や特別なネットワーク設定など、特定の機能を可能な限り早期に設定する必要がある場合に重要になります。

2.3.2.2. インストール時のハードニング

OpenShift Container Platform インストールプロセスを中断し、Ignition 設定を変更できます。Ignition 設定を使用して、独自のファイルおよび systemd サービスを RHCOS ノードに追加できます。また、インストールに使用する install-config.yaml ファイルに基本的なセキュリティー関連の変更を加えることもできます。この方法で追加した内容は、各ノードの初回起動時に利用できます。

2.3.2.3. クラスターの実行後のハードニング

OpenShift Container Platform クラスターの起動後にハードニング機能を RHCOS に適用する方法は複数あります。

  • デーモンセット: すべてのノードでサービスを実行する必要がある場合は、そのサービスを Kubernetes DaemonSet オブジェクト で追加できます。
  • マシン設定: MachineConfig オブジェクトには、同じ形式の Ignition 設定のサブセットが含まれます。マシン設定をすべてのワーカーノードまたはコントロールプレーンノードに適用することで、クラスターに追加される同じタイプの次のノードで同じ変更が適用されるようにできます。

ここで説明しているすべての機能は、OpenShift Container Platform の製品ドキュメントに記載されています。

2.4. コンテナーイメージの署名

Red Hat は、Red Hat Container Registry でイメージの署名を提供します。これらの署名は、Machine Config Operator (MCO) を使用して OpenShift Container Platform 4 クラスターにプルされる際に自動的に検証されます。

Quay.io は OpenShift Container Platform を設定するほとんどのイメージを提供し、リリースイメージのみが署名されます。リリースイメージは承認済みの OpenShift Container Platform イメージを参照するため、サプライチェーン攻撃からの一定レベルの保護が得られます。ただし、ロギング、モニタリング、サービスメッシュなどの OpenShift Container Platform への拡張の一部は、Operator Lifecycle Manager (OLM) から Operator として提供されます。それらのイメージは、Red Hat Ecosystem Catalog Container イメージ レジストリーから提供されます。

Red Hat レジストリーとインフラストラクチャー間のイメージの整合性を確認するには、署名の検証を有効にします。

2.4.1. Red Hat Container Registry の署名の検証の有効化

Red Hat Container レジストリーのコンテナー署名の検証を有効にするには、これらのレジストリーからのイメージを検証するキーを指定する署名検証ポリシーファイルを作成する必要があります。RHEL8 ノードの場合、レジストリーはデフォルトで /etc/containers/registries.d にすでに定義されています。

手順

  1. ワーカーノードに必要な設定を含む Butane 設定ファイル 51-worker-rh-registry-trust.bu を作成します。

    注記

    Butane の詳細は、「Butane を使用したマシン設定の作成」を参照してください。

    variant: openshift
    version: 4.13.0
    metadata:
      name: 51-worker-rh-registry-trust
      labels:
        machineconfiguration.openshift.io/role: worker
    storage:
      files:
      - path: /etc/containers/policy.json
        mode: 0644
        overwrite: true
        contents:
          inline: |
            {
              "default": [
                {
                  "type": "insecureAcceptAnything"
                }
              ],
              "transports": {
                "docker": {
                  "registry.access.redhat.com": [
                    {
                      "type": "signedBy",
                      "keyType": "GPGKeys",
                      "keyPath": "/etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release"
                    }
                  ],
                  "registry.redhat.io": [
                    {
                      "type": "signedBy",
                      "keyType": "GPGKeys",
                      "keyPath": "/etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release"
                    }
                  ]
                },
                "docker-daemon": {
                  "": [
                    {
                      "type": "insecureAcceptAnything"
                    }
                  ]
                }
              }
            }
  2. Butane を使用して、ワーカーノードのディスクに書き込まれるファイルが含まれるように、マシン設定 YAML ファイル 51-worker-rh-registry-trust.yaml を生成します。

    $ butane 51-worker-rh-registry-trust.bu -o 51-worker-rh-registry-trust.yaml
  3. 作成されたマシン設定を適用します。

    $ oc apply -f 51-worker-rh-registry-trust.yaml
  4. ワーカーマシン設定プールが新しいマシン設定でロールアウトされていることを確認します。

    1. 新しいマシン設定が作成されたことを確認します。

      $ oc get mc

      出力例

      NAME                                               GENERATEDBYCONTROLLER                      IGNITIONVERSION   AGE
      00-master                                          a2178ad522c49ee330b0033bb5cb5ea132060b0a   3.2.0             25m
      00-worker                                          a2178ad522c49ee330b0033bb5cb5ea132060b0a   3.2.0             25m
      01-master-container-runtime                        a2178ad522c49ee330b0033bb5cb5ea132060b0a   3.2.0             25m
      01-master-kubelet                                  a2178ad522c49ee330b0033bb5cb5ea132060b0a   3.2.0             25m
      01-worker-container-runtime                        a2178ad522c49ee330b0033bb5cb5ea132060b0a   3.2.0             25m
      01-worker-kubelet                                  a2178ad522c49ee330b0033bb5cb5ea132060b0a   3.2.0             25m
      51-master-rh-registry-trust                                                                   3.2.0             13s
      51-worker-rh-registry-trust                                                                   3.2.0             53s 1
      99-master-generated-crio-seccomp-use-default                                                  3.2.0             25m
      99-master-generated-registries                     a2178ad522c49ee330b0033bb5cb5ea132060b0a   3.2.0             25m
      99-master-ssh                                                                                 3.2.0             28m
      99-worker-generated-crio-seccomp-use-default                                                  3.2.0             25m
      99-worker-generated-registries                     a2178ad522c49ee330b0033bb5cb5ea132060b0a   3.2.0             25m
      99-worker-ssh                                                                                 3.2.0             28m
      rendered-master-af1e7ff78da0a9c851bab4be2777773b   a2178ad522c49ee330b0033bb5cb5ea132060b0a   3.2.0             8s
      rendered-master-cd51fd0c47e91812bfef2765c52ec7e6   a2178ad522c49ee330b0033bb5cb5ea132060b0a   3.2.0             24m
      rendered-worker-2b52f75684fbc711bd1652dd86fd0b82   a2178ad522c49ee330b0033bb5cb5ea132060b0a   3.2.0             24m
      rendered-worker-be3b3bce4f4aa52a62902304bac9da3c   a2178ad522c49ee330b0033bb5cb5ea132060b0a   3.2.0             48s 2

      1
      新しいマシン設定
      2
      新しいレンダリングされたマシン設定
    2. ワーカーマシン設定プールが新しいマシン設定で更新されていることを確認します。

      $ oc get mcp

      出力例

      NAME     CONFIG                                             UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
      master   rendered-master-af1e7ff78da0a9c851bab4be2777773b   True      False      False      3              3                   3                     0                      30m
      worker   rendered-worker-be3b3bce4f4aa52a62902304bac9da3c   False     True       False      3              0                   0                     0                      30m 1

      1
      UPDATING フィールドが True の場合、マシン設定プールは新しいマシン設定で更新されます。フィールドが False になると、ワーカーマシン設定プールが新しいマシン設定にロールアウトされます。
  5. クラスターが RHEL7 ワーカーノードを使用している場合、ワーカーマシンの設定プールが更新されたら、それらのノードに YAML ファイルを /etc/containers/registries.d ディレクトリーに作成します。これにより、特定のレジストリーサーバーの切り離された署名の場所が指定されます。次の例は、registry.access.redhat.com および registry.redhat.io でホストされているイメージに対してのみ機能します。

    1. 各 RHEL7 ワーカーノードへのデバッグセッションを開始します。

      $ oc debug node/<node_name>
    2. ルートディレクトリーを /host に変更します。

      sh-4.2# chroot /host
    3. 以下を含む /etc/containers/registries.d/registry.redhat.io.yaml ファイルを作成します。

      docker:
           registry.redhat.io:
               sigstore: https://registry.redhat.io/containers/sigstore
    4. 以下を含む /etc/containers/registries.d/registry.access.redhat.com.yaml ファイルを作成します。

      docker:
           registry.access.redhat.com:
               sigstore: https://access.redhat.com/webassets/docker/content/sigstore
    5. デバッグセッションを終了します。

2.4.2. 署名の検証設定の確認

マシン設定をクラスターに適用すると、Machine Config Controller は新規の MachineConfig オブジェクトを検出し、新規の rendered-worker-<hash> バージョンを生成します。

前提条件

  • マシン設定ファイルを使用して署名の検証を有効にしている。

手順

  1. コマンドラインで以下のコマンドを実行し、必要なワーカーの情報を表示します。

    $ oc describe machineconfigpool/worker

    初期ワーカーモニタリングの出力例

    Name:         worker
    Namespace:
    Labels:       machineconfiguration.openshift.io/mco-built-in=
    Annotations:  <none>
    API Version:  machineconfiguration.openshift.io/v1
    Kind:         MachineConfigPool
    Metadata:
      Creation Timestamp:  2019-12-19T02:02:12Z
      Generation:          3
      Resource Version:    16229
      Self Link:           /apis/machineconfiguration.openshift.io/v1/machineconfigpools/worker
      UID:                 92697796-2203-11ea-b48c-fa163e3940e5
    Spec:
      Configuration:
        Name:  rendered-worker-f6819366eb455a401c42f8d96ab25c02
        Source:
          API Version:  machineconfiguration.openshift.io/v1
          Kind:         MachineConfig
          Name:         00-worker
          API Version:  machineconfiguration.openshift.io/v1
          Kind:         MachineConfig
          Name:         01-worker-container-runtime
          API Version:  machineconfiguration.openshift.io/v1
          Kind:         MachineConfig
          Name:         01-worker-kubelet
          API Version:  machineconfiguration.openshift.io/v1
          Kind:         MachineConfig
          Name:         51-worker-rh-registry-trust
          API Version:  machineconfiguration.openshift.io/v1
          Kind:         MachineConfig
          Name:         99-worker-92697796-2203-11ea-b48c-fa163e3940e5-registries
          API Version:  machineconfiguration.openshift.io/v1
          Kind:         MachineConfig
          Name:         99-worker-ssh
      Machine Config Selector:
        Match Labels:
          machineconfiguration.openshift.io/role:  worker
      Node Selector:
        Match Labels:
          node-role.kubernetes.io/worker:
      Paused:                              false
    Status:
      Conditions:
        Last Transition Time:  2019-12-19T02:03:27Z
        Message:
        Reason:
        Status:                False
        Type:                  RenderDegraded
        Last Transition Time:  2019-12-19T02:03:43Z
        Message:
        Reason:
        Status:                False
        Type:                  NodeDegraded
        Last Transition Time:  2019-12-19T02:03:43Z
        Message:
        Reason:
        Status:                False
        Type:                  Degraded
        Last Transition Time:  2019-12-19T02:28:23Z
        Message:
        Reason:
        Status:                False
        Type:                  Updated
        Last Transition Time:  2019-12-19T02:28:23Z
        Message:               All nodes are updating to rendered-worker-f6819366eb455a401c42f8d96ab25c02
        Reason:
        Status:                True
        Type:                  Updating
      Configuration:
        Name:  rendered-worker-d9b3f4ffcfd65c30dcf591a0e8cf9b2e
        Source:
          API Version:            machineconfiguration.openshift.io/v1
          Kind:                   MachineConfig
          Name:                   00-worker
          API Version:            machineconfiguration.openshift.io/v1
          Kind:                   MachineConfig
          Name:                   01-worker-container-runtime
          API Version:            machineconfiguration.openshift.io/v1
          Kind:                   MachineConfig
          Name:                   01-worker-kubelet
          API Version:            machineconfiguration.openshift.io/v1
          Kind:                   MachineConfig
          Name:                   99-worker-92697796-2203-11ea-b48c-fa163e3940e5-registries
          API Version:            machineconfiguration.openshift.io/v1
          Kind:                   MachineConfig
          Name:                   99-worker-ssh
      Degraded Machine Count:     0
      Machine Count:              1
      Observed Generation:        3
      Ready Machine Count:        0
      Unavailable Machine Count:  1
      Updated Machine Count:      0
    Events:                       <none>

  2. oc describe コマンドを再度実行します。

    $ oc describe machineconfigpool/worker

    ワーカーの更新後の出力例

    ...
        Last Transition Time:  2019-12-19T04:53:09Z
        Message:               All nodes are updated with rendered-worker-f6819366eb455a401c42f8d96ab25c02
        Reason:
        Status:                True
        Type:                  Updated
        Last Transition Time:  2019-12-19T04:53:09Z
        Message:
        Reason:
        Status:                False
        Type:                  Updating
      Configuration:
        Name:  rendered-worker-f6819366eb455a401c42f8d96ab25c02
        Source:
          API Version:            machineconfiguration.openshift.io/v1
          Kind:                   MachineConfig
          Name:                   00-worker
          API Version:            machineconfiguration.openshift.io/v1
          Kind:                   MachineConfig
          Name:                   01-worker-container-runtime
          API Version:            machineconfiguration.openshift.io/v1
          Kind:                   MachineConfig
          Name:                   01-worker-kubelet
          API Version:            machineconfiguration.openshift.io/v1
          Kind:                   MachineConfig
          Name:                   51-worker-rh-registry-trust
          API Version:            machineconfiguration.openshift.io/v1
          Kind:                   MachineConfig
          Name:                   99-worker-92697796-2203-11ea-b48c-fa163e3940e5-registries
          API Version:            machineconfiguration.openshift.io/v1
          Kind:                   MachineConfig
          Name:                   99-worker-ssh
      Degraded Machine Count:     0
      Machine Count:              3
      Observed Generation:        4
      Ready Machine Count:        3
      Unavailable Machine Count:  0
      Updated Machine Count:      3
    ...

    注記

    Observed Generation パラメーターは、コントローラーで作成される設定の生成に基づいて増加するカウントを表示します。このコントローラーは、仕様の処理とリビジョンの生成に失敗する場合でも、この値を更新します。Configuration Source 値は 51-worker-rh-registry-trust 設定を参照します。

  3. 以下のコマンドを使用して、policy.json ファイルが存在することを確認します。

    $ oc debug node/<node> -- chroot /host cat /etc/containers/policy.json

    出力例

    Starting pod/<node>-debug ...
    To use host binaries, run `chroot /host`
    {
      "default": [
        {
          "type": "insecureAcceptAnything"
        }
      ],
      "transports": {
        "docker": {
          "registry.access.redhat.com": [
            {
              "type": "signedBy",
              "keyType": "GPGKeys",
              "keyPath": "/etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release"
            }
          ],
          "registry.redhat.io": [
            {
              "type": "signedBy",
              "keyType": "GPGKeys",
              "keyPath": "/etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release"
            }
          ]
        },
        "docker-daemon": {
          "": [
            {
              "type": "insecureAcceptAnything"
            }
          ]
        }
      }
    }

  4. 以下のコマンドを使用して、registry.redhat.io.yaml ファイルが存在することを確認します。

    $ oc debug node/<node> -- chroot /host cat /etc/containers/registries.d/registry.redhat.io.yaml

    出力例

    Starting pod/<node>-debug ...
    To use host binaries, run `chroot /host`
    docker:
         registry.redhat.io:
             sigstore: https://registry.redhat.io/containers/sigstore

  5. 以下のコマンドを使用して、registry.access.redhat.com.yaml ファイルが存在することを確認します。

    $ oc debug node/<node> -- chroot /host cat /etc/containers/registries.d/registry.access.redhat.com.yaml

    出力例

    Starting pod/<node>-debug ...
    To use host binaries, run `chroot /host`
    docker:
         registry.access.redhat.com:
             sigstore: https://access.redhat.com/webassets/docker/content/sigstore

2.4.3. 検証可能な署名がないコンテナーイメージの検証について

各 OpenShift Container Platform リリースイメージはイミュータブルであり、Red Hat プロダクションキーで署名されています。OpenShift Container Platform の更新またはインストール中に、検証可能な署名がないコンテナーイメージをリリースイメージがデプロイする可能性があります。各署名付きリリースイメージダイジェストはイミュータブルです。リリースイメージ内の各参照は、別のイメージのイミュータブルダイジェストに対するものであるため、コンテンツは推移的に信頼できます。言い換えれば、リリースイメージ上の署名は、すべてのリリース内容を検証します。

たとえば、検証可能な署名がないイメージ参照は、署名付き OpenShift Container Platform リリースイメージに含まれています。

リリース情報の出力例

$ oc adm release info  quay.io/openshift-release-dev/ ocp-release@sha256:2309578b68c5666dad62aed696f1f9d778ae1a089ee461060ba7b9514b7ca417 -o pullspec 1
quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:9aafb914d5d7d0dec4edd800d02f811d7383a7d49e500af548eab5d00c1bffdb 2

1
署名付きリリースイメージ SHA。
2
リリースに含まれる検証可能な署名がないコンテナーイメージ。
2.4.3.1. 更新時の自動検証

署名の検証は自動的に行われます。OpenShift Cluster Version Operator (CVO) は、OpenShift Container Platform の更新中にリリースイメージの署名を検証します。これは内部プロセスです。自動検証が失敗すると、OpenShift Container Platform のインストールまたは更新は失敗します。

署名の検証は、skopeo コマンドラインユーティリティーを使用して手動で行うこともできます。

2.4.3.2. skopeo を使用して Red Hat コンテナーイメージの署名を検証する

OpenShift Container Platform リリースイメージに含まれるコンテナーイメージの署名は、OCP リリースミラーサイト から署名を取得して検証できます。ミラーサイトの署名は Podman や CRI-O が理解できる形式ではないため、skopeo standalone-verify コマンドを使用して、リリースイメージが Red Hat によって署名されていることを確認します。

前提条件

  • skopeo コマンドラインユーティリティーがインストールされている。

手順

  1. 次のコマンドを実行して、リリースの完全な SHA を取得します。

    $ oc adm release info <release_version>  \ 1
    1
    <release_version> をリリース番号に置き換えます (例: 4.14.3)。

    出力の抜粋例

    ---
    Pull From: quay.io/openshift-release-dev/ocp-release@sha256:e73ab4b33a9c3ff00c9f800a38d69853ca0c4dfa5a88e3df331f66df8f18ec55
    ---

  2. 次のコマンドを実行して、Red Hat リリースキーをプルダウンします。

    $ curl -o pub.key https://access.redhat.com/security/data/fd431d51.txt
  3. 次のコマンドを実行して、検証する特定のリリースの署名ファイルを取得します。

    $ curl -o signature-1 https://mirror.openshift.com/pub/openshift-v4/signatures/openshift-release-dev/ocp-release/sha256%<sha_from_version>/signature-1 \ 1
    1
    <sha_from_version> を、リリースの SHA に一致するミラーサイトへの完全なリンクの SHA 値に置き換えます。たとえば、4.12.23 リリースの署名へのリンクは https://mirror.openshift.com/pub/openshift-v4/signatures/openshift-release-dev/ocp-release/sha256%e73ab4b33a9c3ff00c9f800a38d69853ca0c4dfa5a88e3df331f66df8f18ec55/signature-1、SHA 値は e73ab4b33a9c3ff00c9f800a38d69853ca0c4dfa5a88e3df331f66df8f18ec55 です。
  4. 次のコマンドを実行して、リリースイメージのマニフェストを取得します。

    $ skopeo inspect --raw docker://<quay_link_to_release> > manifest.json \ 1
    1
    <quay_link_to_release> を、oc adm release info コマンドの出力に置き換えます。たとえば、quay.io/openshift-release-dev/ocp-release@sha256:e73ab4b33a9c3ff00c9f800a38d69853ca0c4dfa5a88e3df331f66df8f18ec55 です。
  5. skopeo を使用して署名を検証します。

    $ skopeo standalone-verify manifest.json quay.io/openshift-release-dev/ocp-release:<release_number>-<arch> any signature-1 --public-key-file pub.key

    ここでは、以下のようになります。

    <release_number>
    リリース番号を指定します (例: 4.14.3)。
    <arch>

    アーキテクチャーを指定します (例: x86_64)。

    出力例

    Signature verified using fingerprint 567E347AD0044ADE55BA8A5F199E2F91FD431D51, digest sha256:e73ab4b33a9c3ff00c9f800a38d69853ca0c4dfa5a88e3df331f66df8f18ec55

2.4.4. 関連情報

2.5. コンプライアンスについて

多くの OpenShift Container Platform のお客様においては、システムが実稼働環境で使用される前に、一定レベルでの規制への対応またはコンプライアンスが必要になります。この規制対応は、国家標準、業界標準または組織の企業ガバナンスフレームワークによって課せられます。

2.5.1. コンプライアンスおよびリスク管理について

OpenShift Container Platform コンプライアンスフレームワークに関する Red Hat のアプローチは、OpenShift セキュリティーガイド のリスク管理および規制対応の章を参照してください。

2.6. コンテナーのコンテンツのセキュリティー保護

コンテナー内のコンテンツのセキュリティーを確保するには、まず信頼できるベースイメージ (Red Hat Universal Base Images など) を使用し、信頼できるソフトウェアを追加する必要があります。コンテナーイメージのセキュリティーを継続的に確認するには、Red Hat およびサードパーティーのツールの両方を使用してイメージをスキャンできます。

2.6.1. コンテナー内のセキュリティー

アプリケーションとインフラストラクチャーは、すぐに利用できるコンポーネントで構成されています。その多くは、Linux オペレーティングシステム、JBoss Web Server、PostgreSQL、および Node.js などのオープンソースパッケージです。

これらのパッケージのコンテナー化されたバージョンも利用できます。ただし、パッケージの出所や、ビルドした人、パッケージの中に悪質なコードが含まれているかどうかを確認する必要があります。

確認するべき点には以下が含まれます。

  • コンテナーの内容がインフラストラクチャーを危険にさらす可能性はあるか ?
  • アプリケーション層に既知の脆弱性が存在するか ?
  • ランタイムおよびオペレーティングシステム層は最新の状態にあるか ?

Red Hat Universal Base Images (UBI) でコンテナーをビルドすることにより、コンテナーイメージのベースが Red Hat Enterprise Linux に含まれる同じ RPM パッケージのソフトウェアで構成されるものであることを確認できます。UBI イメージの使用または再配布にサブスクリプションは必要ありません。

コンテナー自体のセキュリティーが継続的に保護されるようにするには、RHEL から直接使用されるか、OpenShift Container Platform に追加されているセキュリティースキャン機能は、使用しているイメージに脆弱性がある場合に警告を出します。OpenSCAP イメージスキャンは RHEL で利用でき、Red Hat Quay Container Security Operator は、OpenShift Container Platform で使用されるコンテナーイメージをチェックするために追加できます。

2.6.2. UBI を使用した再配布可能なイメージの作成

コンテナー化されたアプリケーションを作成するには、通常オペレーティングシステムによって提供されるコンポーネントを提供する信頼されたベースイメージの使用から開始します。これらには、ライブラリー、ユーティリティー、およびその他の機能が含まれます。これらは、アプリケーションがオペレーティングシステムのファイルシステムで認識することが予想されます。

Red Hat Universal Base Images (UBI) は、独自のコンテナーのビルドを試行される方に、まず Red Hat Enterprise Linux rpm パッケージやその他のコンテンツで作成されたコンテナーを使用するよう奨励するために作成されています。このような UBI イメージは、セキュリティーパッチを適用し、独自のソフトウェアを組み込むためにビルドされたコンテナーイメージと共に自由に使用し、再配布するために定期的に更新されます。

Red Hat Ecosystem Catalog を検索して、異なる UBI イメージを見つけ、そのイメージの正常性を確認します。セキュアなコンテナーイメージを作成する場合は、以下の 2 つの一般的な UBI イメージのタイプを使用することを検討できるかもしれません。

  • UBI: RHEL 7、8、9 の標準 UBI イメージ (ubi7/ubiubi8/ubiubi9/ubi) と、これらのシステムに基づく最小限のイメージ (ubi7/ubi-minimalubi8/ubi- mimimal、ubi9/ubi-minimal) があります。これらのイメージはすべて、標準の yum コマンドおよび dnf コマンドを使用して、ビルドするコンテナーイメージに追加できる RHEL ソフトウェアの空きのリポジトリーを参照するように事前に設定されています。Red Hat は、Fedora や Ubuntu などの他のディストリビューションでこのイメージを使用することを推奨しています。
  • Red Hat Software Collections: Red Hat Ecosystem Catalog で rhscl/ を検索し、特定タイプのアプリケーションのベースイメージとして使用するために作成されたイメージを見つけます。たとえば、Apache httpd (rhscl/httpd-*)、Python (rhscl/python-*)、Ruby (rhscl/ruby-*)、Node.js (rhscl/nodejs-*) および Perl (rhscl/perl-*) rhscl イメージがあります。

UBI イメージは自由に利用でき、再配布可能ですが、このイメージに対する Red Hat のサポートは、Red Hat 製品サブスクリプションでのみ利用できることに注意してください。

標準、最小および init UBI イメージを使用し、これを使用してビルドする方法は、Red Hat Enterprise Linux ドキュメントの Red Hat Universal Base イメージの使用 を参照してください。

2.6.3. RHEL におけるセキュリティースキャン

Red Hat Enterprise Linux (RHEL) システムでは、openscap-utils パッケージで OpenSCAP スキャンを利用できます。RHEL では、openscap-podman コマンドを使用して、イメージで脆弱性の有無をスキャンできます。Red Hat Enterprise Linux ドキュメントの Scanning containers and container images for vulnerabilities を参照してください。

OpenShift Container Platform では、RHEL スキャナーを CI/CD プロセスで利用することができます。たとえば、ソースコードのセキュリティー上の欠陥をテストする静的コード解析ツールや、既知の脆弱性などのメタデータを提供するために使用するオープンソースライブラリーを特定するソフトウェアコンポジション解析ツールを統合することができます。

2.6.3.1. OpenShift イメージのスキャン

OpenShift Container Platform で実行され、Red Hat Quay レジストリーからプルされるコンテナーイメージの場合、Operator を使用してそれらのイメージの脆弱性を一覧表示できます。Red Hat Quay Container Security Operator を OpenShift Container Platform に追加して、選択した namespace に追加されたイメージの脆弱性レポートを提供できます。

Red Hat Quay のコンテナーイメージスキャンは、Clair によって実行されます。Red Hat Quay では、Clair は RHEL、CentOS、Oracle、Alpine、Debian、および Ubuntu のオペレーティングシステムソフトウェアでビルドされたイメージの脆弱性を検索し、報告することができます。

2.6.4. 外部サービスの統合

OpenShift Container Platform は、オブジェクトのアノテーション (object annotations) を利用して機能を拡張します。脆弱性スキャナーなどの外部ツールはイメージオブジェクトにメタデータのアノテーションを付けることで、結果の要約を表示したり、Pod の実行を制御したりできます。このセクションでは、このアノテーションの認識される形式を説明します。この形式を使用することで、アノテーションをコンソールで安全に使用し、ユーザーに役立つデータを表示することができます。

2.6.4.1. イメージのメタデータ

イメージの品質データには、パッケージの脆弱性およびオープンソースソフトウェア (OSS) ライセンスのコンプライアンスなどの様々なタイプがあります。さらに、複数のプロバイダーがこのメタデータを提供する場合があります。このため、以下のアノテーションの形式が保持されます。

quality.images.openshift.io/<qualityType>.<providerId>: {}
表2.1 アノテーションキーの形式
コンポーネント説明許可される値

qualityType

メタデータのタイプ

vulnerability
license
operations
policy

providerId

プロバイダー ID の文字列

openscap
redhatcatalog
redhatinsights
blackduck
jfrog

2.6.4.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: {}

イメージの品質アノテーションの値は、以下の形式に従った構造化データになります。

表2.2 アノテーション値の形式
フィールド必須 ?説明タイプ

name

はい

プロバイダーの表示名

文字列

timestamp

はい

スキャンのタイムスタンプ

文字列

description

いいえ

簡単な説明

文字列

reference

はい

情報ソースの URL または詳細情報。ユーザーのデータ検証に必要。

文字列

scannerVersion

いいえ

スキャナーバージョン

文字列

compliant

いいえ

コンプライアンスの合否

ブール値

summary

いいえ

検出された問題の要約

リスト (以下の表を参照)

summary フィールドは、以下の形式に従う必要があります。

表2.3 要約フィールド値の形式
フィールド説明タイプ

label

コンポーネントの表示ラベル (例: "critical"、"important"、"moderate"、"low"、または "health")

文字列

data

このコンポーネントのデータ (例: 検出された脆弱性の数またはスコア)

文字列

severityIndex

順序付けおよびグラフィック表示の割り当てを可能にするコンポーネントのインデックス。値は 0..3 の範囲内にあり、0 = low になります。

整数

reference

情報ソースの URL または詳細情報。オプション。

文字列

2.6.4.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 Ecosystem Catalog のコンテナーイメージのセクション のアノテーションを示しています。

Red Hat Ecosystem Catalog アノテーション

{
  "name": "Red Hat Ecosystem 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 }
  ]
}

2.6.4.2. イメージオブジェクトのアノテーション

OpenShift Container Platform のエンドユーザーはイメージストリームオブジェクトに対して操作を行いますが、セキュリティーメタデータでアノテーションが付けられるのはイメージオブジェクトです。イメージオブジェクトはクラスター全体でそのスコープが設定され、多くのイメージストリームおよびタグで参照される可能性のある単一イメージをポイントします。

2.6.4.2.1. アノテーションが使用されている CLI コマンドの例

<image> をイメージダイジェストに置き換えます (例: sha256:401e359e0f45bfdcf004e258b72e253fd07fba8cc5c6f2ed4f4608fb119ecc2)。

$ oc annotate image <image> \
    quality.images.openshift.io/vulnerability.redhatcatalog='{ \
    "name": "Red Hat Ecosystem Catalog", \
    "description": "Container health index", \
    "timestamp": "2020-06-01T05:04:46Z", \
    "compliant": null, \
    "scannerVersion": "1.2", \
    "reference": "https://access.redhat.com/errata/RHBA-2020:2347", \
    "summary": "[ \
      { "label": "Health index", "data": "B", "severityIndex": 1, "reference": null } ]" }'
2.6.4.3. Pod 実行の制御

images.openshift.io/deny-execution イメージポリシーを使用して、イメージを実行するかどうかをプログラムで制御します。

2.6.4.3.1. アノテーションの例
annotations:
  images.openshift.io/deny-execution: true
2.6.4.4. 統合リファレンス

ほとんどの場合、脆弱性スキャナーなどの外部ツールはイメージの更新を監視し、スキャンを実施し、関連するイメージオブジェクトに結果のアノテーションを付けるスクリプトまたはプラグインを開発します。この自動化では通常、OpenShift Container Platform 4.13 REST API を呼び出してアノテーションを作成します。REST API の一般的な情報は、OpenShift Container Platform REST API を参照してください。

2.6.4.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>:6443/apis/image.openshift.io/v1/images/<image_id> \
  --data '{ <image_annotation> }'

以下は、PATCH ペイロードデータの例です。

パッチ呼び出しデータ

{
"metadata": {
  "annotations": {
    "quality.images.openshift.io/vulnerability.redhatcatalog":
       "{ 'name': 'Red Hat Ecosystem Catalog', 'description': 'Container health index', 'timestamp': '2020-06-01T05:04:46Z', 'compliant': null, 'reference': 'https://access.redhat.com/errata/RHBA-2020:2347', 'summary': [{'label': 'Health index', 'data': '4', 'severityIndex': 1, 'reference': null}] }"
    }
  }
}

2.7. コンテナーレジストリーのセキュアな使用

コンテナーレジストリーは、以下を実行するためにコンテナーイメージを保存します。

  • イメージに他からアクセスできるようにする
  • イメージをイメージの複数バージョンを含むことができるリポジトリーに整理する
  • オプションで、異なる認証方法に基づいてイメージへのアクセスを制限するか、イメージを一般に利用できるようにする。

Quay.io や Docker Hub などのパブリックコンテナーレジストリーがあり、ここでは多くの人や組織がイメージを共有します。Red Hat レジストリーは、サポート対象の Red Hat およびパートナーのイメージを提供しますが、Red Hat Ecosystem Catalog ではこれらのイメージに関する詳細な説明およびヘルスチェックが提供されます。独自のレジストリーを管理するには、Red Hat Quay などのコンテナーレジストリーを購入することができます。

セキュリティーの観点では、一部のレジストリーは、コンテナーの正常性を確認し、強化するために特別な機能を提供します。たとえば、Red Hat Quay は、Clair セキュリティースキャナーを使用したコンテナー脆弱性のスキャン、GitHub およびその他の場所でソースコードが変更された場合にイメージを自動的に再ビルドするためのビルドのトリガー、およびイメージへのアクセスをセキュア化するためのロールベースのアクセス制御 (RBAC) を使用できる機能を提供します。

2.7.1. コンテナーのソースの確認

ダウンロード済みかつデプロイ済みのコンテナーイメージのコンテンツをスキャンし、追跡するには各種のツールを使用できます。しかし、コンテナーイメージの公開ソースは数多くあります。公開されているコンテナーレジストリーを使用する場合は、信頼されるソースを使用して保護用の層を追加することができます。

2.7.2. イミュータブルで認定済みのコンテナー

イミュータブルなコンテナー を管理する際に、セキュリティー更新を使用することはとくに重要になります。イミュータブルなコンテナーは、実行中には変更されることのないコンテナーです。イミュータブルなコンテナーをデプロイする場合には、実行中のコンテナーにステップインして 1 つ以上のバイナリーを置き換えることはできません。運用上の観点では、更新されたコンテナーイメージを再ビルド、再デプロイし、コンテナーを変更するのではなく、コンテナーの置き換えを行います。

以下は、Red Hat 認定イメージの特徴になります。

  • プラットフォームの各種コンポーネントまたは層に既知の脆弱性がない。
  • ベアメタルからクラウドまで、RHEL プラットフォーム全体で互換性がある。
  • Red Hat によってサポートされる。

既知の脆弱性のリストは常に更新されるので、デプロイ済みのコンテナーイメージのコンテンツのほか、新規にダウンロードしたイメージを継続的に追跡する必要があります。Red Hat セキュリティーアドバイザリー (RHSA) を利用して、Red Hat 認定コンテナーイメージで新たに発見される問題に関する警告を受け、更新されたイメージを確認することができます。または、Red Hat Ecosystem Catalog にアクセスして、その問題および各 Red Hat イメージの他のセキュリティー関連の問題について検索することもできます。

2.7.3. Red Hat レジストリーおよび Ecosystem Catalog からのコンテナーの取得

Red Hat では、Red Hat Ecosystem Catalog の Container Images セクションから、Red Hat 製品およびパートナーオファリングの認定コンテナーイメージをリスト表示しています。このカタログから、CVE、ソフトウェアパッケージのリスト、ヘルススコアなどの各イメージの詳細を確認できます。

Red Hat イメージは、パブリックコンテナーレジストリー (registry.access.redhat.com) および認証されたレジストリー (registry.redhat.io) によって代表される、Red Hat レジストリー というレジストリーに実際に保存されます。どちらにも基本的に Red Hat サブスクリプション認証情報での認証を必要とするいくつかの追加イメージを含む registry.redhat.io と同様に、同じコンテナーイメージのセットが含まれます。

Red Hat ではコンテナーのコンテンツの脆弱性を監視し、コンテンツを定期的に更新しています。glibcDROWN、または Dirty Cow の修正など、Red Hat がセキュリティー更新をリリースする際に、影響を受けるすべてのコンテナーイメージも再ビルドされ、Red Hat Registry にプッシュされます。

Red Hat では health index を使用して、Red Hat Ecosystem Catalog 経由で提供される各コンテナーのセキュリティー上のリスクを考慮します。コンテナーは Red Hat およびエラータプロセスで提供されるソフトウェアを使用するため、セキュリティーのレベルは、コンテナーが古いと低くなり、新規のコンテナーの場合はセキュリティーのレベルが上がります。

コンテナーの年数について、Red Hat Ecosystem Catalog では格付けシステムを使用します。最新度の評価は、イメージに利用できる最も古く、最も重大度の高いセキュリティーエラータに基づいて行われます。格付けは "A" から "F" まであり、"A" が最新となります。この格付けシステムの詳細は、Container Health Index grades as used inside the Red Hat Ecosystem Catalog を参照してください。

Red Hat ソフトウェアに関連するセキュリティー更新および脆弱性の詳細は、Red Hat Product Security Center を参照してください。Red Hat セキュリティーアドバイザリー を参照して、特定のアドバイザリーおよび CVE を検索できます。

2.7.4. OpenShift Container レジストリー

OpenShift Container Platform には、コンテナーイメージを管理するために使用できるプラットフォームの統合されたコンポーネントとして実行される、プライベートレジストリーの OpenShift Container レジストリー が含まれます。OpenShift Container レジストリーは、ロールベースのアクセス制御を提供します。 これにより、どのコンテナーイメージを誰がプル/プッシュするのかを管理できるようになります。

また、OpenShift Container Platform は Red Hat Quay などのすでに使用している可能性のある他のプライベートレジストリーとの統合もサポートしています。

2.7.5. Red Hat Quay を使用したコンテナーの保存

Red Hat Quay は、Red Hat のエンタープライズレベルの品質の高いコンテナーレジストリー製品です。Red Hat Quay の開発は、アップストリームの Project Quay で行われます。Red Hat Quay は、オンプレミスまたは Quay.io のホスト型バージョンの Red Hat Quay でデプロイできます。

Red Hat Quay のセキュリティー関連機能には、以下が含まれます。

  • Time Machine (マシンの時間設定): 設定した期間またはユーザーが選択した有効期限に基づいて、古いタグを持つイメージの有効期限が切れるようにします。
  • Repository mirroring (リポジトリーのミラーリング): セキュリティー上の理由から他のレジストリーをミラーリングします。たとえば、会社のファイアウォールの背後の Red Hat Quay でパブリックリポジトリーをホストしたり、パフォーマンス上の理由からレジストリーを使用される場所の近くに配置したりします。
  • Action log storage (アクションログの保存): Red Hat Quay のロギング出力を Elasticsearch ストレージまたは Splunk に保存し、後に検索および分析に使用できるようにします。
  • Clair: 各コンテナーイメージの起点に基づき、さまざまな Linux 脆弱性データベースに対してイメージをスキャンします。
  • Internal authentication (内部認証): Red Hat Quay への RBAC 認証を処理するデフォルトのローカルデータベースを使用するか、LDAP、Keystone (OpenStack)、JWT Custom Authentication、または External Application Token 認証から選択します。
  • External authorization (OAuth) (外部認証 (OAuth): GitHub、GitHub Enterprise、または Google 認証からの Red Hat Quay への認証を許可します。
  • Access settings (アクセス設定): docker、rkt、匿名アクセス、ユーザー作成のアカウント、暗号化されたクライアントパスワード、または接頭辞、ユーザー名の自動補完での Red Hat Quay へのアクセスを可能にするトークンを生成します。

Red Hat Quay と OpenShift Container Platform の統合が継続されており、とくに関連する OpenShift Container Platform Operator との統合が継続されています。Quay Bridge Operator を使用すると、内部 OpenShift イメージレジストリーを Red Hat Quay に置き換えることができます。Red Hat Quay Container Security Operator を使用すると、Red Hat Quay レジストリーからプルされた OpenShift Container Platform で実行されているイメージの脆弱性を確認することができます。

2.8. ビルドプロセスのセキュリティー保護

コンテナー環境では、ソフトウェアのビルドプロセスはライフサイクルのステージであり、ここでは、アプリケーションコードが必要なランタイムライブラリーと統合されます。このビルドプロセスの管理は、ソフトウェアのスタックのセキュリティーを保護する上で鍵となります。

2.8.1. 1 回のビルドでどこにでもデプロイが可能

OpenShift Container Platform をコンテナービルドの標準プラットフォームとして使用することで、ビルド環境のセキュリティーを確保できます。「1 回のビルドでどこにでもデプロイが可能」という理念を背景に、ビルドプロセスの製品がそのままの状態で実稼働にデプロイされるようにすることができます。

コンテナーのイミュータブルな状態を維持することも重要です。実行中のコンテナーにパッチを当てることはできません。 その代わりに再ビルドおよび再デプロイを実行します。

ソフトウェアがビルド、テスト、および実稼働環境の複数ステージを通過する際に、ソフトウェアのサプライチェーンを設定するツールが信頼できるかどうかは重要です。以下の図は、コンテナー化されたソフトウェアの信頼できるソフトウェアサプライチェーンに組み込むことができるプロセスおよびツールを示しています。

OpenShift Container Platform は、セキュアなコードを作成し、管理できるように、信頼できるコードリポジトリー (GitHub など) および開発プラットフォーム (Che など) と統合できます。単体テストは、Cucumber および JUnit に依存する必要がある場合があります。コンテナーの脆弱性の有無や、Anchore または Twistlock などのコンプライアンス関連の問題の有無を検査し、AtomicScan または Clair などのイメージスキャンツールを使用できます。Sysdig などのツールは、コンテナー化されたアプリケーションの継続的なモニタリングを提供できます。

2.8.2. ビルドの管理

Source-to-Image (S2I) を使用して、ソースコードとベースイメージを組み合わせることができます。ビルダーイメージ は S2I を利用し、開発および運用チームの再現可能なビルド環境での協業を可能にします。Red Hat S2I イメージが Universal Base Image (UBI) イメージとして利用可能な場合、実際の RHEL RPM パッケージからビルドされたベースイメージでソフトウェアを自由に再配布できます。Red Hat は、これを可能にするためにサブスクリプションの制限を削除しました。

開発者がビルドイメージを使用して、アプリケーション用に Git でコードをコミットする場合、OpenShift Container Platform は以下の機能を実行できます。

  • コードリポジトリーの Webhook または他の自動化された継続的インテグレーション (CI) プロセスのいずれかで、利用可能なアーティファクト、S2I ビルダーイメージ、および新たにコミットされたコードを使用して新規イメージの自動アセンブルをトリガーします。
  • 新規にビルドしたイメージを自動的にデプロイし、テストします。
  • テスト済みのイメージを実稼働にプロモートします。 ここでは CI プロセスを使用して自動的にデプロイされます。
Source-to-Image (S2I) ビルド

統合された OpenShift Container レジストリーを使用して、最終イメージへのアクセスを管理できます。S2I イメージおよびネイティブビルドイメージの両方は OpenShift Container レジストリーに自動的にプッシュされます。

CI の組み込まれた Jenkins のほかに、独自のビルドおよび CI 環境を RESTful API および API 準拠のイメージレジストリーを使用して OpenShift Container Platform に統合することもできます。

2.8.3. ビルド時の入力のセキュリティー保護

シナリオによっては、ビルド操作において、依存するリソースにアクセスするために認証情報が必要になる場合がありますが、この認証情報をビルドで生成される最終的なアプリケーションイメージで利用可能にすることは適切ではありません。このため、入力シークレットを定義することができます。

たとえば、Node.js アプリケーションのビルド時に、Node.js モジュールのプライベートミラーを設定できます。プライベートミラーからモジュールをダウンロードするには、URL、ユーザー名、パスワードを含む、ビルド用のカスタム .npmrc ファイルを指定する必要があります。セキュリティー上の理由により、認証情報はアプリケーションイメージで公開しないでください。

この例で示したシナリオを使用して、入力シークレットを新規の BuildConfig オブジェクトに追加できます。

  1. シークレットがない場合は作成します。

    $ oc create secret generic secret-npmrc --from-file=.npmrc=~/.npmrc

    これにより、secret-npmrc という名前の新規シークレットが作成されます。 これには、~/.npmrc ファイルの base64 でエンコードされたコンテンツが含まれます。

  2. シークレットを既存の BuildConfig オブジェクトの source セクションに追加します。

    source:
      git:
        uri: https://github.com/sclorg/nodejs-ex.git
      secrets:
      - destinationDir: .
        secret:
          name: secret-npmrc
  3. シークレットを新規の BuildConfig オブジェクトに追加するには、以下のコマンドを実行します。

    $ oc new-build \
        openshift/nodejs-010-centos7~https://github.com/sclorg/nodejs-ex.git \
        --build-secret secret-npmrc

2.8.4. ビルドプロセスの設計

コンテナーの層を使用できるようにコンテナーイメージ管理およびビルドプロセスを設計して、制御を分離可能にすることができます。

ビルドプロセスの設計

たとえば、運用チームはベースイメージを管理します。一方で、アーキテクトはミドルウェア、ランタイム、データベース、その他のソリューションを管理します。これにより、開発者はアプリケーション層のみを使用し、コードの作成に集中することができます。

新しい脆弱性情報は常に更新されるので、コンテナーのコンテンツを継続的かつプロアクティブに確認する必要があります。これを実行するには、自動化されたセキュリティーテストをビルドまたは CI プロセスに統合する必要があります。以下に例を示します。

  • SAST / DAST – 静的および動的なセキュリティーテストツール
  • 既知の脆弱性をリアルタイムにチェックするためのスキャナー。このようなツールは、コンテナー内のオープンソースパッケージをカタログ化し、既知の脆弱性について通知し、スキャン済みのパッケージに新たな脆弱性が検出されるとその更新情報を送信します。

CI プロセスには、セキュリティースキャンで発見される問題について担当チームが適切に対処できるように、これらの問題のフラグをビルドに付けるポリシーを含める必要があります。カスタマイズしたコンテナーに署名することで、ビルドとデプロイメント間に改ざんが発生しないようにします。

GitOps の方法を使用すると、同じ CI/CD メカニズムを使用してアプリケーションの設定だけでなく、OpenShift Container Platform インフラストラクチャーも管理できます。

2.8.5. Knative サーバーレスアプリケーションのビルド

Kubernetes と Kourier を利用すると、OpenShift Container Platform で OpenShift Serverless を使用して、サーバーレスアプリケーションを構築、デプロイ、管理できます。

他のビルドと同様に、S2I イメージを使用してコンテナーをビルドしてから、Knative サービスを使用してそれらを提供できます。OpenShift Container Platform Web コンソールの Topology ビューを使用して Knative アプリケーションのビルドを表示します。

2.8.6. 関連情報

2.9. コンテナーのデプロイ

各種の手法を使用して、デプロイするコンテナーが最新の実稼働に適した品質のコンテンツを保持し、改ざんされていないことを確認することができます。これらの手法には、最新のコードを組み込むためのビルドトリガーのセットアップやコンテナーが信頼できるソースから取得され、変更されないようにするための署名の使用が含まれます。

2.9.1. トリガーによるコンテナーデプロイメントの制御

ビルドプロセスで何らかの問題が生じる場合や、イメージのデプロイ後に脆弱性が発見される場合に、自動化されるポリシーベースのデプロイのためのツールを使用して修復できます。イメージの再ビルドおよび置き換えはトリガーを使用して実行し、イミュータブルなコンテナーのプロセスを確認できます。 実行中のコンテナーにパッチを当てる方法は推奨されていません。

セキュアなデプロイメント

たとえば、3 つのコンテナーイメージ層 (コア、ミドルウェア、アプリケーション) を使用してアプリケーションをビルドするとします。コアイメージに問題が見つかり、そのイメージは再ビルドされました。ビルドが完了すると、イメージは OpenShift Container レジストリーにプッシュされます。OpenShift Container Platform はイメージが変更されたことを検知し、定義されたトリガーに基づいてアプリケーションイメージを自動的に再ビルドし、デプロイします。この変更には修正されたライブラリーが組み込まれ、実稼働コードが最新のイメージと同じ状態になります。

oc set triggers コマンドを使用してデプロイメントトリガーを設定できます。たとえば、deployment-example という名前のデプロイメントのトリガーを設定するには、以下を実行します。

$ oc set triggers deploy/deployment-example \
    --from-image=example:latest \
    --containers=web

2.9.2. イメージソースのデプロイの制御

重要な点として、対象とするイメージが実際にデプロイされていることや、組み込まれているコンテンツを持つイメージが信頼されるソースからのものであること、またそれらが変更されていないことを確認できる必要があります。これは、暗号による署名を使用して実行できます。OpenShift Container Platform では、クラスター管理者がデプロイメント環境とセキュリティー要件を反映した (広義または狭義のものを含む) セキュリティーポリシーを適用できます。このポリシーは、以下の 2 つのパラメーターで定義されます。

  • 1 つ以上のレジストリー (オプションのプロジェクト namespace を使用)
  • 信頼タイプ (accept、reject、または require public key(s))

これらのポリシーパラメーターを使用して、レジストリー全体、レジストリーの一部、または個別のイメージに対して信頼関係を許可、拒否、または要求することができます。信頼されたパブリックキーを使用して、ソースが暗号で検証されていることを確認できます。このポリシールールはノードに適用されます。ポリシーは、すべてのノード全体に均一に適用されるか、異なるノードのワークロード (例: ビルド、ゾーン、または環境) ごとにターゲットが設定される場合があります。

イメージ署名ポリシーファイルの例

{
    "default": [{"type": "reject"}],
    "transports": {
        "docker": {
            "access.redhat.com": [
                {
                    "type": "signedBy",
                    "keyType": "GPGKeys",
                    "keyPath": "/etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release"
                }
            ]
        },
        "atomic": {
            "172.30.1.1:5000/openshift": [
                {
                    "type": "signedBy",
                    "keyType": "GPGKeys",
                    "keyPath": "/etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release"
                }
            ],
            "172.30.1.1:5000/production": [
                {
                    "type": "signedBy",
                    "keyType": "GPGKeys",
                    "keyPath": "/etc/pki/example.com/pubkey"
                }
            ],
            "172.30.1.1:5000": [{"type": "reject"}]
        }
    }
}

ポリシーは /etc/containers/policy.json としてノードに保存できます。このファイルのノードへの保存は、新規の MachineConfig オブジェクトを使用して実行するのが最適な方法です。この例では、以下のルールを実施しています。

  • Red Hat レジストリー (registry.access.redhat.com) からのイメージは Red Hat パブリックキーで署名される必要がある。
  • openshift namespace 内の OpenShift Container レジストリーからのイメージは Red Hat パブリックキーで署名される必要がある。
  • production namespace 内の OpenShift Container レジストリーからのイメージは example.com のパブリックキーで署名される必要がある。
  • グローバルの default 定義で指定されていないその他すべてのレジストリーは拒否される。

2.9.3. 署名トランスポートの使用

署名トランスポートは、バイナリーの署名 Blob を保存および取得する方法です。署名トランスポートには、2 つのタイプあります。

  • atomic: OpenShift Container Platform API で管理される。
  • docker: ローカルファイルとして提供されるか、Web サーバーによって提供される。

OpenShift Container Platform API は、atomic トランスポートタイプを使用する署名を管理します。このタイプの署名を使用するイメージは OpenShift Container レジストリーに保存する必要があります。docker/distribution extensions API はイメージ署名のエンドポイントを自動検出するため、追加の設定は不要になります。

docker トランスポートタイプを使用する署名は、ローカルファイルまたは Web サーバーによって提供されます。これらの署名には柔軟性があります。任意のコンテナーレジストリーからイメージを提供でき、バイナリー署名の送信に個別のサーバーを使用することができます。

ただし、docker トランスポートタイプの場合には追加の設定が必要です。任意に名前が付けられた YAML ファイルをホストシステムのディレクトリー (/etc/containers/registries.d) にデフォルトとして配置し、ノードを署名サーバーの URI で設定する必要があります。YAML 設定ファイルには、レジストリー URI および署名サーバー URI が含まれます。 署名サーバー URI は、sigstore とも呼ばれます。

registries.d ファイルの例

docker:
    access.redhat.com:
        sigstore: https://access.redhat.com/webassets/docker/content/sigstore

この例では、Red Hat レジストリー (access.redhat.com) は、docker タイプのトランスポートの署名を提供する署名サーバーです。Red Hat レジストリーの URI は、sigstore パラメーターで定義されます。このファイルに /etc/containers/registries.d/redhat.com.yaml という名前を付け、Machine Config Operator を使用してこのファイルをクラスター内の各ノード上に自動的に配置することができます。ポリシーと registries.d ファイルはコンテナーのランタイムで動的に読み込まれるため、サービスを再起動する必要はありません。

2.9.4. シークレットおよび config map の作成

Secret オブジェクトタイプはパスワード、OpenShift Container Platform クライアント設定ファイル、dockercfg ファイル、プライベートソースリポジトリーの認証情報などの機密情報を保持するメカニズムを提供します。シークレットは機密内容を Pod から切り離します。シークレットはボリュームプラグインを使用してコンテナーにマウントすることも、システムが Pod の代わりにシークレットを使用して各種アクションを実行することもできます。

たとえば、プライベートイメージリポジトリーにアクセスできるように、シークレットをデプロイメント設定に追加するには、以下を実行します。

手順

  1. OpenShift Container Platform Web コンソールにログインします。
  2. 新規プロジェクトを作成します。
  3. ResourcesSecrets に移動し、新規シークレットを作成します。Secret TypeImage Secret に、Authentication TypeImage Registry Credentials に設定し、プライベートイメージリポジトリーにアクセスするために必要な認証情報を入力します。
  4. デプロイメント設定を作成する場合 (例: Add to ProjectDeploy Image ページに移動する)、Pull Secret を新規シークレットに設定します。

config map はシークレットに似ていますが、機密情報を含まない文字列の使用をサポートするように設計されています。ConfigMap オブジェクトは、Pod で使用したり、コントローラーなどのシステムコンポーネントの設定データを保存するために使用できる設定データのキーと値のペアを保持します。

2.9.5. 継続的デプロイメントの自動化

独自の継続的デプロイメント (CD) のツールを OpenShift Container Platform に統合することができます。

CI/CD および OpenShift Container Platform を利用することで、アプリケーションの再ビルドプロセスを自動化し、最新の修正の組み込み、テスト、および環境内の至るところでのデプロイを可能にします。

2.10. コンテナープラットフォームのセキュリティー保護

OpenShift Container Platform および Kubernetes API は、スケーリング時にコンテナー管理を自動化する鍵となります。API は以下の目的で使用されます。

  • Pod、サービス、およびレプリケーションコントローラーのデータの検証および設定。
  • 受信要求におけるプロジェクト検証の実施と、他の主要なシステムコンポーネントでのトリガーの呼び出し。

Kubernetes をベースとする OpenShift Container Platform のセキュリティー関連機能には、以下が含まれます。

  • マルチテナンシー: ロールベースのアクセス制御とネットワークポリシーを統合し、複数のレベルでコンテナーを分離します。
  • API と API の要求側との間の境界を形成する受付プラグイン。

OpenShift Container Platform は Operator を使用して Kubernetes レベルのセキュリティー機能の管理を自動化し、単純化します。

2.10.1. マルチテナンシーによるコンテナーの分離

マルチテナンシーは、複数のユーザーによって所有され、複数のホストおよび namespace で実行される OpenShift Container Platform クラスターの複数アプリケーションが、相互に分離された状態のままにし、外部の攻撃から隔離された状態にすることができます。ロールベースアクセス制御 (RBAC) を Kubernetes namespace に適用して、マルチテナンシーを取得します。

Kubernetes では、namespace はアプリケーションを他のアプリケーションと分離した状態で実行できるエリアです。OpenShift Container Platform は、SELinux の MCS ラベルを含む追加のアノテーションを追加して namespace を使用し、これを拡張し、これらの拡張された namespace を プロジェクト として特定します。プロジェクトの範囲内で、ユーザーは、サービスアカウント、ポリシー、制約、およびその他のオブジェクトなど、独自のクラスターリソースを維持できます。

RBAC オブジェクトはプロジェクトに割り当てられ、選択されたユーザーのそれらのプロジェクトへのアクセスを認可します。この認可には、ルール、ロール、およびバインディングの形式が使用されます。

  • ルールは、ユーザーがプロジェクト内で作成またはアクセスできるものを定義します。
  • ロールは、選択されたユーザーまたはグループにバインドできるルールのコレクションです。
  • バインディングは、ユーザーまたはグループとロール間の関連付けを定義します。

ローカル RBAC ロールおよびバインディングは、ユーザーまたはグループを特定のプロジェクトに割り当てます。クラスター RBAC では、クラスター全体のロールおよびバインディングをクラスターのすべてのプロジェクトに割り当てることができます。adminbasic-usercluster-admin、および cluster-status アクセスを提供するために割り当てることのできるデフォルトのクラスターロールがあります。

2.10.2. 受付プラグインでのコントロールプレーンの保護

RBAC はユーザーおよびグループと利用可能なプロジェクト間のアクセスルールを制御しますが、受付プラグイン は OpenShift Container Platform マスター API へのアクセスを定義します。受付プラグインは、以下で構成されるルールのチェーンを形成します。

  • デフォルトの受付プラグイン: これは、OpenShift Container Platform コントロールプレーンのコンポーネントに適用されるポリシーおよびリソース制限のデフォルトセットを実装します。
  • ミューティングアドミッションプラグイン: これらのプラグインは、アドミッションチェーンを動的に拡張します。これらは Webhook サーバーに対する呼び出しを実行し、要求の認証および選択されたリソースの変更の両方を実行します。
  • 検証用の受付プラグイン: 選択されたリソースの要求を検証し、要求を検証すると共にリソースが再度変更されないようにすることができます。

API 要求はチェーン内の受付プラグインを通過し、途中で失敗した場合には要求が拒否されます。それぞれの受付プラグインは特定のリソースに関連付けられ、それらのリソースの要求にのみ応答します。

2.10.2.1. Security Context Constraints (SCC)

Security Context Constraints (SCC) を使用して、Pod のシステムでの受け入れを可能にするために Pod の実行時に必要となる一連の条件を定義することができます。

以下は、SCC で管理できる分野の一部です。

  • 特権付きコンテナーの実行
  • コンテナーが要求できる機能の追加
  • ホストディレクトリーのボリュームとしての使用
  • コンテナーの SELinux コンテキスト
  • コンテナーのユーザー ID

必要なパーミッションがある場合は、必要に応じてデフォルトの SCC ポリシーの許容度を上げるように調整することができます。

2.10.2.2. ロールのサービスアカウントへの付与

ロールは、ユーザーにロールベースのアクセスを割り当てるのと同じ方法で、サービスアカウントに割り当てることができます。各プロジェクトに 3 つのデフォルトサービスアカウントが作成されます。サービスアカウント:

  • スコープが特定プロジェクトに制限される
  • その名前はそのプロジェクトから派生している。
  • OpenShift Container レジストリーにアクセスするために API トークンおよび認証情報が自動的に割り当てられる。

プラットフォームのコンポーネントに関連付けられたサービスアカウントでは、キーが自動的にローテーションされます。

2.10.3. 認証および認可

2.10.3.1. OAuth を使用したアクセスの制御

コンテナープラットフォームのセキュリティーを保護にするために、認証および承認で API アクセス制御を使用することができます。OpenShift Container Platform マスターには、ビルトインの OAuth サーバーが含まれます。ユーザーは、OAuth アクセストークンを取得して API に対して認証することができます。

管理者として、LDAP、GitHub、または Google などの アイデンティティープロバイダー を使用して認証できるように OAuth を設定できます。新規の OpenShift Container Platform デプロイメントには、デフォルトでアイデンティティープロバイダーが使用されますが、これを初回インストール時またはインストール後に設定できます。

2.10.3.2. API アクセス制御および管理

アプリケーションには、管理を必要とする各種のエンドポイントを持つ複数の独立した API サービスを設定できます。OpenShift Container Platform には 3scale API ゲートウェイのコンテナー化されたバージョンが含まれており、これにより API を管理し、アクセスを制御することができます。

3scale は、API の認証およびセキュリティーに関する様々な標準オプションを提供します。これらは、認証情報を発行し、アクセスを制御するために単独で使用することも、他と組み合わせて使用することもできます (例: 標準 API キー、アプリケーション ID とキーペア、OAuth 2.0 など)。

アクセスについては、特定のエンドポイント、メソッド、およびサービスに制限することができ、アクセスポリシーをユーザーグループに適用することができます。アプリケーションの計画に基づいて、API の使用にレート制限を設定したり、開発者グループのトラフィックフローを制御したりすることが可能です。

APIcast v2 (コンテナー化された 3scale API ゲートウェイ) の使用に関するチュートリアルは、3scale ドキュメントの Running APIcast on Red Hat OpenShift を参照してください。

2.10.3.3. Red Hat Single Sign-On

Red Hat Single Sign-On サーバーを使用すると、SAML 2.0、OpenID Connect、および OAuth 2.0 などの標準に基づく Web サインオン機能を提供し、アプリケーションのセキュリティーを保護することができます。このサーバーは、SAML または OpenID Connect ベースのアイデンティティープロバイダー (IdP) として機能します。つまり、標準ベースのトークンを使用して、アイデンティティー情報およびアプリケーションについてエンタープライズユーザーディレクトリーまたはサードパーティーのアイデンティティープロバイダーとの仲介を行います。Red Hat Single Sign-On を Microsoft Active Directory および Red Hat Enterprise Linux Identity Management を含む LDAP ベースのディレクトリーサービスと統合することが可能です。

2.10.3.4. セルフサービス Web コンソールのセキュリティー保護

OpenShift Container Platform はセルフサービスの Web コンソールを提供して、チームが認証なしに他の環境にアクセスできないようにします。OpenShift Container Platform は以下の条件に基づいてセキュアなマルチテナントマスターを提供します。

  • マスターへのアクセスは Transport Layer Security (TLS) を使用する。
  • API サーバーへのアクセスは X.509 証明書または OAuth アクセストークンを使用する。
  • プロジェクトのクォータは不正トークンによるダメージを制限する。
  • etcd サービスはクラスターに直接公開されない。

2.10.4. プラットフォームの証明書の管理

OpenShift Container Platform には、そのフレームワーク内に、TLS 証明書による暗号化を利用した REST ベースの HTTPS 通信を使用する複数のコンポーネントがあります。OpenShift Container Platform のインストーラーは、これらの認証をインストール時に設定します。以下は、このトラフィックを生成するいくつかの主要コンポーネントです。

  • マスター (API サーバーとコントローラー)
  • etcd
  • ノード
  • レジストリー
  • ルーター
2.10.4.1. カスタム証明書の設定

API サーバーおよび Web コンソールのパブリックホスト名のカスタム提供証明書は、初回のインストール時または証明書の再デプロイ時に設定できます。カスタム CA を使用することも可能です。

2.11. ネットワークのセキュリティー保護

ネットワークセキュリティーは、複数のレベルで管理できます。Pod レベルでは、ネットワーク namespace はネットワークアクセスを制限することで、コンテナーが他の Pod やホストシステムを認識できないようにすることができます。ネットワークポリシーにより、拒否している接続の許可について制御することができます。コンテナー化されたアプリケーションに対する ingress および egress トラフィックを管理することができます。

2.11.1. ネットワーク namespace の使用

OpenShift Container Platform はソフトウェア定義ネットワーク (SDN) を使用して、クラスター全体でのコンテナー間の通信を可能にする統一クラスターネットワークを提供します。

ネットワークポリシーモードは、デフォルトで他の Pod およびネットワークエンドポイントからプロジェクトのすべての Pod にアクセスできるようにします。プロジェクトで 1 つ以上の Pod を分離するには、そのプロジェクトで NetworkPolicy オブジェクトを作成し、許可する着信接続を指定します。マルチテナントモードを使用すると、Pod およびサービスのプロジェクトレベルの分離を実行できます。

2.11.2. ネットワークポリシーを使用した Pod の分離

ネットワークポリシー を使用して、同じプロジェクトの Pod を相互に分離することができます。ネットワークポリシーでは、Pod へのネットワークアクセスをすべて拒否し、Ingress コントローラーの接続のみを許可したり、他のプロジェクトの Pod からの接続を拒否したり、ネットワークの動作に関する同様のルールを設定したりできます。

2.11.3. 複数の Pod ネットワークの使用

実行中の各コンテナーには、デフォルトでネットワークインターフェイスが 1 つだけあります。Multus CNI プラグインを使用すると、複数の CNI ネットワークを作成し、それらのネットワークのいずれかを Pod に割り当てることができます。このようにして、プライベートデータをより制限されたネットワークに分離し、各ノードに複数のネットワークインターフェイスを持たせることができます。

2.11.4. アプリケーションの分離

OpenShift Container Platform では、ユーザー、チーム、アプリケーション、および環境を非グローバルリソースから分離するマルチテナントのクラスターを作成するために、単一のクラスター上でネットワークのトラフィックをセグメント化することができます。

2.11.5. Ingress トラフィックのセキュリティー保護

OpenShift Container Platform クラスター外から Kubernetes サービスへのアクセスを設定する方法に関連し、セキュリティー上の影響に関する多数の考慮点があります。Ingress ルーティングでは、HTTP および HTTPS ルートを公開するほか、NodePort または LoadBalancer Ingress タイプを設定できます。NodePort は、それぞれのクラスターワーカーからアプリケーションのサービス API オブジェクトを公開します。LoadBalancer を使用すると、外部ロードバランサーを OpenShift Container Platform クラスターの関連付けられたサービス API オブジェクトに割り当てることができます。

2.11.6. Egress トラフィックのセキュリティー保護

OpenShift Container Platform は、ルーターまたはファイアウォールのいずれかを使用して Egress トラフィックを制御する機能を提供します。たとえば、IP のホワイトリストを使用して、データベースのアクセスを制御できます。クラスター管理者は、1 つ以上の egress IP アドレスを OpenShift Container Platform SDN ネットワークプロバイダーのプロジェクトに割り当てることができます。同様に、クラスター管理者は egress ファイアウォールを使用して、egress トラフィックが OpenShift Container Platform クラスター外に送信されないようにできます。

固定 egress IP アドレスを割り当てることで、すべての送信トラフィックを特定プロジェクトのその IP アドレスに割り当てることができます。egress ファイアウォールを使用すると、Pod が外部ネットワークに接続されないようにしたり、Pod が内部ネットワークに接続されないようにするか、Pod の特定の内部サブネットへのアクセスを制限したりできます。

2.12. 割り当てられたストレージのセキュリティー保護

OpenShift Container Platform は、オンプレミスおよびクラウドプロバイダーの両方で、複数のタイプのストレージをサポートします。とくに、OpenShift Container Platform は Container Storage Interface をサポートするストレージタイプを使用できます。

2.12.1. 永続ボリュームプラグイン

コンテナーは、ステートレスとステートフルの両方のアプリケーションに役立ちます。割り当て済みのストレージを保護することは、ステートフルサービスのセキュリティーを保護する上で重要な要素になります。Container Storage Interface (CSI) を使用すると、OpenShift Container Platform は CSI インターフェイスをサポートするストレージバックエンドからのストレージを組み込むことができます。

OpenShift Container Platform は、以下を含む複数のタイプのストレージのプラグインを提供します。

  • Red Hat OpenShift Data Foundation *
  • AWS Elastic Block Stores (EBS) *
  • AWS Elastic File System (EFS) *
  • Azure Disk
  • Azure File
  • OpenStack Cinder *
  • GCE Persistent Disks *
  • VMware vSphere *
  • ネットワークファイルシステム (NFS)
  • FlexVolume
  • ファイバーチャネル
  • iSCSI

動的プロビジョニングでのこれらのストレージタイプのプラグインには、アスタリスク (*) が付いています。送信中のデータは、相互に通信している OpenShift Container Platform のすべてのコンポーネントについて HTTPS 経由で暗号化されます。

永続ボリューム (PV) はストレージタイプでサポートされる方法でホスト上にマウントできます。異なるタイプのストレージにはそれぞれ異なる機能があり、各 PV のアクセスモードは、特定のボリュームによってサポートされる特定のモードに設定されます。

たとえば、NFS は複数の読み取り/書き込みクライアントをサポートしますが、特定の NFS PV は読み取り専用としてサーバー上でエクスポートされる可能性があります。各 PV には、ReadWriteOnceReadOnlyMany、および ReadWriteMany など、特定の PV 機能を説明したアクセスモードの独自のセットがあります。

2.12.2. 共有ストレージ

NFS のような共有ストレージプロバイダーの場合、PV はグループ ID (GID) を PV リソースのアノテーションとして登録します。次に、Pod が PV を要求する際に、アノテーションが付けられた GID が Pod の補助グループに追加され、この Pod に共有ストレージのコンテンツへのアクセスを付与します。

2.12.3. ブロックストレージ

AWS Elastic Block Store (EBS)、GCE Persistent Disks、および iSCSI などのブロックストレージプロバイダーの場合、OpenShift Container Platform は SELinux 機能を使用し、権限のない Pod のマウントされたボリュームについて、そのマウントされたボリュームが関連付けられたコンテナーにのみ所有され、このコンテナーにのみ表示されるようにしてそのルートを保護します。

2.13. クラスターイベントとログの監視

OpenShift Container Platform クラスターを監視および監査する機能は、不適切な利用に対してクラスターおよびそのユーザーを保護する上で重要な要素となります。

これに関連し、イベントとログという 2 つの主な情報源をクラスターレベルの情報として使用できます。

2.13.1. クラスターイベントの監視

クラスター管理者は、関連するイベントを判別できるように イベント のリソースタイプについて理解し、システムイベントのリストを確認することを推奨します。イベントは、関連するリソースの namespace または default namespace (クラスターイベントの場合) のいずれかの namespace に関連付けられます。デフォルトの namespace は、クラスターを監視または監査するための関連するイベントを保持します。たとえば、これにはノードイベントおよびインフラストラクチャーコンポーネントに関連したリソースイベントが含まれます。

マスター API および oc コマンドは、イベントのリストをノードに関連するものに制限するパラメーターを提供しません。これを実行する簡単な方法として grep を使用することができます。

$ oc get event -n default | grep Node

出力例

1h         20h         3         origin-node-1.example.local   Node      Normal    NodeHasDiskPressure   ...

より柔軟な方法として、他のツールで処理できる形式でイベントを出力することができます。たとえば、以下の例では NodeHasDiskPressure イベントのみをデプロイメントするために JSON 出力に対して jq ツールを使用しています。

$ oc get events -n default -o json \
  | jq '.items[] | select(.involvedObject.kind == "Node" and .reason == "NodeHasDiskPressure")'

出力例

{
  "apiVersion": "v1",
  "count": 3,
  "involvedObject": {
    "kind": "Node",
    "name": "origin-node-1.example.local",
    "uid": "origin-node-1.example.local"
  },
  "kind": "Event",
  "reason": "NodeHasDiskPressure",
  ...
}

リソースの作成や変更、または削除に関連するイベントも、クラスターの不正な使用を検出するために使用することができます。たとえば、以下のクエリーは、イメージの過剰なプルの有無を確認するために使用できます。

$ oc get events --all-namespaces -o json \
  | jq '[.items[] | select(.involvedObject.kind == "Pod" and .reason == "Pulling")] | length'

出力例

4

注記

namespace を削除すると、そのイベントも削除されます。イベントも期限切れになる可能性があり、etcd ストレージが一杯にならないように削除されます。イベントは永続するレコードとして保存されず、一定期間の統計データを取得するためにポーリングを頻繁に実行する必要があります。

2.13.2. ロギング

oc log コマンドを使用して、コンテナーログ、ビルド設定およびデプロイメントをリアルタイムで表示できます。ユーザーによって、ログへの異なるアクセスが必要になる場合があります。

  • プロジェクトにアクセスできるユーザーは、デフォルトでそのプロジェクトのログを確認することができます。
  • 管理ロールを持つユーザーは、すべてのコンテナーログにアクセスできます。

詳細な監査および分析のためにログを保存するには、cluster-logging アドオン機能を有効にして、システム、コンテナー、監査ログを収集し、管理し、表示できます。OpenShift Elasticsearch Operator および Red Hat OpenShift Logging Operator を使用して OpenShift Logging をデプロイし、管理し、アップグレードできます。

2.13.3. 監査ログ

監査ログ を使用すると、ユーザー、管理者、またはその他の OpenShift Container Platform コンポーネントの動作に関連する一連のアクティビティーをフォローできます。API 監査ロギングは各サーバーで行われます。

第3章 証明書の設定

3.1. デフォルトの Ingress 証明書の置き換え

3.1.1. デフォルトの Ingress 証明書について

デフォルトで、OpenShift Container Platform は Ingress Operator を使用して内部 CA を作成し、.apps サブドメインの下にあるアプリケーションに有効なワイルドカード証明書を発行します。Web コンソールと CLI のどちらもこの証明書を使用します。

内部インフラストラクチャー CA 証明書は自己署名型です。一部のセキュリティーまたは PKI チームにとってこのプロセスは適切とみなされない可能性がありますが、ここで想定されるリスクは最小限度のものです。これらの証明書を暗黙的に信頼するクライアントがクラスター内の他のコンポーネントになります。デフォルトのワイルドカード証明書を、コンテナーユーザー空間で提供される CA バンドルにすでに含まれているパブリック CA に置き換えることで、外部クライアントは .apps サブドメインで実行されるアプリケーションに安全に接続できます。

3.1.2. デフォルトの Ingress 証明書の置き換え

.apps サブドメインにあるすべてのアプリケーションのデフォルトの Ingress 証明書を置き換えることができます。証明書を置き換えた後に、Web コンソールや CLI を含むすべてのアプリケーションには、指定された証明書で提供される暗号化が設定されます。

前提条件

  • 完全修飾 .apps サブドメインおよびその対応するプライベートキーのワイルドカード証明書が必要です。それぞれが個別の PEM 形式のファイルである必要があります。
  • プライベートキーの暗号化は解除されている必要があります。キーが暗号化されている場合は、これを OpenShift Container Platform にインポートする前に復号化します。
  • 証明書には、*.apps.<clustername>.<domain> を示す subjectAltName 拡張が含まれている必要があります。
  • 証明書ファイルでは、チェーンに 1 つ以上の証明書を含めることができます。ワイルドカード証明書は、ファイルの最初の証明書である必要があります。この後には中間証明書が続き、ファイルの最後はルート CA 証明書にすることができます。
  • ルート CA 証明書を追加の PEM 形式のファイルにコピーします。
  • -----END CERTIFICATE----- を含むすべての証明書が、その行の後に 1 つの改行で終了していることを確認します。
重要

認証局(CA)を更新すると、クラスター内のノードが再起動します。

手順

  1. ワイルドカード証明書の署名に使用されるルート CA 証明書のみが含まれる設定マップを作成します。

    $ oc create configmap custom-ca \
         --from-file=ca-bundle.crt=</path/to/example-ca.crt> \1
         -n openshift-config
    1
    </path/to/example-ca.crt> は、ローカルファイルシステム上のルート CA 証明書ファイルへのパスです。
  2. 新たに作成された設定マップでクラスター全体のプロキシー設定を更新します。

    $ oc patch proxy/cluster \
         --type=merge \
         --patch='{"spec":{"trustedCA":{"name":"custom-ca"}}}'
  3. ワイルドカード証明書チェーンおよびキーが含まれるシークレットを作成します。

    $ oc create secret tls <secret> \1
         --cert=</path/to/cert.crt> \2
         --key=</path/to/cert.key> \3
         -n openshift-ingress
    1
    <secret> は、証明書チェーンおよびプライベートキーが含まれるシークレットの名前です。
    2
    </path/to/cert.crt> は、ローカルファイルシステム上の証明書チェーンへのパスです。
    3
    </path/to/cert.key> は、この証明書に関連付けられるプライベートキーへのパスです。
  4. Ingress コントローラー設定を、新規に作成されたシークレットで更新します。

    $ oc patch ingresscontroller.operator default \
         --type=merge -p \
         '{"spec":{"defaultCertificate": {"name": "<secret>"}}}' \1
         -n openshift-ingress-operator
    1
    <secret> を、直前の手順でシークレットに使用された名前に置き換えます。
関連情報

3.2. API サーバー証明書の追加

デフォルトの API サーバー証明書は、内部 OpenShift Container Platform クラスター CA によって発行されます。クラスター外のクライアントは、デフォルトで API サーバーの証明書を検証できません。この証明書は、クライアントが信頼する CA によって発行される証明書に置き換えることができます。

3.2.1. API サーバーの名前付き証明書の追加

デフォルトの API サーバー証明書は、内部 OpenShift Container Platform クラスター CA によって発行されます。リバースプロキシーやロードバランサーが使用される場合など、クライアントが要求する完全修飾ドメイン名 (FQDN) に基づいて、API サーバーが返す代替証明書を 1 つ以上追加できます。

前提条件

  • FQDN とそれに対応するプライベートキーの証明書が必要です。それぞれが個別の PEM 形式のファイルである必要があります。
  • プライベートキーの暗号化は解除されている必要があります。キーが暗号化されている場合は、これを OpenShift Container Platform にインポートする前に復号化します。
  • 証明書には、FQDN を示す subjectAltName 拡張が含まれる必要があります。
  • 証明書ファイルでは、チェーンに 1 つ以上の証明書を含めることができます。API サーバー FQDN の証明書は、ファイルの最初の証明書である必要があります。この後には中間証明書が続き、ファイルの最後はルート CA 証明書にすることができます。
警告

内部ロードバランサーに名前付きの証明書を指定しないようにしてください (ホスト名 api-int.<cluster_name>.<base_domain>)。これを指定すると、クラスターの状態は動作の低下した状態になります。

手順

  1. kubeadmin ユーザーとして新しい API にログインします。

    $ oc login -u kubeadmin -p <password> https://FQDN:6443
  2. kubeconfig ファイルを取得します。

    $ oc config view --flatten > kubeconfig-newapi
  3. openshift-config namespace に証明書およびプライベートキーが含まれるシークレットを作成します。

    $ oc create secret tls <secret> \1
         --cert=</path/to/cert.crt> \2
         --key=</path/to/cert.key> \3
         -n openshift-config
    1
    <secret> は、証明書チェーンおよびプライベートキーが含まれるシークレットの名前です。
    2
    </path/to/cert.crt> は、ローカルファイルシステム上の証明書チェーンへのパスです。
    3
    </path/to/cert.key> は、この証明書に関連付けられるプライベートキーへのパスです。
  4. API サーバーを作成されたシークレットを参照するように更新します。

    $ oc patch apiserver cluster \
         --type=merge -p \
         '{"spec":{"servingCerts": {"namedCertificates":
         [{"names": ["<FQDN>"], 1
         "servingCertificate": {"name": "<secret>"}}]}}}' 2
    1
    <FQDN> を、API サーバーが証明書を提供する FQDN に置き換えます。
    2
    <secret> を、直前の手順でシークレットに使用された名前に置き換えます。
  5. apiserver/cluster オブジェクトを検査し、シークレットが参照されていることを確認します。

    $ oc get apiserver cluster -o yaml

    出力例

    ...
    spec:
      servingCerts:
        namedCertificates:
        - names:
          - <FQDN>
          servingCertificate:
            name: <secret>
    ...

  6. kube-apiserver Operator を確認し、Kubernetes API サーバーの新しいリビジョンがロールアウトされることを確認します。Operator が設定の変更を検出して新しいデプロイメントをトリガーするのに 1 分かかる場合があります。新しいリビジョンが公開されている間、PROGRESSINGTrue を報告します。

    $ oc get clusteroperators kube-apiserver

    以下の出力にあるように、PROGRESSINGFalse と表示されるまで次の手順に移行しないでください。

    出力例

    NAME             VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE
    kube-apiserver   4.13.0     True        False         False      145m

    PROGRESSINGTrue と表示されている場合は、数分待機してから再試行します。

    注記

    Kubernetes API サーバーの新しいリビジョンは、API サーバーの名前付き証明書が初めて追加された場合にのみロールアウトされます。API サーバーの名前付き証明書が更新されると、kube-apiserver Pod が更新された証明書を動的に再ロードするため、Kubernetes API サーバーの新しいリビジョンはロールアウトされません。

3.3. サービス提供証明書のシークレットによるサービストラフィックのセキュリティー保護

3.3.1. サービス提供証明書について

サービス提供証明書は、暗号化を必要とする複雑なミドルウェアアプリケーションをサポートすることが意図されています。これらの証明書は、TLS Web サーバー証明書として発行されます。

service-ca コントローラーは、サービス証明書を生成するために x509.SHA256WithRSA 署名アルゴリズムを使用します。

生成される証明書およびキーは PEM 形式のもので、作成されたシークレット内の tls.crt および tls.key にそれぞれ保存されます。証明書およびキーは、有効期間に近づくと自動的に置き換えられます。

サービス証明書を発行するサービス CA 証明書は 26 ヵ月間有効であり、有効期間が 13 ヵ月未満になると自動的にローテーションされます。ローテーション後も、直前のサービス CA 設定は有効期限が切れるまで信頼されます。これにより、影響を受けるすべてのサービスについて、期限が切れる前にそれらのキーの情報を更新できるように猶予期間が許可されます。この猶予期間中にクラスターをアップグレード (サービスを再起動してそれらのキー情報を更新する) を実行しない場合、直前のサービス CA の期限が切れた後の失敗を防ぐためにサービスを手動で再起動する必要がある場合があります。

注記

以下のコマンドを使用して、クラスター内のすべての Pod を手動で再起動できます。このコマンドは、すべての namespace で実行されているすべての Pod を削除するため、このコマンドを実行するとサービスが中断します。これらの Pod は削除後に自動的に再起動します。

$ for I in $(oc get ns -o jsonpath='{range .items[*]} {.metadata.name}{"\n"} {end}'); \
      do oc delete pods --all -n $I; \
      sleep 1; \
      done

3.3.2. サービス証明書の追加

サービスとの通信のセキュリティーを保護するには、サービスと同じ namespace のシークレットに署名済みの提供証明書とキーのペアを生成します。

生成される証明書は、内部サービス DNS 名 <service.name>.<service.namespace>.svc にのみ有効であり、内部通信用にのみ有効です。サービスがヘッドレスサービス (clusterIP 値が設定されていない) である場合、生成された証明書には *.<service.name>.<service.namespace>.svc 形式のワイルドカードのサブジェクトも含まれます。

重要

生成された証明書にはヘッドレスサービスのワイルドカードサブジェクトが含まれるため、クライアントが個別の Pod を区別する必要がある場合はサービス CA を使用しないでください。この場合は、以下のようになります。

  • 別の CA を使用して個別の TLS 証明書を生成します。
  • サービス CA は、個々の Pod に送信される接続に関する信頼される CA として許可することはできず、他の Pod がこの権限を借用することはできません。これらの接続は、個別の TLS 証明書の生成に使用されている CA を信頼するように設定される必要があります。

前提条件

  • サービスが定義されていること。

手順

  1. サービスに service.beta.openshift.io/serving-cert-secret-name のアノテーションを付けます。

    $ oc annotate service <service_name> \1
         service.beta.openshift.io/serving-cert-secret-name=<secret_name> 2
    1
    <service_name> を、セキュリティー保護するサービスの名前に置き換えます。
    2
    <secret_name> は、証明書とキーのペアを含む生成されたシークレットの名前です。便宜上、これを <service_name> と同じにすることが推奨されます。

    たとえば、以下のコマンドを使用してサービス test1 にアノテーションを付けます。

    $ oc annotate service test1 service.beta.openshift.io/serving-cert-secret-name=test1
  2. アノテーションが存在することを確認するためにサービスを検査します。

    $ oc describe service <service_name>

    出力例

    ...
    Annotations:              service.beta.openshift.io/serving-cert-secret-name: <service_name>
                              service.beta.openshift.io/serving-cert-signed-by: openshift-service-serving-signer@1556850837
    ...

  3. クラスターがサービスのシークレットを生成した後に、Pod 仕様がこれをマウントでき、Pod はシークレットが利用可能になった後にこれを実行できます。

関連情報

3.3.3. サービス CA バンドルの設定マップへの追加

Pod は、service.beta.openshift.io/inject-cabundle=true のアノテーションの付いた ConfigMap オブジェクトをマウントしてサービス CA 証明書にアクセスできます。アノテーションが付けられると、クラスターはサービス CA 証明書を設定マップの service-ca.crt キーに自動的に挿入します。この CA 証明書にアクセスできると、TLS クライアントはサービス提供証明書を使用してサービスへの接続を検証できます。

重要

このアノテーションが設定マップに追加されると、その中に含まれるすべての既存データが削除されます。service-ca.crt を組み込む設定マップとしては、Pod の設定の保存先と同じ設定マップではなく、別の設定マップを使用することが推奨されます。

手順

  1. 設定マップに service.beta.openshift.io/inject-cabundle=true のアノテーションを付けます。

    $ oc annotate configmap <config_map_name> \1
         service.beta.openshift.io/inject-cabundle=true
    1
    <config_map_name> を、アノテーションを付ける設定マップの名前に置き換えます。
    注記

    ボリュームマウントの service-ca.crt キーを明示的に参照することにより、設定マップが CA バンドルと共に挿入されるまで、Pod を起動できなくなります。この動作は、ボリュームの提供証明書の設定について optional フィールドを true に設定して上書きできます。

    たとえば、以下のコマンドを使用して設定マップ test1 にアノテーションを付けます。

    $ oc annotate configmap test1 service.beta.openshift.io/inject-cabundle=true
  2. 設定マップを表示して、サービス CA バンドルが挿入されていることを確認します。

    $ oc get configmap <config_map_name> -o yaml

    CA バンドルは、YAML 出力の service-ca.crt キーの値として表示されます。

    apiVersion: v1
    data:
      service-ca.crt: |
        -----BEGIN CERTIFICATE-----
    ...

3.3.4. サービス CA バンドルの API サービスへの追加

APIService オブジェクトに service.beta.openshift.io/inject-cabundle=true のアノテーションを付け、その spec.caBundle フィールドにサービス CA バンドルを設定できます。これにより、Kubernetes API サーバーはターゲットに設定されたエンドポイントのセキュリティーを保護するために使用されるサービス CA 証明書を検証することができます。

手順

  1. API サービスに service.beta.openshift.io/inject-cabundle=true のアノテーションを付けます。

    $ oc annotate apiservice <api_service_name> \1
         service.beta.openshift.io/inject-cabundle=true
    1
    <api_service_name> を、アノテーションを付ける API サービスの名前に置き換えます。

    たとえば、以下のコマンドを使用して API サービス test1 にアノテーションを付けます。

    $ oc annotate apiservice test1 service.beta.openshift.io/inject-cabundle=true
  2. API サービスを表示し、サービス CA バンドルが挿入されていることを確認します。

    $ oc get apiservice <api_service_name> -o yaml

    CA バンドルは YAML 出力の spec.caBundle フィールドに表示されます。

    apiVersion: apiregistration.k8s.io/v1
    kind: APIService
    metadata:
      annotations:
        service.beta.openshift.io/inject-cabundle: "true"
    ...
    spec:
      caBundle: <CA_BUNDLE>
    ...

3.3.5. サービス CA バンドルのカスタムリソース定義への追加

CustomResourceDefinition (CRD) オブジェクトに service.beta.openshift.io/inject-cabundle=true のアノテーションを付け、その spec.conversion.webhook.clientConfig.caBundle フィールドにサービス CA バンドルを設定できます。これにより、Kubernetes API サーバーはターゲットに設定されたエンドポイントのセキュリティーを保護するために使用されるサービス CA 証明書を検証することができます。

注記

サービス CA バンドルは、CRD が変換に Webhook を使用するように設定されている場合にのみ CRD にインジェクトされます。CRD の Webhook がサービス CA 証明書でセキュリティー保護されている場合にのみ、サービス CA バンドルを挿入することは役に立ちます。

手順

  1. CRD に service.beta.openshift.io/inject-cabundle=true のアノテーションを付けます。

    $ oc annotate crd <crd_name> \1
         service.beta.openshift.io/inject-cabundle=true
    1
    <crd_name> をアノテーションを付ける CRD の名前に置き換えます。

    たとえば、以下のコマンドを使用して CRD test1 にアノテーションを付けます。

    $ oc annotate crd test1 service.beta.openshift.io/inject-cabundle=true
  2. CRD を表示して、サービス CA バンドルが挿入されていることを確認します。

    $ oc get crd <crd_name> -o yaml

    CA バンドルは、YAML 出力の spec.conversion.webhook.clientConfig.caBundle フィールドに表示されます。

    apiVersion: apiextensions.k8s.io/v1
    kind: CustomResourceDefinition
    metadata:
      annotations:
        service.beta.openshift.io/inject-cabundle: "true"
    ...
    spec:
      conversion:
        strategy: Webhook
        webhook:
          clientConfig:
            caBundle: <CA_BUNDLE>
    ...

3.3.6. サービス CA バンドルの変更用 Webhook 設定への追加

MutatingWebhookConfiguration オブジェクトに service.beta.openshift.io/inject-cabundle=true のアノテーションを付け、各 Webhook の clientConfig.caBundle フィールドにサービス CA バンドルを設定できます。これにより、Kubernetes API サーバーはターゲットに設定されたエンドポイントのセキュリティーを保護するために使用されるサービス CA 証明書を検証することができます。

注記

異なる Webhook に異なる CA バンドルを指定する必要がある受付 Webhook 設定にはこのアノテーションを設定しないでください。これを実行する場合、サービス CA バンドルはすべての Webhook について挿入されます。

手順

  1. 変更用 Webhook 設定に service.beta.openshift.io/inject-cabundle=true のアノテーションを付けます。

    $ oc annotate mutatingwebhookconfigurations <mutating_webhook_name> \1
         service.beta.openshift.io/inject-cabundle=true
    1
    <mutating_webhook_name> を、アノテーションを付ける変更用 Webhook 設定の名前に置き換えます。

    たとえば、以下のコマンドを使用して変更用 webhook 設定 test1 にアノテーションを付けます。

    $ oc annotate mutatingwebhookconfigurations test1 service.beta.openshift.io/inject-cabundle=true
  2. 変更用 webhook 設定を表示して、サービス CA バンドルが挿入されていることを確認します。

    $ oc get mutatingwebhookconfigurations <mutating_webhook_name> -o yaml

    CA バンドルは、YAML 出力のすべての Webhook の clientConfig.caBundle フィールドに表示されます。

    apiVersion: admissionregistration.k8s.io/v1
    kind: MutatingWebhookConfiguration
    metadata:
      annotations:
        service.beta.openshift.io/inject-cabundle: "true"
    ...
    webhooks:
    - myWebhook:
      - v1beta1
      clientConfig:
        caBundle: <CA_BUNDLE>
    ...

3.3.7. サービス CA バンドルの変更用 webhook 設定への追加

ValidatingWebhookConfiguration オブジェクトに service.beta.openshift.io/inject-cabundle=true のアノテーションを付け、各 Webhook の clientConfig.caBundle フィールドにサービス CA バンドルを設定できます。これにより、Kubernetes API サーバーはターゲットに設定されたエンドポイントのセキュリティーを保護するために使用されるサービス CA 証明書を検証することができます。

注記

異なる Webhook に異なる CA バンドルを指定する必要がある受付 Webhook 設定にはこのアノテーションを設定しないでください。これを実行する場合、サービス CA バンドルはすべての Webhook について挿入されます。

手順

  1. 検証用 Webhook 設定に service.beta.openshift.io/inject-cabundle=true のアノテーションを付けます。

    $ oc annotate validatingwebhookconfigurations <validating_webhook_name> \1
         service.beta.openshift.io/inject-cabundle=true
    1
    <validating_webhook_name> をアノテーションを付ける検証用 Webhook 設定の名前に置き換えます。

    たとえば、以下のコマンドを使用して検証用 webhook 設定 test1 にアノテーションを付けます。

    $ oc annotate validatingwebhookconfigurations test1 service.beta.openshift.io/inject-cabundle=true
  2. 検証用 webhook 設定を表示して、サービス CA バンドルが挿入されていることを確認します。

    $ oc get validatingwebhookconfigurations <validating_webhook_name> -o yaml

    CA バンドルは、YAML 出力のすべての Webhook の clientConfig.caBundle フィールドに表示されます。

    apiVersion: admissionregistration.k8s.io/v1
    kind: ValidatingWebhookConfiguration
    metadata:
      annotations:
        service.beta.openshift.io/inject-cabundle: "true"
    ...
    webhooks:
    - myWebhook:
      - v1beta1
      clientConfig:
        caBundle: <CA_BUNDLE>
    ...

3.3.8. 生成されたサービス証明書の手動によるローテーション

関連付けられたシークレットを削除することにより、サービス証明書をローテーションできます。シークレットを削除すると、新規のシークレットが自動的に作成され、新規証明書が作成されます。

前提条件

  • 証明書とキーのペアを含むシークレットがサービス用に生成されていること。

手順

  1. 証明書を含むシークレットを確認するためにサービスを検査します。これは、以下に示すように serving-cert-secret-name アノテーションにあります。

    $ oc describe service <service_name>

    出力例

    ...
    service.beta.openshift.io/serving-cert-secret-name: <secret>
    ...

  2. サービスの生成されたシークレットを削除します。このプロセスで、シークレットが自動的に再作成されます。

    $ oc delete secret <secret> 1
    1
    <secret> を、直前の手順のシークレットの名前に置き換えます。
  3. 新規シークレットを取得し、AGE を調べて、証明書が再作成されていることを確認します。

    $ oc get secret <service_name>

    出力例

    NAME              TYPE                DATA   AGE
    <service.name>    kubernetes.io/tls   2      1s

3.3.9. サービス CA 証明書の手動によるローテーション

サービス CA は 26 ヵ月間有効で、有効期間が 13 ヵ月未満になると自動的に更新されます。

必要に応じて、以下の手順でサービス CA を手動で更新することができます。

警告

手動でローテーションされるサービス CA は、直前のサービス CA で信頼を維持しません。クラスターの Pod が再起動するまでサービスが一時的に中断する可能性があります。これにより、Pod が新規サービス CA で発行されるサービス提供証明書を使用できるようになります。

前提条件

  • クラスター管理者としてログインしている必要があります。

手順

  1. 以下のコマンドを使用して、現在のサービス CA 証明書の有効期限を表示します。

    $ oc get secrets/signing-key -n openshift-service-ca \
         -o template='{{index .data "tls.crt"}}' \
         | base64 --decode \
         | openssl x509 -noout -enddate
  2. サービス CA を手動でローテーションします。このプロセスは、新規サービス証明書に署名するために使用される新規サービス CA を生成します。

    $ oc delete secret/signing-key -n openshift-service-ca
  3. 新規証明書をすべてのサービスに適用するには、クラスター内のすべての Pod を再起動します。このコマンドにより、すべてのサービスが更新された証明書を使用するようになります。

    $ for I in $(oc get ns -o jsonpath='{range .items[*]} {.metadata.name}{"\n"} {end}'); \
          do oc delete pods --all -n $I; \
          sleep 1; \
          done
    警告

    このコマンドは、すべての namespace で実行されているすべての Pod を調べ、これらを削除するため、サービスを中断させます。これらの Pod は削除後に自動的に再起動します。

3.4. CA バンドルの更新

重要

認証局 (CA) を更新すると、クラスターのノードが再起動されます。

3.4.1. CA バンドル証明書について

プロキシー証明書により、ユーザーは egress 接続の実行時にプラットフォームコンポーネントによって使用される 1 つ以上のカスタム認証局 (CA) を指定できます。

プロキシーオブジェクトの trustedCA フィールドは、ユーザーによって提供される信頼される認証局 (CA) バンドルを含む設定マップの参照です。このバンドルは Red Hat Enterprise Linux CoreOS (RHCOS) 信頼バンドルにマージされ、egress HTTPS 呼び出しを行うプラットフォームコンポーネントの信頼ストアに挿入されます。たとえば、image-registry-operator は外部イメージレジストリーを呼び出してイメージをダウンロードします。trustedCA が指定されていない場合、RHCOS 信頼バンドルのみがプロキシーされる HTTPS 接続に使用されます。独自の証明書インフラストラクチャーを使用する場合は、カスタム CA 証明書を RHCOS 信頼バンドルに指定します。

trustedCA フィールドは、プロキシーバリデーターによってのみ使用される必要があります。バリデーターは、必要なキー ca-bundle.crt から証明書バンドルを読み取り、これを openshift-config-managed namespace の trusted-ca-bundle という名前の設定マップにコピーします。trustedCA によって参照される設定マップの namespace は openshift-config です。

apiVersion: v1
kind: ConfigMap
metadata:
  name: user-ca-bundle
  namespace: openshift-config
data:
  ca-bundle.crt: |
    -----BEGIN CERTIFICATE-----
    Custom CA certificate bundle.
    -----END CERTIFICATE-----

3.4.2. CA バンドル証明書の置き換え

手順

  1. ワイルドカード証明書の署名に使用されるルート CA 証明書が含まれる設定マップを作成します。

    $ oc create configmap custom-ca \
         --from-file=ca-bundle.crt=</path/to/example-ca.crt> \1
         -n openshift-config
    1
    </path/to/example-ca.crt> は、ローカルファイルシステム上の CA 証明書バンドルへのパスです。
  2. 新たに作成された設定マップでクラスター全体のプロキシー設定を更新します。

    $ oc patch proxy/cluster \
         --type=merge \
         --patch='{"spec":{"trustedCA":{"name":"custom-ca"}}}'
関連情報

第4章 証明書の種類および説明

4.1. API サーバーのユーザーによって提供される証明書

4.1.1. 目的

API サーバーは、api.<cluster_name>.<base_domain> のクラスター外にあるクライアントからアクセスできます。クライアントに別のホスト名で API サーバーにアクセスさせたり、クラスター管理の認証局 (CA) 証明書をクライアントに配布せずに API サーバーにアクセスさせたりする必要が生じる場合があります。管理者は、コンテンツを提供する際に API サーバーによって使用されるカスタムデフォルト証明書を設定する必要があります。

4.1.2. 場所

ユーザーによって提供される証明書は、openshift-config namespace の kubernetes.io/tls タイプの Secret で指定される必要があります。ユーザーによって提供される証明書を使用できるように、API サーバークラスター設定の apiserver/cluster リソースを更新します。

4.1.3. 管理

ユーザーによって提供される証明書はユーザーによって管理されます。

4.1.4. 有効期限

API サーバークライアント証明書の有効期限は 5 分未満です。

ユーザーによって提供される証明書はユーザーによって管理されます。

4.1.5. カスタマイズ

必要に応じて、ユーザーが管理する証明書を含むシークレットを更新します。

関連情報

4.2. プロキシー証明書

4.2.1. 目的

プロキシー証明書により、ユーザーは egress 接続の実行時にプラットフォームコンポーネントによって使用される 1 つ以上のカスタム認証局 (CA) 証明書を指定できます。

プロキシーオブジェクトの trustedCA フィールドは、ユーザーによって提供される信頼される認証局 (CA) バンドルを含む設定マップの参照です。このバンドルは Red Hat Enterprise Linux CoreOS (RHCOS) 信頼バンドルにマージされ、egress HTTPS 呼び出しを行うプラットフォームコンポーネントの信頼ストアに挿入されます。たとえば、image-registry-operator は外部イメージレジストリーを呼び出してイメージをダウンロードします。trustedCA が指定されていない場合、RHCOS 信頼バンドルのみがプロキシーされる HTTPS 接続に使用されます。独自の証明書インフラストラクチャーを使用する場合は、カスタム CA 証明書を RHCOS 信頼バンドルに指定します。

trustedCA フィールドは、プロキシーバリデーターによってのみ使用される必要があります。バリデーターは、必要なキー ca-bundle.crt から証明書バンドルを読み取り、これを openshift-config-managed namespace の trusted-ca-bundle という名前の設定マップにコピーします。trustedCA によって参照される設定マップの namespace は openshift-config です。

apiVersion: v1
kind: ConfigMap
metadata:
  name: user-ca-bundle
  namespace: openshift-config
data:
  ca-bundle.crt: |
    -----BEGIN CERTIFICATE-----
    Custom CA certificate bundle.
    -----END CERTIFICATE-----
関連情報

4.2.2. インストール時のプロキシー証明書の管理

インストーラー設定の additionalTrustBundle 値は、インストール時にプロキシー信頼 CA 証明書を指定するために使用されます。以下に例を示します。

$ cat install-config.yaml

出力例

...
proxy:
  httpProxy: http://<username:password@proxy.example.com:123/>
  httpsProxy: http://<username:password@proxy.example.com:123/>
  noProxy: <123.example.com,10.88.0.0/16>
additionalTrustBundle: |
    -----BEGIN CERTIFICATE-----
   <MY_HTTPS_PROXY_TRUSTED_CA_CERT>
    -----END CERTIFICATE-----
...

4.2.3. 場所

ユーザーによって提供される信頼バンドルは、設定マップとして表現されます。設定マップは、egress HTTPS 呼び出しを行うプラットフォームコンポーネントのファイルシステムにマウントされます。通常、Operator は設定マップを /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem にマウントしますが、これはプロキシーでは必要ありません。プロキシーは HTTPS 接続を変更したり、検査したりできます。いずれの場合も、プロキシーは接続用の新規証明書を生成して、これに署名する必要があります。

完全なプロキシーサポートとは、指定されたプロキシーに接続し、生成した署名を信頼することを指します。そのため、信頼されたルートに接続しているいずれの証明書チェーンも信頼されるように、ユーザーがその信頼されたルートを指定する必要があります。

RHCOS 信頼バンドルを使用している場合、CA 証明書を /etc/pki/ca-trust/source/anchors に配置します。

詳細は、Red Hat Enterprise Linux ドキュメントの 共有システム証明書の使用 を参照してください。

4.2.4. 有効期限

ユーザーは、ユーザーによって提供される信頼バンドルの有効期限を設定します。

デフォルトの有効期限は CA 証明書自体で定義されます。この設定は、OpenShift Container Platform または RHCOS で使用する前に、CA 管理者が証明書に対して行います。

注記

Red Hat では、CA の有効期限が切れるタイミングを監視しません。ただし、CA の有効期間は長く設定されるため、通常問題は生じません。ただし、信頼バンドルを定期的に更新する必要がある場合があります。

4.2.5. サービス

デフォルトで、egress HTTPS 呼び出しを行うすべてのプラットフォームコンポーネントは RHCOS 信頼バンドルを使用します。trustedCA が定義される場合、これも使用されます。

RHCOS ノードで実行されているすべてのサービスは、ノードの信頼バンドルを使用できます。

4.2.6. 管理

これらの証明書は、ユーザーではなく、システムによって管理されます。

4.2.7. カスタマイズ

ユーザーによって提供される信頼バンドルを更新するには、以下のいずれかを実行します。

  • trustedCA で参照される設定マップの PEM でエンコードされた証明書の更新
  • 新しい信頼バンドルが含まれる namespace openshift-config での設定マップの作成、および新規設定マップの名前を参照できるようにするための trustedCA の更新

CA 証明書を RHCOS 信頼バンドルに書き込むメカニズムは、マシン設定を使用して行われるその他のファイルの RHCOS への書き込みと全く同じです。Machine Config Operator (MCO) が新規 CA 証明書が含まれる新規マシン設定を適用すると、ノードは再起動されます。次回の起動時に、サービス coreos-update-ca-trust.service は RHCOS ノードで実行されます。これにより、新規 CA 証明書で信頼バンドルが自動的に更新されます。以下に例を示します。

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: worker
  name: 50-examplecorp-ca-cert
spec:
  config:
    ignition:
      version: 3.1.0
    storage:
      files:
      - contents:
          source: data:text/plain;charset=utf-8;base64,LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUVORENDQXh5Z0F3SUJBZ0lKQU51bkkwRDY2MmNuTUEwR0NTcUdTSWIzRFFFQkN3VUFNSUdsTVFzd0NRWUQKV1FRR0V3SlZVekVYTUJVR0ExVUVDQXdPVG05eWRHZ2dRMkZ5YjJ4cGJtRXhFREFPQmdOVkJBY01CMUpoYkdWcApBMmd4RmpBVUJnTlZCQW9NRFZKbFpDQklZWFFzSUVsdVl5NHhFekFSQmdOVkJBc01DbEpsWkNCSVlYUWdTVlF4Ckh6QVpCZ05WQkFNTUVsSmxaQ0JJWVhRZ1NWUWdVbTl2ZENCRFFURWhNQjhHQ1NxR1NJYjNEUUVKQVJZU2FXNW0KWGpDQnBURUxNQWtHQTFVRUJoTUNWVk14RnpBVkJnTlZCQWdNRGs1dmNuUm9JRU5oY205c2FXNWhNUkF3RGdZRApXUVFIREFkU1lXeGxhV2RvTVJZd0ZBWURWUVFLREExU1pXUWdTR0YwTENCSmJtTXVNUk13RVFZRFZRUUxEQXBTCkFXUWdTR0YwSUVsVU1Sc3dHUVlEVlFRRERCSlNaV1FnU0dGMElFbFVJRkp2YjNRZ1EwRXhJVEFmQmdrcWhraUcKMHcwQkNRRVdFbWx1Wm05elpXTkFjbVZrYUdGMExtTnZiVENDQVNJd0RRWUpLb1pJaHZjTkFRRUJCUUFEZ2dFUApCRENDQVFvQ2dnRUJBTFF0OU9KUWg2R0M1TFQxZzgwcU5oMHU1MEJRNHNaL3laOGFFVHh0KzVsblBWWDZNSEt6CmQvaTdsRHFUZlRjZkxMMm55VUJkMmZRRGsxQjBmeHJza2hHSUlaM2lmUDFQczRsdFRrdjhoUlNvYjNWdE5xU28KSHhrS2Z2RDJQS2pUUHhEUFdZeXJ1eTlpckxaaW9NZmZpM2kvZ0N1dDBaV3RBeU8zTVZINXFXRi9lbkt3Z1BFUwpZOXBvK1RkQ3ZSQi9SVU9iQmFNNzYxRWNyTFNNMUdxSE51ZVNmcW5obzNBakxRNmRCblBXbG82MzhabTFWZWJLCkNFTHloa0xXTVNGa0t3RG1uZTBqUTAyWTRnMDc1dkNLdkNzQ0F3RUFBYU5qTUdFd0hRWURWUjBPQkJZRUZIN1IKNXlDK1VlaElJUGV1TDhacXczUHpiZ2NaTUI4R0ExVWRJd1FZTUJhQUZIN1I0eUMrVWVoSUlQZXVMOFpxdzNQegpjZ2NaTUE4R0ExVWRFd0VCL3dRRk1BTUJBZjh3RGdZRFZSMFBBUUgvQkFRREFnR0dNQTBHQ1NxR1NJYjNEUUVCCkR3VUFBNElCQVFCRE52RDJWbTlzQTVBOUFsT0pSOCtlbjVYejloWGN4SkI1cGh4Y1pROGpGb0cwNFZzaHZkMGUKTUVuVXJNY2ZGZ0laNG5qTUtUUUNNNFpGVVBBaWV5THg0ZjUySHVEb3BwM2U1SnlJTWZXK0tGY05JcEt3Q3NhawpwU29LdElVT3NVSks3cUJWWnhjckl5ZVFWMnFjWU9lWmh0UzV3QnFJd09BaEZ3bENFVDdaZTU4UUhtUzQ4c2xqCjVlVGtSaml2QWxFeHJGektjbGpDNGF4S1Fsbk92VkF6eitHbTMyVTB4UEJGNEJ5ZVBWeENKVUh3MVRzeVRtZWwKU3hORXA3eUhvWGN3bitmWG5hK3Q1SldoMWd4VVp0eTMKLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQo=
        mode: 0644
        overwrite: true
        path: /etc/pki/ca-trust/source/anchors/examplecorp-ca.crt

マシンの信頼ストアは、ノードの信頼ストアの更新もサポートする必要があります。

4.2.8. 更新

RHCOS ノードで証明書を自動更新できる Operator はありません。

注記

Red Hat では、CA の有効期限が切れるタイミングを監視しません。ただし、CA の有効期間は長く設定されるため、通常問題は生じません。ただし、信頼バンドルを定期的に更新する必要がある場合があります。

4.3. サービス CA 証明書

4.3.1. 目的

service-ca は、OpenShift Container Platform クラスターのデプロイ時に自己署名の CA を作成する Operator です。

4.3.2. 有効期限

カスタムの有効期限はサポートされません。自己署名 CA は、フィールド tls.crt (証明書)、tls.key (プライベートキー)、および ca-bundle.crt (CA バンドル) の修飾名 service-ca/signing-key を持つシークレットに保存されます。

他のサービスは、サービスリソースに service.beta.openshift.io/serving-cert-secret-name: <secret name> のアノテーションを付けてサービス提供証明書を要求できます。応答として、Operator は、名前付きシークレットに対し、新規証明書を tls.crt として、プライベートキーを tls.key として生成します。証明書は 2 年間有効です。

他のサービスは、サービス CA から生成される証明書の検証をサポートするために、service.beta.openshift.io/inject-cabundle: true のアノテーションを付けてサービス CA の CA バンドルを API サービスまたは設定マップリソースに挿入するように要求します。応答として、Operator はその現在の CA バンドルを API サービスの CABundle フィールドに書き込むか、service-ca.crt として設定マップに書き込みます。

OpenShift Container Platform 4.3.5 の時点で、自動ローテーションはサポートされ、一部の 4.2.z および 4.3.z リリースにバックポートされます。自動ローテーションをサポートするすべてのリリースについて、サービス CA は 26 ヵ月間有効であり、有効期間までの残りの期間が 13 ヵ月未満になると自動的に更新されます。必要に応じて、サービス CA を手動で更新することができます。

サービス CA 有効期限の 26 ヵ月は、サポートされる OpenShift Container Platform クラスターの予想されるアップグレード間隔よりも長くなります。そのため、サービス CA 証明書のコントロールプレーン以外のコンシューマーは CA のローテーション後に更新され、またローテーション前の CA の有効期限が切れる前に更新されます。

警告

手動でローテーションされるサービス CA は、直前のサービス CA で信頼を維持しません。クラスターの Pod が再起動するまでサービスが一時的に中断する可能性があります。これにより、Pod が新規サービス CA で発行されるサービス提供証明書を使用できるようになります。

重要

service-ca 証明書を使用するアプリケーションは、CA 証明書を動的に再読み込みできる必要があります。そうしないと、自動ローテーションが発生したときに、証明書を信頼するためにアプリケーション Pod を再起動する必要がある場合があります。

4.3.3. 管理

これらの証明書は、ユーザーではなく、システムによって管理されます。

4.3.4. サービス

サービス CA 証明書を使用するサービスには以下が含まれます。

  • cluster-autoscaler-operator
  • cluster-monitoring-operator
  • cluster-authentication-operator
  • cluster-image-registry-operator
  • cluster-ingress-operator
  • cluster-kube-apiserver-operator
  • cluster-kube-controller-manager-operator
  • cluster-kube-scheduler-operator
  • cluster-networking-operator
  • cluster-openshift-apiserver-operator
  • cluster-openshift-controller-manager-operator
  • cluster-samples-operator
  • machine-config-operator
  • console-operator
  • insights-operator
  • machine-api-operator
  • operator-lifecycle-manager

これはすべてを網羅したリストではありません。

関連情報

4.4. ノード証明書

4.4.1. 目的

ノード証明書はクラスターによって署名され、kubelet が Kubernetes API サーバーと通信できるようにします。これらは、ブートストラッププロセスで生成される kubelet CA 証明書から取得されます。

4.4.2. 場所

kubelet CA 証明書は、openshift-kube-apiserver-operator namespace の kube-apiserver-to-kubelet-signer シークレットにあります。

4.4.3. 管理

これらの証明書は、ユーザーではなく、システムによって管理されます。

4.4.4. 有効期限

ノード証明書は 292 日後に自動的にローテーションされ、365 日後に期限切れになります。

4.4.5. 更新

Kubernetes API Server Operator は、292 日後に新規の kube-apiserver-to-kubelet-signer CA 証明書を自動的に生成します。古い CA 証明書は 365 日後に削除されます。kubelet CA 証明書を更新または削除しても、ノードは再起動されません。

クラスター管理者は、次のコマンドを実行して kubelet CA 証明書を手動で更新できます。

$ oc annotate -n openshift-kube-apiserver-operator secret kube-apiserver-to-kubelet-signer auth.openshift.io/certificate-not-after-
関連情報

4.5. ブートストラップ証明書

4.5.1. 目的

OpenShift Container Platform 4 以降では、kubelet は /etc/kubernetes/kubeconfig にあるブートストラップ証明書を使用して初回のブートストラップを実行します。その次に、ブートストラップの初期化プロセス および CSR を作成するための kubelet の認証 に進みます。

このプロセスでは、kubelet はブートストラップチャネル上での通信中に CSR を生成します。コントローラーマネージャーは CSR に署名すると、kubelet が管理する証明書が作成されます。

4.5.2. 管理

これらの証明書は、ユーザーではなく、システムによって管理されます。

4.5.3. 有効期限

このブートストラップ証明書は 10 年間有効です。

kubelet が管理する証明書は 1 年間有効であり、その 1 年の約 80 パーセントマークで自動的にローテーションします。

注記

OpenShift Lifecycle Manager (OLM) は、ブートストラップ証明書を更新しません。

4.5.4. カスタマイズ

ブートストラップ証明書をカスタマイズすることはできません。

4.6. etcd 証明書

4.6.1. 目的

etcd 証明書は etcd-signer によって署名されます。それらの証明書はブートストラッププロセスで生成される認証局 (CA) から提供されます。

4.6.2. 有効期限

CA 証明書は 10 年間有効です。ピア、クライアント、およびサーバーの証明書は 3 年間有効です。

4.6.3. 管理

これらの証明書はシステムによってのみ管理され、自動的にローテーションされます。

4.6.4. サービス

etcd 証明書は、etcd メンバーのピア間の暗号化された通信と暗号化されたクライアントトラフィックに使用されます。以下の証明書は etcd および etcd と通信する他のプロセスによって生成され、使用されます。

  • ピア証明書: etcd メンバー間の通信に使用されます。
  • クライアント証明書: 暗号化されたサーバーとクライアント間の通信に使用されます。現時点で、クライアント証明書は API サーバーによってのみ使用され、プロキシーを除いてその他のサービスは etcd に直接接続されません。クライアントシークレット (etcd-clientetcd-metric-clientetcd-metric-signer、および etcd-signer) は openshift-configopenshift-monitoring、および openshift-kube-apiserver namespace に追加されます。
  • サーバー証明書: クライアント要求を認証するために etcd サーバーによって使用されます。
  • メトリック証明書: メトリックのすべてのコンシューマーは metric-client 証明書を使用してプロキシーに接続します。
関連情報

4.7. OLM 証明書

4.7.1. 管理

Operator Lifecycle Manager (OLM) コンポーネント (olm-operatorcatalog-operatorpackageserver、および marketplace-operator) のすべての証明書はシステムによって管理されます。

Webhook または API サービスを含む Operator を ClusterServiceVersion (CSV) オブジェクトにインストールする場合、OLM はこれらのリソースの証明書を作成し、ローテーションします。openshift-operator-lifecycle-manager namespace のリソースの証明書は OLM によって管理されます。

OLM はプロキシー環境で管理する Operator の証明書を更新しません。これらの証明書は、ユーザーがサブスクリプション設定で管理する必要があります。

4.8. 集合 API クライアント証明書

4.8.1. 目的

集約 API クライアント証明書は、集約 API サーバーに接続するときに KubeAPIServer を認証するために使用されます。

4.8.2. 管理

これらの証明書は、ユーザーではなく、システムによって管理されます。

4.8.3. 有効期限

この CA は 30 日間有効です。

管理クライアント証明書は 30 日間有効です。

CA およびクライアント証明書は、コントローラーを使用して自動的にローテーションされます。

4.8.4. カスタマイズ

集約された API サーバー証明書をカスタマイズすることはできません。

4.9. Machine Config Operator 証明書

4.9.1. 目的

この認証局は、初期プロビジョニング中にノードから Machine Config Server (MCS) への接続を保護するために使用されます。

証明書は 2 つあります。自己署名 CA (MCS CA)。派生証明書、MCS 証明書

4.9.1.1. プロビジョニングの詳細

Red Hat Enterprise Linux CoreOS (RHCOS) を使用する OpenShift Container Platform インストールは、Ignition を使用してインストールされます。このプロセスは 2 つの部分に分かれています。

  1. MCS によって提供される完全な設定の URL を参照する Ignition 設定が作成されます。
  2. ユーザーがプロビジョニングしたインフラストラクチャーのインストール方法の場合、Ignition 設定は、openshift-install コマンドによって作成された worker.ign ファイルとしてマニフェストされます。Machine API Operator を使用する、インストーラーがプロビジョニングするインフラストラクチャーのインストール方法の場合、この設定は worker-user-data シークレットとして表示されます。
重要

現在、マシン設定サーバーエンドポイントをブロックまたは制限する方法はサポートされていません。マシン設定サーバーは、既存の設定または状態を持たない新しくプロビジョニングされたマシンが設定を取得できるように、ネットワークに公開する必要があります。このモデルでは、信頼のルートは証明書署名要求 (CSR) エンドポイントであり、kubelet がクラスターに参加するための承認のために証明書署名要求を送信する場所です。このため、シークレットや証明書などの機密情報を配布するためにマシン設定を使用しないでください。

マシン設定サーバーエンドポイント、ポート 22623 および 22624 がベアメタルシナリオで確実に保護されるようにするには、顧客は適切なネットワークポリシーを設定する必要があります。

4.9.1.2. 信頼チェーンのプロビジョニング

MCS CA は、security.tls.certificateAuthorities 設定フィールドの下の Ignition 設定に挿入されます。その後、MCS は、Web サーバーによって提示された MCS 証明書を使用して完全な設定を提供します。

クライアントは、サーバーによって提示された MCS 証明書に、認識する機関への信頼チェーンがあることを検証します。この場合、MCS CA がその認証局であり、MCS 証明書に署名します。これにより、クライアントが正しいサーバーにアクセスしていることを確認できます。この場合のクライアントは、initramfs のマシン上で実行されている Ignition です。

4.9.1.3. クラスター内のキーマテリアル

MCS CA は、ca.crt キーを持つ kube-system namespace、root-ca オブジェクト内の config map としてクラスターに表示されます。秘密鍵はクラスターに保存されず、インストール完了後に破棄されます。

MCS 証明書は、tls.crt キーと tls.key キーを持つ openshift-machine-config-operator namespace および machine-config-server-tls オブジェクト内のシークレットとしてクラスターに表示されます。

4.9.2. 管理

現時点では、これらの証明書のいずれかを直接変更することはサポートされていません。

4.9.3. 有効期限

MCS CA は 10 年間有効です。

発行されたサービング証明書は 10 年間有効です。

4.9.4. カスタマイズ

Machine Config Operator 証明書をカスタマイズすることはできません。

4.10. デフォルト ingress のユーザーによって提供される証明書

4.10.1. 目的

アプリケーションは通常 <route_name>.apps.<cluster_name>.<base_domain> で公開されます。<cluster_name> および <base_domain> はインストール設定ファイルから取得されます。<route_name> は、(指定されている場合) ルートのホストフィールド、またはルート名です。例: hello-openshift-default.apps.username.devcluster.openshift.com.hello-openshift はルートの名前で、ルートは default namespace に置かれます。クラスター管理の CA 証明書をクライアントに分散せずに、クライアントにアプリケーションにアクセスさせる必要がある場合があります。管理者は、アプリケーションコンテンツを提供する際にカスタムのデフォルト証明書を設定する必要があります。

警告

Ingress Operator は、カスタムのデフォルト証明書を設定するまで、プレースホルダーとして機能する Ingress コントローラーのデフォルト証明書を生成します。実稼働クラスターで Operator が生成するデフォルト証明書を使用しないでください。

4.10.2. 場所

ユーザーによって提供される証明書は、openshift-ingress namespace の tls タイプの Secret で指定される必要があります。ユーザーがユーザーによって提供される証明書を有効にできるようにするために、openshift-ingress-operator namespace で IngressController CR を更新します。このプロセスの詳細は、カスタムデフォルト証明書の設定 を参照してください。

4.10.3. 管理

ユーザーによって提供される証明書はユーザーによって管理されます。

4.10.4. 有効期限

ユーザーによって提供される証明書はユーザーによって管理されます。

4.10.5. サービス

クラスターにデプロイされるアプリケーションは、デフォルト Ingress にユーザーによって提供される証明書を使用します。

4.10.6. カスタマイズ

必要に応じて、ユーザーが管理する証明書を含むシークレットを更新します。

関連情報

4.11. Ingress 証明書

4.11.1. 目的

Ingress Operator は以下の目的で証明書を使用します。

  • Prometheus のメトリックへのアクセスのセキュリティーを保護する。
  • ルートへのアクセスのセキュリティーを保護する。

4.11.2. 場所

Ingress Operator および Ingress コントローラーメトリックへのアクセスのセキュリティーを保護するために、Ingress Operator はサービス提供証明書を使用します。Operator は独自のメトリックについて service-ca コントローラーから証明書を要求し、service-ca コントローラーは証明書を openshift-ingress-operator namespace の metrics-tls という名前のシークレットに配置します。さらに、Ingress Operator は各 Ingress コントローラーの証明書を要求し、service-ca コントローラーは証明書を router-metrics-certs-<name> という名前のシークレットに配置します。ここで、<name>openshift-ingress namespace の Ingress コントローラーの名前です。

各 Ingress コントローラーには、独自の証明書を指定しないセキュリティー保護されたルートに使用するデフォルト証明書があります。カスタム証明書を指定しない場合、Operator はデフォルトで自己署名証明書を使用します。Operator は独自の自己署名証明書を使用して、生成するデフォルト証明書に署名します。Operator はこの署名証明書を生成し、これを openshift-ingress-operator namespace の router-ca という名前のシークレットに配置します。Operator がデフォルトの証明書を生成する際に、デフォルト証明書を openshift-ingress namespace の router-certs-<name> という名前のシークレットに配置します (ここで、<name> は Ingress コントローラーの名前です)。

警告

Ingress Operator は、カスタムのデフォルト証明書を設定するまで、プレースホルダーとして機能する Ingress コントローラーのデフォルト証明書を生成します。実稼働クラスターで Operator が生成するデフォルト証明書は使用しないでください。

4.11.3. ワークフロー

図4.1 カスタム証明書のワークフロー

図4.2 デフォルトの証明書ワークフロー

20 空の defaultCertificate フィールドにより、Ingress Operator はその自己署名 CA を使用して指定されたドメインの提供証明書を生成します。

20 Ingress Operator によって生成されるデフォルトの CA 証明書およびキー。Operator が生成するデフォルトの提供証明書に署名するために使用されます。

20 デフォルトのワークフローでは、Ingress Operator によって作成され、生成されるデフォルト CA 証明書を使用して署名されるワイルドカードのデフォルト提供証明書です。カスタムワークフローでは、これはユーザーによって提供される証明書です。

20 ルーターのデプロイメント。secrets/router-certs-default の証明書を、デフォルトのフロントエンドサーバー証明書として使用します。

20 デフォルトのワークフローでは、ワイルドカードのデフォルト提供証明書 (パブリックおよびプライベートの部分) の内容がここにコピーされ、OAuth 統合が有効になります。カスタムワークフローでは、これはユーザーによって提供される証明書です。

20 デフォルト提供証明書のパブリック (証明書) の部分です。configmaps/router-ca リソースを置き換えます。

20 ユーザーは ingresscontroller 提供証明書に署名した CA 証明書でクラスタープロキシー設定を更新します。これにより、authconsole などのコンポーネントや、提供証明書を信頼するために使用するレジストリーが有効になります。

20 ユーザーバンドルが指定されていない場合に、組み合わせた Red Hat Enterprise Linux CoreOS (RHCOS) およびユーザーによって提供される CA バンドルまたは RHCOS のみのバンドルを含むクラスター全体の信頼される CA バンドルです。

20 他のコンポーネント (auth および console など) がカスタム証明書で設定された ingresscontroller を信頼するよう指示するカスタム CA 証明書バンドルです。

20 trustedCA フィールドは、ユーザーによって提供される CA バンドルを参照するように使用されます。

20 Cluster Network Operator は、信頼される CA バンドルを proxy-ca 設定マップに挿入します。

20 OpenShift Container Platform 4.13 以降は default-ingress-cert を使用します。

4.11.4. 有効期限

Ingress Operator の証明書の有効期限は以下の通りです。

  • service-ca コントローラーが作成するメトリック証明書の有効期限は、作成日から 2 年間です。
  • Operator の署名証明書の有効期限は、作成日から 2 年間です。
  • Operator が生成するデフォルト証明書の有効期限は、作成日から 2 年間です。

Ingress Operator または service-ca コントローラーが作成する証明書のカスタム有効期限を指定することはできません。

Ingress Operator または service-ca コントローラーが作成する証明書について OpenShift Container Platform をインストールする場合に、有効期限を指定することはできません。

4.11.5. サービス

Prometheus はメトリックのセキュリティーを保護する証明書を使用します。

Ingress Operator はその署名証明書を使用して、カスタムのデフォルト証明書を設定しない Ingress コントローラー用に生成するデフォルト証明書に署名します。

セキュリティー保護されたルートを使用するクラスターコンポーネントは、デフォルトの Ingress コントローラーのデフォルト証明書を使用できます。

セキュリティー保護されたルート経由でのクラスターへの Ingress は、ルートが独自の証明書を指定しない限り、ルートがアクセスされる Ingress コントローラーのデフォルト証明書を使用します。

4.11.6. 管理

Ingress 証明書はユーザーによって管理されます。詳細は、デフォルト ingress 証明書の置き換え を参照してください。

4.11.7. 更新

service-ca コントローラーは、これが発行する証明書を自動的にローテーションします。ただし、oc delete secret <secret> を使用してサービス提供証明書を手動でローテーションすることができます。

Ingress Operator は、独自の署名証明書または生成するデフォルト証明書をローテーションしません。Operator が生成するデフォルト証明書は、設定するカスタムデフォルト証明書のプレースホルダーとして使用されます。

4.12. モニタリングおよび OpenShift Logging Operator コンポーネント証明書

4.12.1. 有効期限

モニタリングコンポーネントは、サービス CA 証明書でトラフィックのセキュリティーを保護します。これらの証明書は 2 年間有効であり、13 ヵ月ごとに実行されるサービス CA のローテーションで自動的に置き換えられます。

証明書が openshift-monitoring または openshift-logging namespace にある場合、これはシステムで管理され、自動的にローテーションされます。

4.12.2. 管理

これらの証明書は、ユーザーではなく、システムによって管理されます。

4.13. コントロールプレーンの証明書

4.13.1. 場所

コントロールプレーンの証明書はこれらの namespace に含まれます。

  • openshift-config-managed
  • openshift-kube-apiserver
  • openshift-kube-apiserver-operator
  • openshift-kube-controller-manager
  • openshift-kube-controller-manager-operator
  • openshift-kube-scheduler

4.13.2. 管理

コントロールプレーンの証明書はシステムによって管理され、自動的にローテーションされます。

稀なケースとして、コントロールプレーンの証明書の有効期限が切れている場合は、コントロールプレーン証明書の期限切れの状態からのリカバリー を参照してください。

第5章 Compliance Operator

5.1. Compliance Operator の概要

OpenShift Container Platform Compliance Operator は、多数の技術実装の検査を自動化することでユーザーを支援し、それらを業界標準、ベンチマーク、およびベースラインの特定の要素と比較します。ただし、Compliance Operator は監査人ではありません。このようなさまざまな標準に対する準拠または認定を実現するには、Qualified Security Assessor (QSA)、Joint Authorization Board (JAB)、または業界で認められたその他の規制当局など、認定監査機関に依頼して、環境の評価を受ける必要があります。

Compliance Operator は、このような標準に関する一般に入手可能な情報とプラクティスに基づいて推奨事項を作成し、場合によっては修復を支援します。ただし、実際の準拠はお客様の責任となります。標準への準拠を実現するには、認定監査人と協力する必要があります。最新の更新については、Compliance Operator リリースノート を参照してください。

Compliance Operator の概念

Compliance Operator について

カスタムリソース定義を理解する

Compliance Operator の管理

Compliance Operator のインストール

Compliance Operator の更新

Compliance Operator の管理

Compliance Operator のアンインストール

Compliance Operator のスキャンの管理

サポートされているコンプライアンスプロファイル

Compliance Operator のスキャン

Compliance Operator の調整

Compliance Operator の未加工の結果の取得

コンプライアンス Operator 修復の管理

高度な Compliance Operator タスクの実行

Compliance Operator のトラブルシューティング

oc-compliance プラグインの使用

5.2. Compliance Operator リリースノート

Compliance Operator を使用すると、OpenShift Container Platform 管理者はクラスターの必要なコンプライアンス状態を記述し、存在するギャップやそれらを修復する方法に関する概要を提供します。

これらのリリースノートは、OpenShift Container Platform での Compliance Operator の開発を追跡します。

Compliance Operator の概要については、Understanding the Compliance Operator を参照してください。

最新リリースにアクセスするには、コンプライアンス Operator の更新 を参照してください。

5.2.1. OpenShift Compliance Operator 1.6.0

OpenShift Compliance Operator 1.6.0 については、以下のアドバイザリーが利用できます。

5.2.1.1. 新機能および機能拡張
  • Compliance Operator には現在、Payment Card Industry Data Security Standard (PCI-DSS) バージョン 4 でサポートされているプロファイルが含まれています。詳細は、サポートされているコンプライアンスプロファイル を参照してください。
  • Compliance Operator には現在、Defense Information Systems Agency Security Technical Implementation Guide (DISA STIG) V2R1 でサポートされているプロファイルが含まれています。詳細は、サポートされているコンプライアンスプロファイル を参照してください。
  • x86ppc64le、および s390x アーキテクチャーにインストールされた Compliance Operator で、must-gather 拡張が利用できるようになりました。must-gather ツールにより、重要な設定の詳細が Red Hat Customer Support チームと Engineering チームに提供されます。詳細は、Compliance Operator の must-gather ツールの使用 を参照してください。
5.2.1.2. バグ修正
  • このリリース前は、ocp4-route-ip-whitelist ルールの誤解を招くような説明により誤解が生じ、誤った設定が発生する可能性がありました。この更新により、ルールがより明確に定義されるようになりました。(CMP-2485)
  • 以前は、DONE ステータスの ComplianceScan のすべての ComplianceCheckResults のレポートが不完全でした。この更新により、ステータスが DONE である ComplianceScanComplianceCheckResults の合計数を報告するためのアノテーションが追加されました。(CMP-2615)
  • 以前は、ocp4-cis-scc-limit-container-allowed-capabilities ルールの説明に曖昧なガイドラインが含まれていたため、ユーザーの間で混乱が生じていました。この更新により、ルールの説明と実行可能な手順が明確になりました。(OCPBUGS-17828)
  • この更新前は、sysctl 設定により、RHCOS4 ルールの特定の自動修復が、影響を受けるクラスターでスキャンに失敗していました。この更新により、正しい sysctl 設定が適用され、FedRAMP High プロファイルの RHCOS4 ルールが正しくスキャンされるようになりました。(OCPBUGS-19690)
  • この更新前は、jq フィルターの問題により、コンプライアンスチェック中に rhacs-operator-controller-manager デプロイメントでエラーが発生していました。この更新により、jq フィルター式が更新され、rhacs-operator-controller-manager デプロイメントはコンテナーリソース制限に関するコンプライアンスチェックから免除され、誤検知の結果が排除されます。(OCPBUGS-19690)
  • この更新前は、rhcos4-high および rhcos4-moderate プロファイルは、誤ったタイトルの設定ファイルの値をチェックしていました。その結果、一部のスキャンチェックが失敗する可能性がありました。この更新により、rhcos4 プロファイルは正しい設定ファイルをチェックし、正しくスキャンされるようになりました。(OCPBUGS-31674)
  • 以前は、oauthclient-inactivity-timeout ルールで使用される accessokenInactivityTimeoutSeconds 変数はイミュータブルだったため、DISA STIG スキャンを実行すると FAIL ステータスになりました。この更新により、accessTokenInactivityTimeoutSeconds 変数の適切な適用が正しく動作し、PASS ステータスが可能になりました。(OCPBUGS-32551)
  • この更新前は、ルールの一部のアノテーションが更新されず、誤った制御標準が表示されていました。この更新により、ルールのアノテーションが正しく更新され、正しい制御標準が表示されるようになります。(OCPBUGS-34982)
  • 以前は、Compliance Operator 1.5.1 にアップグレードすると、ServiceMonitor 設定で誤って参照されたシークレットが原因で、Prometheus Operator とのインテグレーションの問題が発生していました。この更新により、Compliance Operator は ServiceMonitor メトリクスのトークンを含むシークレットを正確に参照するようになります。(OCPBUGS-39417)

5.2.2. OpenShift Compliance Operator 1.5.1

OpenShift Compliance Operator 1.5.1 については、以下のアドバイザリーが利用できます。

5.2.3. OpenShift Compliance Operator 1.5.0

OpenShift Compliance Operator 1.5.0 については、以下のアドバイザリーが利用できます。

5.2.3.1. 新機能および機能拡張
  • この更新により、Compliance Operator はプログラムで容易に使用できる一意のプロファイル ID を提供します。(CMP-2450)
  • このリリースでは、Compliance Operator が ROSA HCP 環境でテストされ、サポートされるようになりました。Compliance Operator は、ROSA HCP 上で実行されるとノードプロファイルのみを読み込みます。これは、Red Hat が管理するプラットフォームではコントロールプレーンへのアクセスが制限され、Platform プロファイルが Operator の機能とは無関係になるためです (CMP-2581)。
5.2.3.2. バグ修正
  • CVE-2024-2961 は、Compliance Operator 1.5.0 リリースで解決されています。(CVE-2024-2961)
  • 以前は、ROSA HCP システムにおけるプロファイルリストが正しくありませんでした。この更新により、Compliance Operator のプロファイル出力が正しくなりました。(OCPBUGS-34535)
  • このリリースでは、カスタマイズされたプロファイルで ocp4-var-network-policies-namespaces-exempt-regex 変数を設定することにより、namespace を ocp4-configure-network-policies-namespaces チェックから除外できるようになりました。(CMP-2543)

5.2.4. OpenShift Compliance Operator 1.4.1

OpenShift Compliance Operator 1.4.1 については、以下のアドバイザリーが利用できます。

5.2.4.1. 新機能および機能拡張
  • このリリース以降、Compliance Operator は CIS OpenShift 1.5.0 プロファイルルールを提供するようになりました。(CMP-2447)
  • この更新により、Compliance Operator がプロファイルルールとともに OCP4 STIG IDSRG を提供するようになりました。(CMP-2401)
  • この更新により、s390x に適用されていた古いルールが削除されました。(CMP-2471)
5.2.4.2. バグ修正
  • 以前は、Red Hat Enterprise Linux (RHEL) 9 を使用する Red Hat Enterprise Linux CoreOS (RHCOS) システムでは、ocp4-kubelet-enable-protect-kernel-sysctl-file-exist ルールの適用に失敗していました。この更新により、ルールが ocp4-kubelet-enable-protect-kernel-sysctl に置き換えられました。自動修復が適用されると、RHEL9 ベースの RHCOS システムでは、このルールの適用時に PASS と表示されるようになりました。(OCPBUGS-13589)
  • 以前は、プロファイル rhcos4-e8 を使用してコンプライアンス修正を適用した後、コアユーザーアカウントへの SSH 接続を使用してノードにアクセスできなくなりました。この更新により、ノードは `sshkey1 オプションを使用して SSH 経由でアクセス可能になります。(OCPBUGS-18331)
  • 以前は、STIG プロファイルに、OpenShift Container Platform 用に公開された STIG の要件を満たす CaC のルールがありませんでした。この更新により、修復時に、Compliance Operator を使用して修復できる STIG 要件をクラスターが満たすようになります。(OCPBUGS-26193)
  • 以前は、複数の製品に対して異なるタイプのプロファイルを持つ ScanSettingBinding オブジェクトを作成すると、バインディング内の複数の製品タイプに対する制限が回避されていました。この更新により、ScanSettingBinding オブジェクトのプロファイルタイプに関係なく、製品検証で複数の製品が許可されるようになりました。(OCPBUGS-26229)
  • 以前は、自動修復が適用された後でも、rhcos4-service-debug-shell-disabled ルールを実行すると、FAIL と表示されていました。この更新により、自動修復が適用された後に rhcos4-service-debug-shell-disabled ルールを実行すると、PASS と表示されるようになりました。(OCPBUGS-28242)
  • この更新により、rhcos4-banner-etc-issue ルールの使用手順が強化され、より詳細な情報が提供されるようになりました。(OCPBUGS-28797)
  • 以前は、api_server_api_priority_flowschema_catch_all ルールが OpenShift Container Platform 4.16 クラスターで FAIL ステータスを示していました。この更新により、api_server_api_priority_flowschema_catch_all ルールが OpenShift Container Platform 4.16 クラスターで PASS ステータスを示すようになりました。(OCPBUGS-28918)
  • 以前は、ScanSettingBinding (SSB) オブジェクトに表示される完了したスキャンからプロファイルを削除した場合、Compliance Operator が古いスキャンを削除しませんでした。その後、削除したプロファイルを使用して新しい SSB を起動すると、Compliance Operator が結果を更新できませんでした。この Compliance Operator のリリースでは、新しい SSB に新しいコンプライアンスチェック結果が表示されるようになりました。(OCPBUGS-29272)
  • 以前は、ppc64le アーキテクチャーでは、メトリクスサービスが作成されませんでした。この更新により、Compliance Operator v1.4.1 を ppc64le アーキテクチャーにデプロイするときに、メトリクスサービスが正しく作成されるようになりました。(OCPBUGS-32797)
  • 以前は、HyperShift ホストクラスターでは、filter cannot iterate 問題により、ocp4-pci-dss profile を使用したスキャンで回復不能なエラーが発生していました。このリリースでは、ocp4-pci-dss プロファイルのスキャンが done ステータスに達し、Compliance または Non-Compliance のテスト結果が返されます。(OCPBUGS-33067)

5.2.5. OpenShift Compliance Operator 1.4.0

OpenShift Compliance Operator 1.4.0 については、以下のアドバイザリーが利用できます。

5.2.5.1. 新機能および機能拡張
  • この更新により、デフォルトの worker および master ノードプール以外のカスタムノードプールを使用するクラスターで、Compliance Operator がそのノードプールの設定ファイルを確実に集約するための追加変数を指定する必要がなくなりました。
  • ユーザーは、ScanSetting.suspend 属性を True に設定することで、スキャンスケジュールを一時停止できるようになりました。これにより、ユーザーは ScanSettingBinding を削除して再作成することなく、スキャンスケジュールを一時停止し、再アクティブ化できます。そのため、メンテナンス期間中のスキャンスケジュールを簡単に一時停止できます。(CMP-2123)
  • Compliance Operator は、Profile カスタムリソースでオプションの version 属性をサポートするようになりました。(CMP-2125)
  • Compliance Operator は、ComplianceRules のプロファイル名をサポートするようになりました。(CMP-2126)
  • このリリースでは、cronjob API が改良された Compliance Operator の互換性を使用できます。(CMP-2310)
5.2.5.2. バグ修正
  • 以前は、Windows ノードがコンプライアンススキャンでスキップされなかったため、Windows ノードを含むクラスターでは、自動修復の適用後に一部のルールが失敗していました。このリリースでは、スキャン時に Windows ノードが正しくスキップされます。(OCPBUGS-7355)
  • この更新により、rprivate のデフォルトのマウント伝播が、マルチパス構成に依存する Pod のルートボリュームマウントに対して正しく処理されるようになりました。(OCPBUGS-17494)
  • 以前は、Compliance Operator は、修復の適用中であってもルールを調整せずに coreos_vsyscall_kernel_argument の修復を生成していました。リリース 1.4.0 では、coreos_vsyscall_kernel_argument ルールがカーネル引数を適切に評価し、適切な修復を生成するようになりました。(OCPBUGS-8041)
  • この更新より前は、自動修復が適用された後でも、rhcos4-audit-rules-login-events-faillock のルールが失敗していました。この更新により、rhcos4-audit-rules-login-events-faillock の失敗ロックが自動修復後に正しく適用されるようになりました。(OCPBUGS-24594)
  • 以前は、Compliance Operator 1.3.1 から Compliance Operator 1.4.0 にアップグレードすると、OVS ルールのスキャン結果が PASS から NOT-APPLICABLE に変わりました。この更新により、OVS ルールのスキャン結果に PASS が表示されるようになりました (OCPBUGS-25323)

5.2.6. OpenShift Compliance Operator 1.3.1

OpenShift Compliance Operator 1.3.1 については、以下のアドバイザリーが利用できます。

この更新プログラムは、基になる依存関係の CVE に対処します。

重要

OpenShift Container Platform クラスターをバージョン 4.14 以降に更新する前に、Compliance Operator をバージョン 1.3.1 以降に更新することが推奨されます。

5.2.6.1. 新機能および機能拡張
  • Compliance Operator は、FIPS モードで実行されている OpenShift Container Platform クラスターにインストールして使用できます。

    重要

    クラスターで FIPS モードを有効にするには、FIPS モードで動作するように設定された RHEL コンピューターからインストールプログラムを実行する必要があります。RHEL での FIPS モードの設定の詳細は、FIPS モードでのシステムのインストール を参照してください。

5.2.6.2. 既知の問題
  • Windows ノードがコンプライアンススキャンでスキップされないため、Windows ノードを含むクラスターでは、自動修復の適用後に一部のルールが失敗します。スキャン時に Windows ノードをスキップする必要があるため、これは想定される結果とは異なります。(OCPBUGS-7355)

5.2.7. OpenShift Compliance Operator 1.3.0

OpenShift Compliance Operator 1.3.0 については、以下のアドバイザリーが利用できます。

5.2.7.1. 新機能および機能拡張
  • OpenShift Container Platform の国防情報システム局セキュリティ技術導入ガイド (DISA-STIG) が、Compliance Operator 1.3.0 から利用できるようになりました。詳細は、サポート対象のコンプライアンスプロファイル を参照してください。
  • Compliance Operator 1.3.0 は、NIST 800-53 Moderate-Impact Baseline for OpenShift Container Platform のプラットフォームおよびノードプロファイルに対応する IBM Power および IBM Z をサポートするようになりました。

5.2.8. OpenShift Compliance Operator 1.2.0

OpenShift Compliance Operator 1.2.0 については、以下のアドバイザリーが利用できます。

5.2.8.1. 新機能および機能拡張
  • CIS OpenShift Container Platform 4 Benchmark v1.4.0 プロファイルがプラットフォームおよびノードアプリケーションで利用できるようになりました。CIS OpenShift Container Platform v4 ベンチマークを見つけるには、CIS ベンチマーク に移動し、最新の CIS ベンチマークをダウンロード をクリックします。ここでベンチマークをダウンロードするために登録できます。

    重要

    Compliance Operator 1.2.0 にアップグレードすると、CIS OpenShift Container Platform 4 Benchmark 1.1.0 プロファイルが上書きされます。

    OpenShift Container Platform 環境に既存の cis および cis-node 修復が含まれている場合は、Compliance Operator 1.2.0 にアップグレードした後のスキャン結果に多少の違いが生じる可能性があります。

  • scc-limit-container-allowed-capabilities ルールで、Security Context Constraints (SCC) の監査に関する明確性がさらに向上しました。
5.2.8.2. 既知の問題
  • CIS OpenShift Container Platform 4 Benchmark v1.4.0 プロファイルを使用する場合、一部のコントロールは OpenShift Container Platform よりも厳格な CIS プロファイルのパーミッションにより失敗する可能性があります。詳細は、ソリューション記事 #7024725 を参照してください。

5.2.9. OpenShift Compliance Operator 1.1.0

OpenShift Compliance Operator 1.1.0 については、以下のアドバイザリーを利用できます。

5.2.9.1. 新機能および機能拡張
  • ComplianceScan カスタムリソース定義 (CRD) ステータスで開始および終了のタイムスタンプが利用できるようになりました。
  • Compliance Operator は、サブスクリプション ファイルを作成することで、OperatorHub を使用してホストされたコントロールプレーンにデプロイメントできるようになりました。詳細は、ホストされたコントロールプレーンへのCompliance Operator のインストール を参照してください。
5.2.9.2. バグ修正
  • 今回の更新前は、Compliance Operator ルールの指示の一部が存在していませんでした。今回の更新後、以下のルールの手順が改善されました。

    • classification_banner
    • oauth_login_template_set
    • oauth_logout_url_set
    • oauth_provider_selection_set
    • ocp_allowed_registries
    • ocp_allowed_registries_for_import

      (OCPBUGS-10473)

  • この更新前は、チェックの精度とルールの指示が不明確でした。今回の更新後、次の sysctl ルールのチェック精度と手順が改善されました。

    • kubelet-enable-protect-kernel-sysctl
    • kubelet-enable-protect-kernel-sysctl-kernel-keys-root-maxbytes
    • kubelet-enable-protect-kernel-sysctl-kernel-keys-root-maxkeys
    • kubelet-enable-protect-kernel-sysctl-kernel-panic
    • kubelet-enable-protect-kernel-sysctl-kernel-panic-on-oops
    • kubelet-enable-protect-kernel-sysctl-vm-overcommit-memory
    • kubelet-enable-protect-kernel-sysctl-vm-panic-on-oom

      (OCPBUGS-11334)

  • 今回の更新以前は、ocp4-alert-receiver-configured ルールに命令が含まれていませんでした。今回の更新により、ocp4-alert-receiver-configured ルールに含まれる命令が改善されました。(OCPBUGS-7307)
  • 今回の更新より前は、rhcos4-sshd-set-loglevel-info ルールは rhcos4-e8 プロファイルでは失敗していました。この更新により、sshd-set-loglevel-info ルールの修復が更新され、正しい設定変更が適用され、修復の適用後に後続のスキャンが通過できるようになりました。(OCPBUGS-7816)
  • 今回の更新の前は、最新の Compliance Operator インストールを使用した OpenShift Container Platform の新規インストールは、scheduler-no-bind-address ルールで失敗していました。今回の更新では、パラメーターが削除されたので、OpenShift Container Platform の新しいバージョンでは scheduler-no-bind-address ルールが無効になりました。(OCPBUGS-8347)

5.2.10. OpenShift Compliance Operator 1.0.0

OpenShift Compliance Operator 1.0.0 については、以下のアドバイザリーを利用できます。

5.2.10.1. 新機能および機能拡張
5.2.10.2. バグ修正
  • この更新前は、compliance_operator_compliance_scan_error_total メトリックには、エラーメッセージごとに異なる値を持つ ERROR ラベルがありました。この更新により、compliance_operator_compliance_scan_error_total メトリックの値は増加しません。(OCPBUGS-1803)
  • この更新前は、ocp4-api-server-audit-log-maxsize ルールにより FAIL 状態が発生していました。この更新により、エラーメッセージがメトリックから削除され、ベストプラクティスに従ってメトリックのカーディナリティが減少しました。(OCPBUGS-7520)
  • この更新前は、rhcos4-enable-fips-mode ルールの説明が分かりにくく、インストール後に FIPS を有効化できるという誤解を招くものでした。この更新により、rhcos4-enable-fips-mode ルールの説明で、インストール時に FIPS を有効化する必要があることを明確に示されました。(OCPBUGS-8358)

5.2.11. OpenShift Compliance Operator 0.1.61

OpenShift Compliance Operator 0.1.61 については、以下のアドバイザリーを利用できます。

5.2.11.1. 新機能および機能拡張
  • Compliance Operator は Scanner Pod のタイムアウト設定をサポートするようになりました。タイムアウトは ScanSetting オブジェクトで指定されます。スキャンがタイムアウト内に完了しない場合、スキャンは最大再試行回数に達するまで再試行します。詳細は、ScanSetting タイムアウトの設定 を参照してください。
5.2.11.2. バグ修正
  • 今回の更新以前は、Compliance Operator は必要な変数を入力として修復していました。変数が設定されていない修復はクラスター全体に適用され、修復が正しく適用された場合でも、ノードがスタックしていました。今回の更新により、Compliance Operator は、修復のために TailoredProfile を使用して変数を提供する必要があるかどうかを検証します。(OCPBUGS-3864)
  • 今回の更新以前は、ocp4-kubelet-configure-tls-cipher-suites の手順が不完全であるため、ユーザーはクエリーを手動で調整する必要がありました。今回の更新により、ocp4-kubelet-configure-tls-cipher-suites で提供されるクエリーが実際の結果を返し、監査ステップを実行します。(OCPBUGS-3017)
  • 今回の更新以前は、システム予約パラメーターが kubelet 設定ファイルで生成されず、Compliance Operator はマシン設定プールの一時停止に失敗していました。今回の更新により、Compliance Operator は、マシン設定プールの評価時にシステム予約パラメーターを省略します。(OCPBUGS-4445)
  • 今回の更新以前は、ComplianceCheckResult オブジェクトに正しい説明がありませんでした。今回の更新により、Compliance Operator は、ルールの説明から ComplianceCheckResult 情報を取得します。(OCPBUGS-4615)
  • この更新前は、Compliance Operator はマシン設定の解析時に空の kubelet 設定ファイルをチェックしませんでした。その結果、Compliance Operator はパニックになり、クラッシュします。今回の更新により、Compliance Operator は kubelet 設定データ構造の改善されたチェックを実装し、完全にレンダリングされた場合にのみ続行します。(OCPBUGS-4621)
  • この更新前は、Compliance Operator は、マシン設定プール名と猶予期間に基づいて kubelet エビクションの修復を生成していたため、単一のエビクションルールの複数の修復が発生していました。今回の更新により、Compliance Operator は単一のルールに対してすべての修復を適用するようになりました。(OCPBUGS-4338)
  • この更新の前に、デフォルト以外の MachineConfigPoolTailoredProfile を使用する ScanSettingBinding を作成しようとすると、ScanSettingBindingFailed としてマークされるというリグレッションが発生していました。今回の更新で、機能が復元され、TailoredProfile を使用してカスタム ScanSettingBinding が正しく実行されるようになりました。(OCPBUGS-6827)
  • 今回の更新以前は、一部の kubelet 設定パラメーターにデフォルト値がありませんでした。今回の更新により、次のパラメーターにデフォルト値が含まれます (OCPBUGS-6708)。

    • ocp4-cis-kubelet-enable-streaming-connections
    • ocp4-cis-kubelet-eviction-thresholds-set-hard-imagefs-available
    • ocp4-cis-kubelet-eviction-thresholds-set-hard-imagefs-inodesfree
    • ocp4-cis-kubelet-eviction-thresholds-set-hard-memory-available
    • ocp4-cis-kubelet-eviction-thresholds-set-hard-nodefs-available
  • 今回の更新以前は、kubelet の実行に必要なパーミッションが原因で、selinux_confinement_of_daemons ルールが kubelet で実行できませんでした。今回の更新で、selinux_confinement_of_daemons ルールが無効になります。(OCPBUGS-6968)

5.2.12. OpenShift Compliance Operator 0.1.59

OpenShift Compliance Operator 0.1.59 については、以下のアドバイザリーが利用できます。

5.2.12.1. 新機能および機能拡張
  • Compliance Operator は、ppc64le アーキテクチャーで Payment Card Industry Data Security Standard (PCI-DSS) ocp4-pci-dss および ocp4-pci-dss-node プロファイルをサポートするようになりました。
5.2.12.2. バグ修正
  • 以前は、Compliance Operator は ppc64le などの異なるアーキテクチャーで Payment Card Industry Data Security Standard (PCI DSS) ocp4-pci-dss および ocp4-pci-dss-node プロファイルをサポートしていませんでした。Compliance Operator は、ppc64le アーキテクチャーで ocp4-pci-dss および ocp4-pci-dss-node プロファイルをサポートするようになりました。(OCPBUGS-3252)
  • 以前は、バージョン 0.1.57 への最近の更新後、rerunner サービスアカウント (SA) はクラスターサービスバージョン (CSV) によって所有されなくなり、Operator のアップグレード中に SA が削除されました。現在、CSV は 0.1.59 で rerunner SA を所有しており、以前のバージョンからアップグレードしても SA が欠落することはありません。(OCPBUGS-3452)

5.2.13. OpenShift Compliance Operator 0.1.57

OpenShift Compliance Operator 0.1.57 については、以下のアドバイザリーを利用できます。

5.2.13.1. 新機能および機能拡張
  • KubeletConfig チェックが Node から Platform タイプに変更されました。KubeletConfig は、KubeletConfig のデフォルト設定を確認します。設定ファイルは、すべてのノードからノードプールごとに 1 つの場所に集約されます。デフォルトの設定値をもとにした KubeletConfig ルールの評価 を参照してください。
  • ScanSetting カスタムリソースでは、scanLimits 属性を使用して、スキャナー Pod のデフォルトの CPU およびメモリー制限をオーバーライドできるようになりました。詳細は、Compliance Operator リソース制限の増加 を参照してください。
  • PriorityClass オブジェクトは ScanSetting で設定できるようになりました。これにより、Compliance Operator が優先され、クラスターがコンプライアンス違反になる可能性が最小限に抑えられます。詳細は、ScanSetting スキャンの PriorityClass の設定 を参照してください。
5.2.13.2. バグ修正
  • 以前のバージョンでは、Compliance Operator は通知をデフォルトの openshift-compliance namespace にハードコーディングしていました。Operator がデフォルト以外の namespace にインストールされている場合、通知は予想通りに機能しませんでした。今回のリリースより、通知はデフォルト以外の openshift-compliance namespace で機能するようになりました。(BZ#2060726)
  • 以前のバージョンでは、Compliance Operator は kubelet オブジェクトによって使用されるデフォルト設定を評価できず、不正確な結果と誤検出が発生していました。この新機能 は kubelet 設定を評価し、正確に報告するようになりました。(BZ#2075041)
  • 以前は、Compliance Operator は、eventRecordQPS の値がデフォルト値よりも大きいため、自動修復の適用後に FAIL 状態で ocp4-kubelet-configure-event-creation ルールを報告していました。ocp4-kubelet-configure-event-creation ルール修復はデフォルト値を設定し、ルールが正しく適用されるようになりました。(BZ#2082416)
  • ocp4-configure-network-policies ルールでは、効果的に実行するために手動の介入が必要です。新しい説明的な指示とルールの更新により、Calico CNI を使用するクラスターに対する ocp4-configure-network-policies ルールの適用性が向上します。(BZ#2091794)
  • 以前のリリースでは、コンプライアンスオペレーターは、スキャン設定で debug=true オプションを使用すると、インフラストラクチャーのスキャンに使用される Pod をクリーンアップしませんでした。これにより、ScanSettingBinding を削除した後でも Pod がクラスターに残されました。現在、ScanSettingBinding が削除されると、Pod は常に削除されます (BZ#2092913)。
  • 以前のバージョンでは、Compliance Operator は古いバージョンの operator-sdk コマンドを使用しており、非推奨の機能についてアラートが発生していました。現在、operator-sdk コマンドの更新バージョンが含まれており、廃止された機能に関するアラートが発生することはなくなりました。(BZ#2098581)
  • 以前のバージョンでは、Compliance Operator は kubelet とマシン設定の関係を判別できない場合に、修復の適用に失敗しました。Compliance Operator はマシン設定の処理を改善し、kubelet 設定がマシン設定のサブセットであるかどうかを判別できるようになりました。(BZ#2102511)
  • 以前のリリースでは、ocp4-cis-node-master-kubelet-enable-cert-rotation のルールで成功基準が適切に記述されていませんでした。その結果、RotateKubeletClientCertificate の要件が不明確でした。今回のリリースでは、ocp4-cis-node-master-kubelet-enable-cert-rotation のルールで、kubelet 設定ファイルにある設定に関係なく正確にレポートされるようになりました。(BZ#2105153)
  • 以前のリリースでは、アイドルストリーミングタイムアウトをチェックするルールでデフォルト値が考慮されなかったため、ルールレポートが正確ではありませんでした。今回のリリースより、チェックがより厳密に行われるようになり、デフォルトの設定値に基づいて結果の精度が向上しました。(BZ#2105878)
  • 以前のバージョンでは、Compliance Operator は Ignition 仕様なしでマシン設定を解析する際に API リソースを取得できず、api-check-pods プロセスがクラッシュしていました。Compliance Operator は Ignition 仕様が正しくない場合も Machine Config Pool を処理するようになりました。(BZ#2117268)
  • 以前のリリースでは、modprobe 設定の値が一致しないことが原因で、修復の適用後に modprobe 設定を評価するルールが失敗することがありました。今回のリリースより、チェックおよび修復の modprobe 設定に同じ値が使用されるようになり、結果の一貫性が保たれるようになりました。(BZ#2117747)
5.2.13.3. 非推奨
  • Install into all namespaces in the cluster を指定するか、WATCH_NAMESPACES 環境変数を "" に設定しても、すべての namespace に設定が適用されなくなりました。Compliance Operator のインストール時に指定されていない namespace にインストールされた API リソースは動作しなくなります。API リソースでは、選択した namespace またはデフォルトで openshift-compliance namespace を作成する必要がある場合があります。今回の変更により、Compliance Operator のメモリー使用量が改善されます。

5.2.14. OpenShift Compliance Operator 0.1.53

OpenShift Compliance Operator 0.1.53 については、以下のアドバイザリーが利用できます。

5.2.14.1. バグ修正
  • 以前は、ocp4-kubelet-enable-streaming-connections ルールに誤った変数比較が含まれていたため、スキャン結果が誤検出されていました。現在、Compliance Operator は、streamingConnectionIdleTimeout を設定するときに正確なスキャン結果を提供します。(BZ#2069891)
  • 以前は、/etc/openvswitch/conf.db のグループ所有権が IBM Z アーキテクチャーで正しくなかったため、ocp4-cis-node-worker-file-groupowner-ovs-conf-db のチェックが失敗していました。現在、このチェックは IBM Z アーキテクチャーシステムでは NOT-APPLICABLE とマークされています。(BZ#2072597)
  • 以前は、デプロイメント内の Security Context Constraints (SCC) ルールに関するデータが不完全なため、ocp4-cis-scc-limit-container-allowed-capabilities ルールが FAIL 状態で報告されていました。現在は、結果は MANUAL ですが、これは、人間の介入を必要とする他のチェックと一致しています。(BZ#2077916)
  • 以前は、以下のルールが API サーバーおよび TLS 証明書とキーの追加の設定パスを考慮していなかったため、証明書とキーが適切に設定されていても失敗が報告されていました。

    • ocp4-cis-api-server-kubelet-client-cert
    • ocp4-cis-api-server-kubelet-client-key
    • ocp4-cis-kubelet-configure-tls-cert
    • ocp4-cis-kubelet-configure-tls-key

    これで、ルールは正確にレポートし、kubelet 設定ファイルで指定されたレガシーファイルパスを監視します。(BZ#2079813)

  • 以前は、content_rule_oauth_or_oauthclient_inactivity_timeout ルールは、タイムアウトのコンプライアンスを評価するときに、デプロイメントによって設定された設定可能なタイムアウトを考慮していませんでした。その結果、タイムアウトが有効であってもルールが失敗していました。現在、Compliance Operator は、var_oauth_inactivity_timeout 変数を使用して、有効なタイムアウトの長さを設定しています。(BZ#2081952)
  • 以前は、Compliance Operator は、特権使用に適切にラベル付けされていない namespace に対して管理者権限を使用していたため、Pod のセキュリティーレベル違反に関する警告メッセージが表示されていました。現在、Compliance Operator は、適切な namespace ラベルと権限調整を行い、権限に違反することなく結果にアクセスできるようになっています。(BZ#2088202)
  • 以前は、rhcos4-high-master-sysctl-kernel-yama-ptrace-scope および rhcos4-sysctl-kernel-core-pattern に自動修復を適用すると、それらのルールが修復されても、その後のスキャン結果で失敗することがありました。現在、修復が適用された後でも、ルールは PASS を正確に報告します。(BZ#2094382)
  • 以前は、Compliance Operator は、メモリー不足の例外が原因で CrashLoopBackoff 状態で失敗していました。現在では、Compliance Operator は、メモリー内の大規模なマシン設定データセットを処理し、正しく機能するように改良されました。(BZ#2094854)
5.2.14.2. 既知の問題
  • ScanSettingBinding オブジェクト内で "debug":true が設定されている場合に、そのバインディングが削除されても、ScanSettingBinding オブジェクトによって生成された Pod は削除されません。回避策として、次のコマンドを実行して残りの Pod を削除します。

    $ oc delete pods -l compliance.openshift.io/scan-name=ocp4-cis

    (BZ#2092913)

5.2.15. OpenShift Compliance Operator 0.1.52

OpenShift Compliance Operator 0.1.52 については、以下のアドバイザリーが利用できます。

5.2.15.1. 新機能および機能拡張
5.2.15.2. バグ修正
  • 以前は、DAC_OVERRIDE 機能が削除されているセキュリティー環境でのマウントパーミッションの問題が原因で、OpenScap コンテナーがクラッシュしていました。今回は、実行可能なマウントパーミッションがすべてのユーザーに適用されるようになりました。(BZ#2082151)
  • 以前は、コンプライアンスルール ocp4-configure-network-policiesMANUAL として設定できました。今回は、コンプライアンスルール ocp4-configure-network-policiesAUTOMATIC に設定されるようになりました。(BZ#2072431)
  • 以前は、Compliance Operator のスキャン Pod はスキャン後に削除されないため、Cluster Autoscaler はスケールダウンできませんでした。今回は、デバッグ目的で明示的に保存されていない限り、Pod はデフォルトで各ノードから削除されるようになりました。(BZ#2075029)
  • 以前は、Compliance Operator を KubeletConfig に適用すると、マシン設定プールの一時停止が早すぎてノードが NotReady 状態になることがありました。今回は、マシン設定プールは停止されず、ノードが正常に機能するようになりました。(BZ#2071854)
  • 以前のバージョンでは、Machine Config Operator は最新のリリースで url-encoded コードではなく base64 を使用していたため、Compliance Operator の修復が失敗していました。Compliance Operator は、base64 および url-encoded マシン設定コードの両方を処理するようにエンコーディングをチェックし、修復が適切に実行されるようになりました。(BZ#2082431)
5.2.15.3. 既知の問題
  • ScanSettingBinding オブジェクト内で "debug":true が設定されている場合に、そのバインディングが削除されても、ScanSettingBinding オブジェクトによって生成された Pod は削除されません。回避策として、次のコマンドを実行して残りの Pod を削除します。

    $ oc delete pods -l compliance.openshift.io/scan-name=ocp4-cis

    (BZ#2092913)

5.2.16. OpenShift Compliance Operator 0.1.49

OpenShift Compliance Operator 0.1.49 については、以下のアドバイザリーが利用できます。

5.2.16.1. 新機能および機能拡張
  • Compliance Operator は、次のアーキテクチャーでサポートされるようになりました。

    • IBM Power
    • IBM Z
    • IBM LinuxONE
5.2.16.2. バグ修正
  • 以前は、openshift-compliance コンテンツには、ネットワークタイプのプラットフォーム固有のチェックが含まれていませんでした。その結果、OVN および SDN 固有のチェックは、ネットワーク設定に基づいて not-applicable ではなく、failed したものとして表示されます。現在、新しいルールにはネットワークルールのプラットフォームチェックが含まれているため、ネットワーク固有のチェックをより正確に評価できます。(BZ#1994609)
  • 以前は、ocp4-moderate-routes-protected-by-tls ルールは TLS 設定を誤ってチェックしていたため、接続がセキュアな SSL/TLS プロトコルであっても、ルールがチェックに失敗していました。現在、このチェックでは、ネットワークガイダンスおよびプロファイルの推奨事項と一致する TLS 設定が適切に評価されます。(BZ#2002695)
  • 以前は、ocp-cis-configure-network-policies-namespace は、namespaces を要求するときにページネーションを使用していました。これにより、デプロイメントで 500 を超える namespaces のリストが切り捨てられたため、ルールが失敗しました。今回のバージョンでは、namespace の全リストが必要になり、namespace が 500 以上ある場合でも、設定済みのネットワークポリシーをチェックするルールが機能するようになりました。(BZ#2038909)
  • 以前は、sshd jinja マクロを使用した修復は、特定の sshd 設定にハードコーディングされていました。その結果、設定がルールがチェックしているコンテンツと一致せず、チェックが失敗していました。これで、sshd 設定がパラメーター化され、ルールが正常に適用されます。(BZ#2049141)
  • 以前は、ocp4-cluster-version-operator-verify-integrity は、常に Cluter バージョンオペレーター (CVO) 履歴の最初のエントリーをチェックしていました。その結果、{product-name} の後続のバージョンが検証される状況では、アップグレードは失敗します。これで、ocp4-cluster-version-operator-verify-integrity のコンプライアンスチェック結果は、検証済みバージョンを検出でき、CVO 履歴で正確になります。(BZ#2053602)
  • 以前は、ocp4-api-server-no-adm-ctrl-plugins-disabled ルールは、空のアドミッションコントローラープラグインのリストをチェックしませんでした。その結果、すべてのアドミッションプラグインが有効になっている場合でも、ルールは常に失敗します。今回のリリースでは、ocp4-api-server-no-adm-ctrl-plugins-disabled ルールのチェックが強力になり、すべての受付コントローラープラグインを有効にすると、問題なく成功するようになりました。(BZ#2058631)
  • 以前は、スキャンには Linux ワーカーノードに対して実行するためのプラットフォームチェックが含まれていませんでした。その結果、Linux ベースではないワーカーノードに対してスキャンを実行すると、スキャンループが終了することはありませんでした。今回のリリースでは、スキャンは、プラットフォームのタイプとラベルに基づいて適切にスケジュールされ、正確に実行されます。(BZ#2056911)

5.2.17. OpenShift Compliance Operator 0.1.48

OpenShift Compliance Operator 0.1.48 については、以下のアドバイザリーを利用できます。

5.2.17.1. バグ修正
  • 以前は、拡張された Open Vulnerability and Assessment Language (OVAL) 定義に関連する一部のルールの checkTypeNone でした。これは、Compliance Operator が、ルールを解析するときに拡張 OVAL 定義を処理していなかったためです。この更新により、拡張 OVAL 定義のコンテンツが解析され、これらのルールの checkTypeNode または Platform になります。(BZ#2040282)
  • 以前は、KubeletConfig 用に手動で作成された MachineConfig オブジェクトにより、KubeletConfig オブジェクトが修復用に生成されなくなり、修復が Pending 状態のままになりました。このリリースでは、KubeletConfig 用に手動で作成された MachineConfig オブジェクトがあるかどうかに関係なく、修復によって KubeletConfig オブジェクトが作成されます。その結果、KubeletConfig の修正が期待どおりに機能するようになりました。(BZ#2040401)

5.2.18. OpenShift Compliance Operator 0.1.47

OpenShift Compliance Operator 0.1.47 については、以下のアドバイザリーを利用できます。

5.2.18.1. 新機能および機能拡張
  • Compliance Operator は、Payment Card Industry Data Security Standard (PCI DSS) の次のコンプライアンスベンチマークをサポートするようになりました。

    • ocp4-pci-dss
    • ocp4-pci-dss-node
  • FedRAMP の中程度の影響レベルの追加のルールと修正が、OCP4-moderate、OCP4-moderate-node、および rhcos4-moderate プロファイルに追加されます。
  • KubeletConfig の修正がノードレベルのプロファイルで利用できるようになりました。
5.2.18.2. バグ修正
  • 以前は、クラスターが OpenShift Container Platform 4.6 以前を実行していた場合、中程度のプロファイルでは USBGuard 関連のルールの修正が失敗していました。これは、Compliance Operator によって作成された修正が、ドロップインディレクトリーをサポートしていない古いバージョンの USBGuard に基づいていたためです。現在、OpenShift Container Platform 4.6 を実行しているクラスターでは、USBGuard 関連のルールの無効な修復は作成されません。クラスターが OpenShift Container Platform 4.6 を使用している場合は、USBGuard 関連のルールの修正を手動で作成する必要があります。

    さらに、修正は、最小バージョン要件を満たすルールに対してのみ作成されます。(BZ#1965511)

  • 以前のリリースでは、修正をレンダリングする場合には、Compliance Operator は、その修正が適切に設定されているかを、厳密すぎる正規表現を使用して確認していました。その結果、sshd_config をレンダリングするような一部の修正は、正規表現チェックに合格しないため、作成されませんでした。正規表現は不要であることが判明し、削除されました。修復が正しくレンダリングされるようになりました。(BZ#2033009)

5.2.19. OpenShift Compliance Operator 0.1.44

OpenShift Compliance Operator 0.1.44 については、以下のアドバイザリーを利用できます。

5.2.19.1. 新機能および機能拡張
  • このリリースでは、strictNodeScan オプションが ComplianceScanComplianceSuite、および ScanSetting CR に追加されました。このオプションのデフォルトは true で、これは以前の動作と一致します。ノードでスキャンをスケジュールできなかった場合にエラーが発生しました。このオプションを false に設定すると、Compliance Operator は、スキャンのスケジュールについてより寛容になります。エフェメラルノードのある環境では、strictNodeScan 値を false に設定できます。これにより、クラスター内の一部のノードがスケジューリングに使用できない場合でも、コンプライアンススキャンを続行できます。
  • ScanSetting オブジェクトの nodeSelector 属性と tolerations 属性を設定することにより、結果サーバーのワークロードをスケジュールするために使用されるノードをカスタマイズできるようになりました。これらの属性は、PV ストレージボリュームをマウントし、生の Asset Reporting Format (ARF) 結果を格納するために使用される Pod である ResultServer Pod を配置するために使用されます。以前は、nodeSelector パラメーターおよび tolerations パラメーターは、デフォルトでコントロールプレーンノードの 1 つを選択し、node-role.kubernetes.io/master taint を許容していました。これは、コントロールプレーンノードが PV をマウントすることを許可されていない環境では機能しませんでした。この機能は、ノードを選択し、それらの環境で異なるテイントを許容する方法を提供します。
  • Compliance Operator は、KubeletConfig オブジェクトを修正できるようになりました。
  • エラーメッセージを含むコメントが追加され、コンテンツ開発者がクラスター内に存在しないオブジェクトとフェッチできないオブジェクトを区別できるようになりました。
  • ルールオブジェクトには、checkType および description の 2 つの新しい属性が含まれるようになりました。これらの属性を使用すると、ルールがノードチェックとプラットフォームチェックのどちらに関連しているかを判断したり、ルールの機能を確認したりできます。
  • 今回の機能拡張により、既存のプロファイルを拡張して調整されたプロファイルを作成する必要があるという要件がなくなります。これは、TailoredProfile CRD の extends フィールドが必須ではなくなったことを意味します。これで、ルールオブジェクトのリストを選択して、調整されたプロファイルを作成できます。compliance.openshift.io/product-type: アノテーションを設定するか、TailoredProfile CR の -node 接尾辞を設定して、プロファイルをノードに適用するかプラットフォームに適用するかを選択する必要があることに注意してください。
  • このリリースでは、Compliance Operator は、テイントに関係なく、すべてのノードでスキャンをスケジュールできるようになりました。以前は、スキャン Pod は node-role.kubernetes.io/master taint のみを許容していました。つまり、テイントのないノードで実行するか、node-role.kubernetes.io/master テイントのあるノードでのみ実行していました。ノードにカスタムテイントを使用するデプロイメントでは、これにより、それらのノードでスキャンがスケジュールされませんでした。現在、スキャン Pod はすべてのノードのテイントを許容します。
  • このリリースでは、Compliance Operator は、次の North American Electric Reliability Corporation (NERC) のセキュリティープロファイルをサポートしています。

    • ocp4-nerc-cip
    • ocp4-nerc-cip-node
    • rhcos4-nerc-cip
  • このリリースでは、Compliance Operator は、NIST 800-53 Moderate-Impact Baseline for the Red Hat OpenShift - Node level, ocp4-moderate-node セキュリティープロファイルをサポートします。
5.2.19.2. テンプレートと変数の使用
  • このリリースでは、修復テンプレートで複数値の変数を使用できるようになりました。
  • この更新により、Compliance Operator は、コンプライアンスプロファイルで設定された変数に基づいて修正を変更できます。これは、タイムアウト、NTP サーバーのホスト名などのデプロイメント固有の値を含む修復に役立ちます。さらに、ComplianceCheckResult オブジェクトは、チェックが使用した変数をリストするラベル compliance.openshift.io/check-has-value を使用するようになりました。
5.2.19.3. バグ修正
  • 以前は、スキャンの実行中に、Pod のスキャナーコンテナーの 1 つで予期しない終了が発生しました。このリリースでは、Compliance Operator は、クラッシュを回避するために最新の OpenSCAP バージョン 1.3.5 を使用します。
  • 以前は、autoReplyRemediations を使用して修復を適用すると、クラスターノードの更新がトリガーされていました。一部の修復に必要な入力変数がすべて含まれていない場合、これは中断されました。これで、修復に 1 つ以上の必要な入力変数が欠落している場合、NeedsReview の状態が割り当てられます。1 つ以上の修復が NeedsReview 状態にある場合、マシン設定プールは一時停止されたままになり、必要なすべての変数が設定されるまで修復は適用されません。これにより、ノードの中断を最小限に抑えることができます。
  • Prometheus メトリックに使用される RBAC Role と Role Binding が 'ClusterRole' と 'ClusterRoleBinding' に変更なり、カスタマイズなしで監視が機能するようになりました。
  • 以前は、プロファイルの解析中にエラーが発生した場合、ルールまたは変数オブジェクトが削除され、プロファイルから削除されていました。これで、解析中にエラーが発生した場合、profileparser はオブジェクトに一時的なアノテーションを付けて、解析が完了するまでオブジェクトが削除されないようにします。(BZ#1988259)
  • 以前のバージョンでは、調整されたプロファイルにタイトルまたは説明がない場合、エラーが発生しました。XCCDF 標準では、調整されたプロファイルのタイトルと説明が必要なため、タイトルと説明を TailoredProfile CR で設定する必要があります。
  • 以前は、調整されたプロファイルを使用する場合、特定の選択セットのみを使用して TailoredProfile 変数値を設定できました。この制限がなくなり、TailoredProfile 変数を任意の値に設定できるようになりました。

5.2.20. Compliance Operator 0.1.39 リリースノート

OpenShift Compliance Operator 0.1.39 については、以下のアドバイザリーが利用できます。

5.2.20.1. 新機能および機能拡張
  • 以前は、Compliance Operator は、Payment Card Industry Data Security Standard (PCI DSS) 参照を解析できませんでした。現在、Operator は、PCI DSS プロファイルで提供されるコンプライアンスコンテンツを解析できるようになりました。
  • 以前は、Compliance Operator は、中程度のプロファイルで AU-5 制御のルールを実行できませんでした。これで、Prometheusrules.monitoring.coreos.com オブジェクトを読み取り、中程度のプロファイルで AU-5 コントロールを扱うルールを実行できるように、Operator にアクセス許可が追加されました。

5.2.21. 関連情報

5.3. Compliance Operator のサポート

5.3.1. Compliance Operator のライフサイクル

Compliance Operator は "Rolling Stream" Operator で、OpenShift Container Platform リリースの更新が非同期で利用可能であることを意味します。詳細は、Red Hat カスタマーポータルの OpenShift Operator ライフサイクル を参照してください。

5.3.2. サポート

このドキュメントで説明されている手順、または OpenShift Container Platform で問題が発生した場合は、Red Hat カスタマーポータル にアクセスしてください。カスタマーポータルでは、次のことができます。

  • Red Hat 製品に関するアーティクルおよびソリューションを対象とした Red Hat ナレッジベースの検索またはブラウズ。
  • Red Hat サポートに対するサポートケースの送信。
  • その他の製品ドキュメントへのアクセス。

クラスターの問題を特定するには、OpenShift Cluster Manager Hybrid Cloud Console で Insights を使用できます。Insights により、問題の詳細と、利用可能な場合は問題の解決方法に関する情報が提供されます。

本書の改善への提案がある場合、またはエラーを見つけた場合は、最も関連性の高いドキュメントコンポーネントの Jira Issue を送信してください。セクション名や OpenShift Container Platform バージョンなどの具体的な情報を提供してください。

5.3.3. Compliance Operator の must-gather ツールの使用

Compliance Operator v1.6.0 以降では、Compliance Operator イメージで must-gather コマンドを実行することで、Compliance Operator リソースに関するデータを収集できます。

注記

サポートケースの作成時またはバグレポートの提出時は、Operator の設定とログに関する追加の詳細が提供される must-gather ツールの使用を検討してください。

手順

  • Compliance Operator に関するデータを収集するには、次のコマンドを実行します。

    $ oc adm must-gather --image=$(oc get csv compliance-operator.v1.6.0 -o=jsonpath='{.spec.relatedImages[?(@.name=="must-gather")].image}')

5.3.4. 関連情報

5.4. Compliance Operator の概念

5.4.1. Compliance Operator について

Compliance Operator を使用すると、OpenShift Container Platform 管理者はクラスターの必要なコンプライアンス状態を記述し、存在するギャップやそれらを修復する方法に関する概要を提供します。Compliance Operator は、OpenShift Container Platform の Kubernetes API リソースと、クラスターを実行するノードの両方のコンプライアンスを評価します。Compliance Operator は、NIST 認定ツールである OpenSCAP を使用して、コンテンツが提供するセキュリティーポリシーをスキャンし、これを適用します。

重要

Compliance Operator は Red Hat Enterprise Linux CoreOS (RHCOS) デプロイメントでのみ利用できます。

5.4.1.1. Compliance Operator のプロファイル

Compliance Operator のインストールの一部として利用可能なプロファイルは複数あります。oc get コマンドを使用して、使用可能なプロファイル、プロファイルの詳細、および特定のルールを表示できます。

  • 利用可能なプロファイルを表示します。

    $ oc get profile.compliance -n openshift-compliance

    出力例

    NAME                       AGE     VERSION
    ocp4-cis                   3h49m   1.5.0
    ocp4-cis-1-4               3h49m   1.4.0
    ocp4-cis-1-5               3h49m   1.5.0
    ocp4-cis-node              3h49m   1.5.0
    ocp4-cis-node-1-4          3h49m   1.4.0
    ocp4-cis-node-1-5          3h49m   1.5.0
    ocp4-e8                    3h49m
    ocp4-high                  3h49m   Revision 4
    ocp4-high-node             3h49m   Revision 4
    ocp4-high-node-rev-4       3h49m   Revision 4
    ocp4-high-rev-4            3h49m   Revision 4
    ocp4-moderate              3h49m   Revision 4
    ocp4-moderate-node         3h49m   Revision 4
    ocp4-moderate-node-rev-4   3h49m   Revision 4
    ocp4-moderate-rev-4        3h49m   Revision 4
    ocp4-nerc-cip              3h49m
    ocp4-nerc-cip-node         3h49m
    ocp4-pci-dss               3h49m   3.2.1
    ocp4-pci-dss-3-2           3h49m   3.2.1
    ocp4-pci-dss-4-0           3h49m   4.0.0
    ocp4-pci-dss-node          3h49m   3.2.1
    ocp4-pci-dss-node-3-2      3h49m   3.2.1
    ocp4-pci-dss-node-4-0      3h49m   4.0.0
    ocp4-stig                  3h49m   V2R1
    ocp4-stig-node             3h49m   V2R1
    ocp4-stig-node-v1r1        3h49m   V1R1
    ocp4-stig-node-v2r1        3h49m   V2R1
    ocp4-stig-v1r1             3h49m   V1R1
    ocp4-stig-v2r1             3h49m   V2R1
    rhcos4-e8                  3h49m
    rhcos4-high                3h49m   Revision 4
    rhcos4-high-rev-4          3h49m   Revision 4
    rhcos4-moderate            3h49m   Revision 4
    rhcos4-moderate-rev-4      3h49m   Revision 4
    rhcos4-nerc-cip            3h49m
    rhcos4-stig                3h49m   V2R1
    rhcos4-stig-v1r1           3h49m   V1R1
    rhcos4-stig-v2r1           3h49m   V2R1

    これらのプロファイルは、複数の異なるコンプライアンスベンチマークを表します。各プロファイルには、適用先の製品名がプロファイル名の接頭辞として追加されます。ocp4-e8 は Essential 8 ベンチマークを OpenShift Container Platform 製品に適用し、rhcos4-e8 は Essential 8 ベンチマークを Red Hat Enterprise Linux CoreOS (RHCOS) 製品に適用します。

  • 以下のコマンドを実行して、rhcos4-e8 プロファイルの詳細を表示します。

    $ oc get -n openshift-compliance -oyaml profiles.compliance rhcos4-e8

    例5.1 出力例

    apiVersion: compliance.openshift.io/v1alpha1
    description: 'This profile contains configuration checks for Red Hat Enterprise Linux
      CoreOS that align to the Australian Cyber Security Centre (ACSC) Essential Eight.
      A copy of the Essential Eight in Linux Environments guide can be found at the ACSC
      website: https://www.cyber.gov.au/acsc/view-all-content/publications/hardening-linux-workstations-and-servers'
    id: xccdf_org.ssgproject.content_profile_e8
    kind: Profile
    metadata:
      annotations:
        compliance.openshift.io/image-digest: pb-rhcos4hrdkm
        compliance.openshift.io/product: redhat_enterprise_linux_coreos_4
        compliance.openshift.io/product-type: Node
      creationTimestamp: "2022-10-19T12:06:49Z"
      generation: 1
      labels:
        compliance.openshift.io/profile-bundle: rhcos4
      name: rhcos4-e8
      namespace: openshift-compliance
      ownerReferences:
      - apiVersion: compliance.openshift.io/v1alpha1
        blockOwnerDeletion: true
        controller: true
        kind: ProfileBundle
        name: rhcos4
        uid: 22350850-af4a-4f5c-9a42-5e7b68b82d7d
      resourceVersion: "43699"
      uid: 86353f70-28f7-40b4-bf0e-6289ec33675b
    rules:
    - rhcos4-accounts-no-uid-except-zero
    - rhcos4-audit-rules-dac-modification-chmod
    - rhcos4-audit-rules-dac-modification-chown
    - rhcos4-audit-rules-execution-chcon
    - rhcos4-audit-rules-execution-restorecon
    - rhcos4-audit-rules-execution-semanage
    - rhcos4-audit-rules-execution-setfiles
    - rhcos4-audit-rules-execution-setsebool
    - rhcos4-audit-rules-execution-seunshare
    - rhcos4-audit-rules-kernel-module-loading-delete
    - rhcos4-audit-rules-kernel-module-loading-finit
    - rhcos4-audit-rules-kernel-module-loading-init
    - rhcos4-audit-rules-login-events
    - rhcos4-audit-rules-login-events-faillock
    - rhcos4-audit-rules-login-events-lastlog
    - rhcos4-audit-rules-login-events-tallylog
    - rhcos4-audit-rules-networkconfig-modification
    - rhcos4-audit-rules-sysadmin-actions
    - rhcos4-audit-rules-time-adjtimex
    - rhcos4-audit-rules-time-clock-settime
    - rhcos4-audit-rules-time-settimeofday
    - rhcos4-audit-rules-time-stime
    - rhcos4-audit-rules-time-watch-localtime
    - rhcos4-audit-rules-usergroup-modification
    - rhcos4-auditd-data-retention-flush
    - rhcos4-auditd-freq
    - rhcos4-auditd-local-events
    - rhcos4-auditd-log-format
    - rhcos4-auditd-name-format
    - rhcos4-auditd-write-logs
    - rhcos4-configure-crypto-policy
    - rhcos4-configure-ssh-crypto-policy
    - rhcos4-no-empty-passwords
    - rhcos4-selinux-policytype
    - rhcos4-selinux-state
    - rhcos4-service-auditd-enabled
    - rhcos4-sshd-disable-empty-passwords
    - rhcos4-sshd-disable-gssapi-auth
    - rhcos4-sshd-disable-rhosts
    - rhcos4-sshd-disable-root-login
    - rhcos4-sshd-disable-user-known-hosts
    - rhcos4-sshd-do-not-permit-user-env
    - rhcos4-sshd-enable-strictmodes
    - rhcos4-sshd-print-last-log
    - rhcos4-sshd-set-loglevel-info
    - rhcos4-sysctl-kernel-dmesg-restrict
    - rhcos4-sysctl-kernel-kptr-restrict
    - rhcos4-sysctl-kernel-randomize-va-space
    - rhcos4-sysctl-kernel-unprivileged-bpf-disabled
    - rhcos4-sysctl-kernel-yama-ptrace-scope
    - rhcos4-sysctl-net-core-bpf-jit-harden
    title: Australian Cyber Security Centre (ACSC) Essential Eight
  • 以下のコマンドを実行して、rhcos4-audit-rules-login-events ルール の詳細を表示します。

    $ oc get -n openshift-compliance -oyaml rules rhcos4-audit-rules-login-events

    例5.2 出力例

    apiVersion: compliance.openshift.io/v1alpha1
    checkType: Node
    description: |-
      The audit system already collects login information for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following lines to a file with suffix.rules in the directory /etc/audit/rules.d in order to watch for attempted manual edits of files involved in storing logon events:
    
      -w /var/log/tallylog -p wa -k logins
      -w /var/run/faillock -p wa -k logins
      -w /var/log/lastlog -p wa -k logins
    
      If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file in order to watch for unattempted manual edits of files involved in storing logon events:
    
      -w /var/log/tallylog -p wa -k logins
      -w /var/run/faillock -p wa -k logins
      -w /var/log/lastlog -p wa -k logins
    id: xccdf_org.ssgproject.content_rule_audit_rules_login_events
    kind: Rule
    metadata:
      annotations:
        compliance.openshift.io/image-digest: pb-rhcos4hrdkm
        compliance.openshift.io/rule: audit-rules-login-events
        control.compliance.openshift.io/NIST-800-53: AU-2(d);AU-12(c);AC-6(9);CM-6(a)
        control.compliance.openshift.io/PCI-DSS: Req-10.2.3
        policies.open-cluster-management.io/controls: AU-2(d),AU-12(c),AC-6(9),CM-6(a),Req-10.2.3
        policies.open-cluster-management.io/standards: NIST-800-53,PCI-DSS
      creationTimestamp: "2022-10-19T12:07:08Z"
      generation: 1
      labels:
        compliance.openshift.io/profile-bundle: rhcos4
      name: rhcos4-audit-rules-login-events
      namespace: openshift-compliance
      ownerReferences:
      - apiVersion: compliance.openshift.io/v1alpha1
        blockOwnerDeletion: true
        controller: true
        kind: ProfileBundle
        name: rhcos4
        uid: 22350850-af4a-4f5c-9a42-5e7b68b82d7d
      resourceVersion: "44819"
      uid: 75872f1f-3c93-40ca-a69d-44e5438824a4
    rationale: Manual editing of these files may indicate nefarious activity, such as
      an attacker attempting to remove evidence of an intrusion.
    severity: medium
    title: Record Attempts to Alter Logon and Logout Events
    warning: Manual editing of these files may indicate nefarious activity, such as an
      attacker attempting to remove evidence of an intrusion.
5.4.1.1.1. Compliance Operator のプロファイルタイプ

コンプライアンスプロファイルとして、Platform と Node の 2 種類を使用できます。

プラットフォーム
Platform スキャンの対象は、OpenShift Container Platform クラスターです。
ノード
Node スキャンの対象は、クラスターのノードです。
重要

pci-dss コンプライアンスプロファイルなのような、Node アプリケーションと Platform アプリケーションを含むコンプライアンスプロファイルの場合は、OpenShift Container Platform 環境で両方を実行する必要があります。

5.4.1.2. 関連情報

5.4.2. カスタムリソース定義を理解する

OpenShift Container Platform の Compliance Operator は、コンプライアンススキャンを実行するためのいくつかのカスタムリソース定義 (CRD) を提供します。コンプライアンススキャンを実行するには、ComplianceAsCode コミュニティープロジェクトから派生した事前定義されたセキュリティーポリシーを利用します。コンプライアンスオペレーターは、これらのセキュリティーポリシーを CRD に変換します。これを使用して、コンプライアンススキャンを実行し、見つかった問題の修正を取得できます。

5.4.2.1. CRD ワークフロー

CRD は、コンプライアンススキャンを完了するための次のワークフローを提供します。

  1. コンプライアンススキャン要件を定義する
  2. コンプライアンススキャン設定を設定する
  3. コンプライアンススキャン設定を使用してコンプライアンス要件を処理する
  4. コンプライアンススキャンをモニターする
  5. コンプライアンススキャンの結果を確認する
5.4.2.2. コンプライアンススキャン要件の定義

デフォルトでは、Compliance Operator CRD には ProfileBundle オブジェクトと Profile オブジェクトが含まれており、これらのオブジェクトでコンプライアンススキャン要件のルールを定義および設定できます。TailoredProfile オブジェクトを使用して、デフォルトのプロファイルをカスタマイズすることもできます。

5.4.2.2.1. ProfileBundle オブジェクト

Compliance Operator のインストール時に、すぐに実行できる ProfileBundle オブジェクトが含まれます。コンプライアンスオペレーターは、ProfileBundle オブジェクトを解析し、バンドル内のプロファイルごとに Profile オブジェクトを作成します。また、Profile オブジェクトによって使用される Rule オブジェクトと Variable オブジェクトも解析します。

ProfileBundle オブジェクトの例

apiVersion: compliance.openshift.io/v1alpha1
kind: ProfileBundle
  name: <profile bundle name>
  namespace: openshift-compliance
status:
  dataStreamStatus: VALID 1

1
コンプライアンスオペレーターがコンテンツファイルを解析できたかどうかを示します。
注記

contentFile が失敗すると、発生したエラーの詳細を提供する errorMessage 属性が表示されます。

トラブルシューティング

無効なイメージから既知のコンテンツイメージにロールバックすると、ProfileBundle オブジェクトは応答を停止し、PENDING 状態を表示します。回避策として、前のイメージとは異なるイメージに移動できます。または、ProfileBundle オブジェクトを削除して再作成し、作業状態に戻すこともできます。

5.4.2.2.2. プロファイルオブジェクト

Profile オブジェクトは、特定のコンプライアンス標準を評価できるルールと変数を定義します。XCCDF 識別子や Node または Platform タイプのプロファイルチェックなど、OpenSCAP プロファイルに関する解析済みの詳細が含まれています。Profile オブジェクトを直接使用することも、TailorProfile オブジェクトを使用してさらにカスタマイズすることもできます。

注記

Profile オブジェクトは単一の ProfileBundle オブジェクトから派生しているため、手動で作成または変更することはできません。通常、1 つの ProfileBundle オブジェクトに複数の Profile オブジェクトを含めることができます。

Profile オブジェクトの例

apiVersion: compliance.openshift.io/v1alpha1
description: <description of the profile>
id: xccdf_org.ssgproject.content_profile_moderate 1
kind: Profile
metadata:
  annotations:
    compliance.openshift.io/product: <product name>
    compliance.openshift.io/product-type: Node 2
  creationTimestamp: "YYYY-MM-DDTMM:HH:SSZ"
  generation: 1
  labels:
    compliance.openshift.io/profile-bundle: <profile bundle name>
  name: rhcos4-moderate
  namespace: openshift-compliance
  ownerReferences:
  - apiVersion: compliance.openshift.io/v1alpha1
    blockOwnerDeletion: true
    controller: true
    kind: ProfileBundle
    name: <profile bundle name>
    uid: <uid string>
  resourceVersion: "<version number>"
  selfLink: /apis/compliance.openshift.io/v1alpha1/namespaces/openshift-compliance/profiles/rhcos4-moderate
  uid: <uid string>
rules: 3
- rhcos4-account-disable-post-pw-expiration
- rhcos4-accounts-no-uid-except-zero
- rhcos4-audit-rules-dac-modification-chmod
- rhcos4-audit-rules-dac-modification-chown
title: <title of the profile>

1
プロファイルの XCCDF 名を指定します。スキャンのプロファイル属性の値として ComplianceScan オブジェクトを定義する場合は、この識別子を使用します。
2
Node または Platform のいずれかを指定します。ノードプロファイルはクラスターノードをスキャンし、プラットフォームプロファイルは Kubernetes プラットフォームをスキャンします。
3
プロファイルのルールのリストを指定します。各ルールは 1 つのチェックに対応します。
5.4.2.2.3. ルールオブジェクト

プロファイルを形成する Rule オブジェクトも、オブジェクトとして公開されます。Rule オブジェクトを使用して、コンプライアンスチェック要件を定義し、それを修正する方法を指定します。

Rule オブジェクトの例

    apiVersion: compliance.openshift.io/v1alpha1
    checkType: Platform 1
    description: <description of the rule>
    id: xccdf_org.ssgproject.content_rule_configure_network_policies_namespaces 2
    instructions: <manual instructions for the scan>
    kind: Rule
    metadata:
      annotations:
        compliance.openshift.io/rule: configure-network-policies-namespaces
        control.compliance.openshift.io/CIS-OCP: 5.3.2
        control.compliance.openshift.io/NERC-CIP: CIP-003-3 R4;CIP-003-3 R4.2;CIP-003-3
          R5;CIP-003-3 R6;CIP-004-3 R2.2.4;CIP-004-3 R3;CIP-007-3 R2;CIP-007-3 R2.1;CIP-007-3
          R2.2;CIP-007-3 R2.3;CIP-007-3 R5.1;CIP-007-3 R6.1
        control.compliance.openshift.io/NIST-800-53: AC-4;AC-4(21);CA-3(5);CM-6;CM-6(1);CM-7;CM-7(1);SC-7;SC-7(3);SC-7(5);SC-7(8);SC-7(12);SC-7(13);SC-7(18)
      labels:
        compliance.openshift.io/profile-bundle: ocp4
      name: ocp4-configure-network-policies-namespaces
      namespace: openshift-compliance
    rationale: <description of why this rule is checked>
    severity: high 3
    title: <summary of the rule>

1
このルールが実行するチェックのタイプを指定します。Node プロファイルはクラスターノードをスキャンし、Platform プロファイルは Kubernetes プラットフォームをスキャンします。空の値は、自動チェックがないことを示します。
2
データストリームから直接解析されるルールの XCCDF 名を指定します。
3
失敗したときのルールの重大度を指定します。
注記

Rule オブジェクトは、関連付けられた ProfileBundle オブジェクトを簡単に識別できるように適切なラベルを取得します。ProfileBundle は、このオブジェクトの OwnerReferences でも指定されます。

5.4.2.2.4. TailoredProfile オブジェクト

TailoredProfile オブジェクトを使用して、組織の要件に基づいてデフォルトの Profile オブジェクトを変更します。ルールを有効または無効にしたり、変数値を設定したり、カスタマイズの正当性を示したりすることができます。検証後、TailoredProfile オブジェクトは ConfigMap を作成します。これは、ComplianceScan オブジェクトから参照できます。

ヒント

ScanSettingBinding オブジェクトで参照することにより、TailoredProfile オブジェクトを使用できます。ScanSettingBinding の詳細は、ScanSettingBinding オブジェクトを参照してください。

TailoredProfile オブジェクトの例

apiVersion: compliance.openshift.io/v1alpha1
kind: TailoredProfile
metadata:
  name: rhcos4-with-usb
spec:
  extends: rhcos4-moderate 1
  title: <title of the tailored profile>
  disableRules:
    - name: <name of a rule object to be disabled>
      rationale: <description of why this rule is checked>
status:
  id: xccdf_compliance.openshift.io_profile_rhcos4-with-usb 2
  outputRef:
    name: rhcos4-with-usb-tp 3
    namespace: openshift-compliance
  state: READY 4

1
これは任意です。TailoredProfile がビルドされる Profile オブジェクトの名前。値が設定されていない場合は、enableRules リストから新しいプロファイルが作成されます。
2
調整されたプロファイルの XCCDF 名を指定します。
3
ConfigMap 名を指定します。これは、ComplianceScantailoringConfigMap.name 属性の値として使用できます。
4
READYPENDINGFAILURE などのオブジェクトの状態を表示します。オブジェクトの状態が ERROR の場合、属性 status.errorMessage が失敗の理由を提供します。

TailoredProfile オブジェクトを使用すると、TailoredProfile コンストラクトを使用して新しい Profile オブジェクトを作成できます。新しい Profile を作成するには、次の設定パラメーターを設定します。

  • 適切なタイトル
  • extends は空でなければなりません
  • TailoredProfile オブジェクトのスキャンタイプアノテーション:

    compliance.openshift.io/product-type: Platform/Node
    注記

    product-type のアノテーションを設定していない場合、コンプライアンスオペレーターはデフォルトで Platform スキャンタイプになります。TailoredProfile オブジェクトの名前に -node 接尾辞を追加すると、node スキャンタイプになります。

5.4.2.3. コンプライアンススキャン設定の設定

コンプライアンススキャンの要件を定義した後、スキャンのタイプ、スキャンの発生、およびスキャンの場所を指定することにより、コンプライアンススキャンを設定できます。そのために、Compliance Operator は ScanSetting オブジェクトを提供します。

5.4.2.3.1. ScanSetting オブジェクト

ScanSetting オブジェクトを使用して、スキャンを実行するための運用ポリシーを定義および再利用します。デフォルトでは、コンプライアンスオペレータは次の ScanSetting オブジェクトを作成します。

  • default - 1Gi Persistent Volume (PV) を使用して、マスターノードとワーカーノードの両方で毎日午前 1 時にスキャンを実行し、最後の 3 つの結果を保持します。修復は自動的に適用も更新もされません。
  • default - 1Gi Persistent Volume (PV) を使用して、コントロールプレーンとワーカーノードの両方で毎日午前 1 時にスキャンを実行し、最後の 3 つの結果を保持します。autoApplyRemediationsautoUpdateRemediations の両方が true に設定されています。

ScanSetting オブジェクトの例

apiVersion: compliance.openshift.io/v1alpha1
autoApplyRemediations: true 1
autoUpdateRemediations: true 2
kind: ScanSetting
maxRetryOnTimeout: 3
metadata:
  creationTimestamp: "2022-10-18T20:21:00Z"
  generation: 1
  name: default-auto-apply
  namespace: openshift-compliance
  resourceVersion: "38840"
  uid: 8cb0967d-05e0-4d7a-ac1c-08a7f7e89e84
rawResultStorage:
  nodeSelector:
    node-role.kubernetes.io/master: ""
  pvAccessModes:
  - ReadWriteOnce
  rotation: 3 3
  size: 1Gi 4
  tolerations:
  - effect: NoSchedule
    key: node-role.kubernetes.io/master
    operator: Exists
  - effect: NoExecute
    key: node.kubernetes.io/not-ready
    operator: Exists
    tolerationSeconds: 300
  - effect: NoExecute
    key: node.kubernetes.io/unreachable
    operator: Exists
    tolerationSeconds: 300
  - effect: NoSchedule
    key: node.kubernetes.io/memory-pressure
    operator: Exists
roles: 5
- master
- worker
scanTolerations:
- operator: Exists
schedule: 0 1 * * * 6
showNotApplicable: false
strictNodeScan: true
timeout: 30m

1
自動修復を有効にするには、true に設定します。自動修復を無効にするには、false に設定します。
2
コンテンツ更新の自動修復を有効にするには、true に設定します。コンテンツ更新の自動修復を無効にするには、false に設定します。
3
生の結果形式で保存されたスキャンの数を指定します。デフォルト値は 3 です。古い結果がローテーションされると、管理者はローテーションが発生する前に結果を別の場所に保存する必要があります。
4
生の結果を保存するためにスキャン用に作成する必要があるストレージサイズを指定します。デフォルト値は 1Gi です。
6
スキャンを実行する頻度を cron 形式で指定します。
注記

ローテーションポリシーを無効にするには、値を 0 に設定します。

5
node-role.kubernetes.io ラベル値を指定して、Node タイプのスキャンをスケジュールします。この値は、MachineConfigPool の名前と一致する必要があります。
5.4.2.4. コンプライアンススキャン設定を使用したコンプライアンススキャン要件の処理

コンプライアンススキャン要件を定義し、スキャンを実行するように設定すると、コンプライアンスオペレーターは ScanSettingBinding オブジェクトを使用してそれを処理します。

5.4.2.4.1. ScanSettingBinding オブジェクト

ScanSettingBinding オブジェクトを使用して、Profile または TailoredProfile オブジェクトを参照してコンプライアンス要件を指定します。次に、スキャンの操作上の制約を提供する ScanSetting オブジェクトにリンクされます。次に、Compliance Operator は、ScanSetting オブジェクトと ScanSettingBinding オブジェクトに基づいて ComplianceSuite オブジェクトを生成します。

ScanSettingBinding オブジェクトの例

apiVersion: compliance.openshift.io/v1alpha1
kind: ScanSettingBinding
metadata:
  name: <name of the scan>
profiles: 1
  # Node checks
  - name: rhcos4-with-usb
    kind: TailoredProfile
    apiGroup: compliance.openshift.io/v1alpha1
  # Cluster checks
  - name: ocp4-moderate
    kind: Profile
    apiGroup: compliance.openshift.io/v1alpha1
settingsRef: 2
  name: my-companys-constraints
  kind: ScanSetting
  apiGroup: compliance.openshift.io/v1alpha1

1
Profile または TailoredProfile オブジェクトの詳細を指定して、環境をスキャンします。
2
スケジュールやストレージサイズなどの運用上の制約を指定します。

ScanSetting オブジェクトと ScanSettingBinding オブジェクトを作成すると、コンプライアンススイートが作成されます。コンプライアンススイートのリストを取得するには、次のコマンドを実行します。

$ oc get compliancesuites
重要

ScanSettingBinding を削除すると、コンプライアンススイートも削除されます。

5.4.2.5. コンプライアンススキャンの追跡

コンプライアンススイートの作成後、ComplianceSuite オブジェクトを使用して、デプロイされたスキャンのステータスをモニターできます。

5.4.2.5.1. ComplianceSuite オブジェクト

ComplianceSuite オブジェクトは、スキャンの状態を追跡するのに役立ちます。スキャンと全体的な結果を作成するための生の設定が含まれています。

Node タイプのスキャンの場合、問題の修正が含まれているため、スキャンを MachineConfigPool にマップする必要があります。ラベルを指定する場合は、それがプールに直接適用されることを確認してください。

ComplianceSuite オブジェクトの例

apiVersion: compliance.openshift.io/v1alpha1
kind: ComplianceSuite
metadata:
  name: <name of the scan>
spec:
  autoApplyRemediations: false 1
  schedule: "0 1 * * *" 2
  scans: 3
    - name: workers-scan
      scanType: Node
      profile: xccdf_org.ssgproject.content_profile_moderate
      content: ssg-rhcos4-ds.xml
      contentImage: registry.redhat.io/compliance/openshift-compliance-content-rhel8@sha256:45dc...
      rule: "xccdf_org.ssgproject.content_rule_no_netrc_files"
      nodeSelector:
        node-role.kubernetes.io/worker: ""
status:
  Phase: DONE 4
  Result: NON-COMPLIANT 5
  scanStatuses:
  - name: workers-scan
    phase: DONE
    result: NON-COMPLIANT

1
自動修復を有効にするには、true に設定します。自動修復を無効にするには、false に設定します。
2
スキャンを実行する頻度を cron 形式で指定します。
3
クラスターで実行するスキャン仕様のリストを指定します。
4
スキャンの進行状況を示します。
5
スイートの全体的な判断を示します。

バックグラウンドのスイートは、scans パラメーターに基づいて ComplianceScan オブジェクトを作成します。プログラムで ComplianceSuites イベントを取得できます。スイートのイベントを取得するには、次のコマンドを実行します。

$ oc get events --field-selector involvedObject.kind=ComplianceSuite,involvedObject.name=<name of the suite>
重要

手動で ComplianceSuite を定義すると、XCCDF 属性が含まれているため、エラーが発生する可能性があります。

5.4.2.5.2. 高度な ComplianceScan オブジェクト

コンプライアンスオペレーターには、デバッグまたは既存のツールとの統合のための上級ユーザー向けのオプションが含まれています。ComplianceScan オブジェクトを直接作成しないことを推奨しますが、代わりに、ComplianceSuite オブジェクトを使用してオブジェクトを管理できます。

高度な ComplianceScan オブジェクトの例

apiVersion: compliance.openshift.io/v1alpha1
kind: ComplianceScan
metadata:
  name: <name of the scan>
spec:
  scanType: Node 1
  profile: xccdf_org.ssgproject.content_profile_moderate 2
  content: ssg-ocp4-ds.xml
  contentImage: registry.redhat.io/compliance/openshift-compliance-content-rhel8@sha256:45dc... 3
  rule: "xccdf_org.ssgproject.content_rule_no_netrc_files" 4
  nodeSelector: 5
    node-role.kubernetes.io/worker: ""
status:
  phase: DONE 6
  result: NON-COMPLIANT 7

1
Node または Platform のいずれかを指定します。ノードプロファイルはクラスターノードをスキャンし、プラットフォームプロファイルは Kubernetes プラットフォームをスキャンします。
2
実行するプロファイルの XCCDF 識別子を指定します。
3
プロファイルファイルをカプセル化するコンテナーイメージを指定します。
4
これはオプションです。単一のルールを実行するスキャンを指定します。このルールは XCCDF ID で識別され、指定されたプロファイルに属している必要があります。
注記

rule パラメーターをスキップすると、指定されたプロファイルで使用可能なすべてのルールに対してスキャンが実行されます。

5
OpenShift Container Platform を使用していて、修復を生成したい場合は、nodeSelector ラベルが MachineConfigPool ラベルと一致する必要があります。
注記

nodeSelector パラメーターを指定しないか、MachineConfig ラベルと一致しない場合でも、スキャンは実行されますが、修復は作成されません。

6
スキャンの現在のフェーズを示します。
7
スキャンの判定を示します。
重要

ComplianceSuite オブジェクトを削除すると、関連するすべてのスキャンが削除されます。

スキャンが完了すると、ComplianceCheckResult オブジェクトのカスタムリソースとして結果が生成されます。ただし、生の結果は ARF 形式で入手できます。これらの結果は、スキャンの名前に関連付けられた永続ボリュームクレーム (PVC) を持つ永続ボリューム (PV) に保存されます。プログラムで ComplianceScans イベントを取得できます。スイートのイベントを生成するには、次のコマンドを実行します。

oc get events --field-selector involvedObject.kind=ComplianceScan,involvedObject.name=<name of the suite>
5.4.2.6. コンプライアンス結果の表示

コンプライアンススイートが DONE フェーズに達すると、スキャン結果と可能な修正を表示できます。

5.4.2.6.1. ComplianceCheckResult オブジェクト

特定のプロファイルでスキャンを実行すると、プロファイル内のいくつかのルールが検証されます。これらのルールごとに、ComplianceCheckResult オブジェクトが作成され、特定のルールのクラスターの状態が提供されます。

ComplianceCheckResult オブジェクトの例

apiVersion: compliance.openshift.io/v1alpha1
kind: ComplianceCheckResult
metadata:
  labels:
    compliance.openshift.io/check-severity: medium
    compliance.openshift.io/check-status: FAIL
    compliance.openshift.io/suite: example-compliancesuite
    compliance.openshift.io/scan-name: workers-scan
  name: workers-scan-no-direct-root-logins
  namespace: openshift-compliance
  ownerReferences:
  - apiVersion: compliance.openshift.io/v1alpha1
    blockOwnerDeletion: true
    controller: true
    kind: ComplianceScan
    name: workers-scan
description: <description of scan check>
instructions: <manual instructions for the scan>
id: xccdf_org.ssgproject.content_rule_no_direct_root_logins
severity: medium 1
status: FAIL 2

1
スキャンチェックの重大度を説明します。
2
チェックの結果を説明します。以下の値を使用できます。
  • PASS: チェックは成功しました。
  • FAIL: チェックに失敗しました。
  • INFO: チェックは成功し、エラーと見なされるほど深刻ではないものが見つかりました。
  • MANUAL: チェックではステータスを自動的に評価できないため、手動チェックが必要です。
  • INCONSISTENT: ノードが異なれば、報告される結果も異なります。
  • ERROR: チェックは正常に実行されましたが、完了できませんでした。
  • NOTAPPLICABLE: 該当しないため、チェックは実行されませんでした。

スイートからすべてのチェック結果を取得するには、次のコマンドを実行します。

oc get compliancecheckresults \
-l compliance.openshift.io/suite=workers-compliancesuite
5.4.2.6.2. ComplianceRemediation オブジェクト

特定のチェックについては、データストリームで指定された修正を行うことができます。ただし、Kubernetes 修正が利用可能な場合、コンプライアンスオペレーターは ComplianceRemediation オブジェクトを作成します。

ComplianceRemediation オブジェクトの例

apiVersion: compliance.openshift.io/v1alpha1
kind: ComplianceRemediation
metadata:
  labels:
    compliance.openshift.io/suite: example-compliancesuite
    compliance.openshift.io/scan-name: workers-scan
    machineconfiguration.openshift.io/role: worker
  name: workers-scan-disable-users-coredumps
  namespace: openshift-compliance
  ownerReferences:
  - apiVersion: compliance.openshift.io/v1alpha1
    blockOwnerDeletion: true
    controller: true
    kind: ComplianceCheckResult
    name: workers-scan-disable-users-coredumps
    uid: <UID>
spec:
  apply: false 1
  object:
    current: 2
       apiVersion: machineconfiguration.openshift.io/v1
       kind: MachineConfig
       spec:
         config:
           ignition:
             version: 2.2.0
           storage:
             files:
             - contents:
                 source: data:,%2A%20%20%20%20%20hard%20%20%20core%20%20%20%200
               filesystem: root
               mode: 420
               path: /etc/security/limits.d/75-disable_users_coredumps.conf
    outdated: {} 3

1
true は、修復が適用されたことを示します。false は、修復が適用されなかったことを示します。
2
修復の定義が含まれています。
3
以前のバージョンのコンテンツから以前に解析された修復を示します。コンプライアンスオペレーターは、古いオブジェクトを引き続き保持して、管理者が新しい修復を適用する前に確認できるようにします。

スイートからすべての修復を取得するには、次のコマンドを実行します。

oc get complianceremediations \
-l compliance.openshift.io/suite=workers-compliancesuite

自動的に修正できるすべての失敗したチェックをリスト表示するには、次のコマンドを実行します。

oc get compliancecheckresults \
-l 'compliance.openshift.io/check-status in (FAIL),compliance.openshift.io/automated-remediation'

手動で修正できるすべての失敗したチェックをリスト表示するには、次のコマンドを実行します。

oc get compliancecheckresults \
-l 'compliance.openshift.io/check-status in (FAIL),!compliance.openshift.io/automated-remediation'

5.5. Compliance Operator の管理

5.5.1. Compliance Operator のインストール

Compliance Operator を使用する前に、これがクラスターにデプロイされていることを確認する必要があります。

重要

Compliance Operator は、OpenShift Dedicated、Red Hat OpenShift Service on AWS Classic、Azure Red Hat OpenShift などのマネージドプラットフォームで誤った結果を報告する場合があります。詳細は、ナレッジベースの記事 Compliance Operator reports incorrect results on Managed Services を参照してください。

重要

Compliance Operator をデプロイする前に、raw の結果出力を保存するためにクラスター内に永続ストレージを定義する必要があります。詳細は、永続ストレージの概要 および デフォルトのストレージクラスの管理 を参照してください。

5.5.1.1. Web コンソールを使用した Compliance Operator のインストール

前提条件

  • admin 権限がある。
  • StorageClass リソースが設定されている。

手順

  1. OpenShift Container Platform Web コンソールで、OperatorsOperatorHub ページに移動します。
  2. Compliance Operator を検索し、Install をクリックします。
  3. Installation mode および namespace のデフォルトの選択を維持し、Operator が openshift-compliance namespace にインストールされていることを確認します。
  4. Install をクリックします。

検証

インストールが正常に行われたことを確認するには、以下を実行します。

  1. OperatorsInstalled Operators ページに移動します。
  2. Compliance Operator が openshift-compliance namespace にインストールされ、そのステータスが Succeeded であることを確認します。

Operator が正常にインストールされていない場合、以下を実行します。

  1. OperatorsInstalled Operators ページに移動し、Status 列でエラーまたは失敗の有無を確認します。
  2. WorkloadsPods ページに移動し、openshift-compliance プロジェクトの Pod で問題を報告しているログの有無を確認します。
重要

restricted な Security Context Constraints (SCC) が system:authenticated グループを含むように変更されているか、requiredDropCapabilities を追加している場合、権限の問題により Compliance Operator が正しく機能しない可能性があります。

Compliance Operator スキャナー Pod サービスアカウント用のカスタム SCC を作成できます。詳細は Compliance Operator のカスタム SCC の作成 を参照してください。

5.5.1.2. CLI を使用した Compliance Operator のインストール

前提条件

  • admin 権限がある。
  • StorageClass リソースが設定されている。

手順

  1. Namespace オブジェクトを定義します。

    namespace-object.yaml の例

    apiVersion: v1
    kind: Namespace
    metadata:
      labels:
        openshift.io/cluster-monitoring: "true"
        pod-security.kubernetes.io/enforce: privileged 1
      name: openshift-compliance

    1
    OpenShift Container Platform 4.13 では、Pod セキュリティーラベルを namespace レベルで privileged に設定する必要があります。
  2. Namespace オブジェクトを作成します。

    $ oc create -f namespace-object.yaml
  3. OperatorGroup オブジェクトを定義します。

    operator-group-object.yaml の例

    apiVersion: operators.coreos.com/v1
    kind: OperatorGroup
    metadata:
      name: compliance-operator
      namespace: openshift-compliance
    spec:
      targetNamespaces:
      - openshift-compliance

  4. OperatorGroup オブジェクトを作成します。

    $ oc create -f operator-group-object.yaml
  5. Subscription オブジェクトを定義します。

    subscription-object.yaml の例

    apiVersion: operators.coreos.com/v1alpha1
    kind: Subscription
    metadata:
      name: compliance-operator-sub
      namespace: openshift-compliance
    spec:
      channel: "stable"
      installPlanApproval: Automatic
      name: compliance-operator
      source: redhat-operators
      sourceNamespace: openshift-marketplace

  6. Subscription オブジェクトを作成します。

    $ oc create -f subscription-object.yaml
注記

グローバルスケジューラー機能を設定する際に、defaultNodeSelector を有効にする場合、namespace を手動で作成し、openshift-compliance のアノテーションを更新するか、openshift.io/node-selector: “" を使用して Compliance Operator がインストールされている namespace のアノテーションを更新する必要があります。これにより、デフォルトのノードセレクターが削除され、デプロイメントの失敗を防ぐことができます。

検証

  1. CSV ファイルを確認して、インストールが正常に完了したことを確認します。

    $ oc get csv -n openshift-compliance
  2. Compliance Operator が稼働していることを確認します。

    $ oc get deploy -n openshift-compliance
5.5.1.3. ROSAHosted Control Plane (HCP) への Compliance Operator のインストール

Compliance Operator 1.5.0 リリース以降、Operator は Hosted Control Plane を使用して AWS 上の Red Hat OpenShift Service に対してテストされています。

Red Hat OpenShift Service on AWS Hosted Control Plane クラスターは、Red Hat によって管理されるコントロールプレーンへのアクセスが制限されています。デフォルトでは、Compliance Operator は master ノードプール内のノードにスケジュールしますが、これは Red Hat OpenShift Service on AWS では使用できません。これには、Operator が利用可能なノードプールでスケジュールできるように Subscription オブジェクトを設定する必要があります。この手順は、AWS Hosted Control Plane クラスター上の Red Hat OpenShift Service を正常にインストールするために必要です。

前提条件

  • admin 権限がある。
  • StorageClass リソースが設定されている。

手順

  1. Namespace オブジェクトを定義します。

    namespace-object.yaml ファイルの例

    apiVersion: v1
    kind: Namespace
    metadata:
      labels:
        openshift.io/cluster-monitoring: "true"
        pod-security.kubernetes.io/enforce: privileged 1
      name: openshift-compliance

    1
    OpenShift Container Platform 4.13 では、Pod セキュリティーラベルを namespace レベルで privileged に設定する必要があります。
  2. 次のコマンドを実行して、Namespace オブジェクトを作成します。

    $ oc create -f namespace-object.yaml
  3. OperatorGroup オブジェクトを定義します。

    operator-group-object.yaml ファイルの例

    apiVersion: operators.coreos.com/v1
    kind: OperatorGroup
    metadata:
      name: compliance-operator
      namespace: openshift-compliance
    spec:
      targetNamespaces:
      - openshift-compliance

  4. 以下のコマンドを実行して OperatorGroup オブジェクトを作成します。

    $ oc create -f operator-group-object.yaml
  5. Subscription オブジェクトを定義します。

    subscription-object.yaml ファイルの例

    apiVersion: operators.coreos.com/v1alpha1
    kind: Subscription
    metadata:
      name: compliance-operator-sub
      namespace: openshift-compliance
    spec:
      channel: "stable"
      installPlanApproval: Automatic
      name: compliance-operator
      source: redhat-operators
      sourceNamespace: openshift-marketplace
      config:
        nodeSelector:
          node-role.kubernetes.io/worker: "" 1

    1
    Operator デプロイメントを更新して、worker ノードにデプロイします。
  6. 以下のコマンドを実行して Subscription オブジェクトを作成します。

    $ oc create -f subscription-object.yaml

検証

  1. 次のコマンドを実行してクラスターサービスバージョン (CSV) ファイルを調べ、インストールが成功したことを確認します。

    $ oc get csv -n openshift-compliance
  2. 次のコマンドを使用して、Compliance Operator が起動して実行されていることを確認します。

    $ oc get deploy -n openshift-compliance
重要

restricted な Security Context Constraints (SCC) が system:authenticated グループを含むように変更されているか、requiredDropCapabilities を追加している場合、権限の問題により Compliance Operator が正しく機能しない可能性があります。

Compliance Operator スキャナー Pod サービスアカウント用のカスタム SCC を作成できます。詳細は Compliance Operator のカスタム SCC の作成 を参照してください。

5.5.1.4. Hypershift Hosted Control Plane への Compliance Operator のインストール

Compliance Operator は、Subscription ファイルを作成して OperatorHub を使用してホストされたコントロールプレーンにインストールできます。

重要

Hosted Control Plane は、テクノロジープレビュー機能としてのみ利用できます。テクノロジープレビュー機能は、Red Hat 製品サポートのサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではない場合があります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビューの機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。

Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。

前提条件

  • admin 権限がある。

手順

  1. 以下のような Namespace オブジェクトを定義します。

    namespace-object.yaml の例

    apiVersion: v1
    kind: Namespace
    metadata:
      labels:
        openshift.io/cluster-monitoring: "true"
        pod-security.kubernetes.io/enforce: privileged 1
      name: openshift-compliance

    1
    OpenShift Container Platform 4.13 では、Pod セキュリティーラベルを namespace レベルで privileged に設定する必要があります。
  2. 次のコマンドを実行して、Namespace オブジェクトを作成します。

    $ oc create -f namespace-object.yaml
  3. OperatorGroup オブジェクトを定義します。

    operator-group-object.yaml の例

    apiVersion: operators.coreos.com/v1
    kind: OperatorGroup
    metadata:
      name: compliance-operator
      namespace: openshift-compliance
    spec:
      targetNamespaces:
      - openshift-compliance

  4. 以下のコマンドを実行して OperatorGroup オブジェクトを作成します。

    $ oc create -f operator-group-object.yaml
  5. Subscription オブジェクトを定義します。

    subscription-object.yaml の例

    apiVersion: operators.coreos.com/v1alpha1
    kind: Subscription
    metadata:
      name: compliance-operator-sub
      namespace: openshift-compliance
    spec:
      channel: "stable"
      installPlanApproval: Automatic
      name: compliance-operator
      source: redhat-operators
      sourceNamespace: openshift-marketplace
      config:
        nodeSelector:
          node-role.kubernetes.io/worker: ""
        env:
        - name: PLATFORM
          value: "HyperShift"

  6. 以下のコマンドを実行して Subscription オブジェクトを作成します。

    $ oc create -f subscription-object.yaml

検証

  1. 以下のコマンドを実行して CSV ファイルを検査し、インストールが正常に完了したことを確認します。

    $ oc get csv -n openshift-compliance
  2. 次のコマンドを実行して、Compliance Operator が稼働していることを確認します。

    $ oc get deploy -n openshift-compliance
5.5.1.5. 関連情報

5.5.2. Compliance Operator の更新

クラスター管理者は、OpenShift Container Platform クラスターで Compliance Operator を更新できます。

重要

OpenShift Container Platform クラスターをバージョン 4.14 以降に更新する前に、Compliance Operator をバージョン 1.3.1 以降に更新することが推奨されます。

5.5.2.1. Operator 更新の準備

インストールされた Operator のサブスクリプションは、Operator の更新を追跡および受信する更新チャネルを指定します。更新チャネルを変更して、新しいチャネルからの更新の追跡と受信を開始できます。

サブスクリプションの更新チャネルの名前は Operator 間で異なる可能性がありますが、命名スキーム通常、特定の Operator 内の共通の規則に従います。たとえば、チャネル名は Operator によって提供されるアプリケーションのマイナーリリース更新ストリーム (1.21.3) またはリリース頻度 (stablefast) に基づく可能性があります。

注記

インストールされた Operator は、現在のチャネルよりも古いチャネルに切り換えることはできません。

Red Hat Customer Portal Labs には、管理者が Operator の更新を準備するのに役立つ以下のアプリケーションが含まれています。

このアプリケーションを使用して、Operator Lifecycle Manager ベースの Operator を検索し、OpenShift Container Platform の異なるバージョン間で更新チャネルごとに利用可能な Operator バージョンを確認できます。Cluster Version Operator ベースの Operator は含まれません。

5.5.2.2. Operator の更新チャネルの変更

OpenShift Container Platform Web コンソールを使用して、Operator の更新チャネルを変更できます。

ヒント

サブスクリプションの承認ストラテジーが Automatic に設定されている場合、アップグレードプロセスは、選択したチャネルで新規 Operator バージョンが利用可能になるとすぐに開始します。承認ストラテジーが Manual に設定されている場合は、保留中のアップグレードを手動で承認する必要があります。

前提条件

  • Operator Lifecycle Manager (OLM) を使用して以前にインストールされている Operator。

手順

  1. Web コンソールの Administrator パースペクティブで、Operators → Installed Operators に移動します。
  2. 更新チャネルを変更する Operator の名前をクリックします。
  3. Subscription タブをクリックします。
  4. Update channel の下にある更新チャネルの名前をクリックします。
  5. 変更する新しい更新チャネルをクリックし、Save をクリックします。
  6. Automatic 承認ストラテジーのあるサブスクリプションの場合、更新は自動的に開始します。Operators → Installed Operators ページに戻り、更新の進捗をモニターします。完了時に、ステータスは Succeeded および Up to date に変更されます。

    Manual 承認ストラテジーのあるサブスクリプションの場合、Subscription タブから更新を手動で承認できます。

5.5.2.3. 保留中の Operator 更新の手動による承認

インストールされた Operator のサブスクリプションの承認ストラテジーが Manual に設定されている場合、新規の更新が現在の更新チャネルにリリースされると、インストールを開始する前に更新を手動で承認する必要があります。

前提条件

  • Operator Lifecycle Manager (OLM) を使用して以前にインストールされている Operator。

手順

  1. OpenShift Container Platform Web コンソールの Administrator パースペクティブで、Operators → Installed Operators に移動します。
  2. 更新が保留中の Operator は Upgrade available のステータスを表示します。更新する Operator の名前をクリックします。
  3. Subscription タブをクリックします。承認が必要な更新は、Upgrade status の横に表示されます。たとえば、1 requires approval が表示される可能性があります。
  4. 1 requires approval をクリックしてから、Preview Install Plan をクリックします。
  5. 更新に利用可能なリソースとして一覧表示されているリソースを確認します。問題がなければ、Approve をクリックします。
  6. Operators → Installed Operators ページに戻り、更新の進捗をモニターします。完了時に、ステータスは Succeeded および Up to date に変更されます。

5.5.3. Compliance Operator の管理

このセクションでは、コンプライアンスコンテンツの更新されたバージョンを使用する方法や、カスタム ProfileBundle オブジェクトを作成する方法など、セキュリティーコンテンツのライフサイクルを説明します。

5.5.3.1. ProfileBundle CR の例

ProfileBundle オブジェクトには、contentImage が含まれるコンテナーイメージの URL と、コンプライアンスコンテンツが含まれるファイルの 2 つの情報が必要です。contentFile パラメーターはファイルシステムのルートに相対します。以下の例のように、ビルトインの rhcos4 ProfileBundle オブジェクトを定義できます。

apiVersion: compliance.openshift.io/v1alpha1
kind: ProfileBundle
metadata:
  creationTimestamp: "2022-10-19T12:06:30Z"
  finalizers:
  - profilebundle.finalizers.compliance.openshift.io
  generation: 1
  name: rhcos4
  namespace: openshift-compliance
  resourceVersion: "46741"
  uid: 22350850-af4a-4f5c-9a42-5e7b68b82d7d
spec:
  contentFile: ssg-rhcos4-ds.xml 1
  contentImage: registry.redhat.io/compliance/openshift-compliance-content-rhel8@sha256:900e... 2
status:
  conditions:
  - lastTransitionTime: "2022-10-19T12:07:51Z"
    message: Profile bundle successfully parsed
    reason: Valid
    status: "True"
    type: Ready
  dataStreamStatus: VALID
1
コンプライアンスコンテンツが含まれるファイルの場所。
2
コンテンツイメージの場所。
重要

コンテンツイメージに使用されるベースイメージには、coreutils が含まれる必要があります。

5.5.3.2. セキュリティーコンテンツの更新

セキュリティーコンテンツは、ProfileBundle オブジェクトが参照するコンテナーイメージとして含まれます。ProfileBundles や、ルールまたはプロファイルなどのバンドルから解析されたカスタムリソースへの更新を正確に追跡するには、タグの代わりにダイジェストを使用してコンプライアンスコンテンツを持つコンテナーイメージを識別します。

$ oc -n openshift-compliance get profilebundles rhcos4 -oyaml

出力例

apiVersion: compliance.openshift.io/v1alpha1
kind: ProfileBundle
metadata:
  creationTimestamp: "2022-10-19T12:06:30Z"
  finalizers:
  - profilebundle.finalizers.compliance.openshift.io
  generation: 1
  name: rhcos4
  namespace: openshift-compliance
  resourceVersion: "46741"
  uid: 22350850-af4a-4f5c-9a42-5e7b68b82d7d
spec:
  contentFile: ssg-rhcos4-ds.xml
  contentImage: registry.redhat.io/compliance/openshift-compliance-content-rhel8@sha256:900e... 1
status:
  conditions:
  - lastTransitionTime: "2022-10-19T12:07:51Z"
    message: Profile bundle successfully parsed
    reason: Valid
    status: "True"
    type: Ready
  dataStreamStatus: VALID

1
セキュリティーコンテナーイメージ。

それぞれの ProfileBundle はデプロイメントでサポートされます。Compliance Operator がコンテナーイメージダイジェストが変更されたことを検知すると、デプロイメントは変更を反映し、コンテンツを再び解析するように更新されます。タグの代わりにダイジェストを使用すると、安定した予測可能なプロファイルセットを使用できます。

5.5.3.3. 関連情報

5.5.4. Compliance Operator のアンインストール

OpenShift Container Platform Web コンソールまたは CLI を使用して、クラスターから OpenShift Compliance Operator を削除できます。

5.5.4.1. Web コンソールを使用した OpenShift Container Platform からの OpenShift Compliance Operator のアンインストール

Compliance Operator を削除するには、まず namespace のオブジェクトを削除する必要があります。オブジェクトが削除されたら、openshift-compliance プロジェクトを削除することで、Operator とその namespace を削除できます。

前提条件

  • cluster-admin パーミッションを持つアカウントを使用して OpenShift Container Platform クラスターにアクセスできる。
  • OpenShift Compliance Operator をインストールする必要があります。

手順

OpenShift Container Platform Web コンソールを使用して Compliance Operator を削除するには、以下を行います。

  1. OperatorsInstalled OperatorsCompliance Operator ページに移動します。

    1. All instances をクリックします。
    2. All namespaces で、 kebab オプションメニューをクリックし、すべての ScanSettingBinding、ComplainceSuite、ComplianceScan、および ProfileBundle オブジェクトを削除します。
  2. AdministrationOperatorsInstalled Operators ページに切り替えます。
  3. Compliance Operator エントリーのオプションメニュー kebab をクリックして Uninstall Operator を選択します。
  4. HomeProjects ページに切り替えます。
  5. 'compliance' を検索します。
  6. openshift-compliance プロジェクトの横にある Options メニュー kebab をクリックし、Delete Project を選択します。

    1. ダイアログボックスに openshift-compliance と入力して削除を確認し、Delete をクリックします。
5.5.4.2. CLI を使用した OpenShift Container Platform からの OpenShift Compliance Operator のアンインストール

Compliance Operator を削除するには、まず namespace のオブジェクトを削除する必要があります。オブジェクトが削除されたら、openshift-compliance プロジェクトを削除することで、Operator とその namespace を削除できます。

前提条件

  • cluster-admin パーミッションを持つアカウントを使用して OpenShift Container Platform クラスターにアクセスできる。
  • OpenShift Compliance Operator をインストールする必要があります。

手順

  1. namespace のすべてのオブジェクトを削除します。

    1. ScanSettingBinding オブジェクトを削除します。

      $ oc delete ssb --all -n openshift-compliance
    2. ScanSetting オブジェクトを削除します。

      $ oc delete ss --all -n openshift-compliance
    3. ComplianceSuite オブジェクトを削除します。

      $ oc delete suite --all -n openshift-compliance
    4. ComplianceScan オブジェクトを削除します。

      $ oc delete scan --all -n openshift-compliance
    5. ProfileBundle オブジェクトを削除します。

      $ oc delete profilebundle.compliance --all -n openshift-compliance
  2. Subscription オブジェクトを削除します。

    $ oc delete sub --all -n openshift-compliance
  3. CSV オブジェクトを削除します。

    $ oc delete csv --all -n openshift-compliance
  4. プロジェクトを削除します。

    $ oc delete project openshift-compliance

    出力例

    project.project.openshift.io "openshift-compliance" deleted

検証

  1. namespace が削除されていることを確認します。

    $ oc get project/openshift-compliance

    出力例

    Error from server (NotFound): namespaces "openshift-compliance" not found

5.6. Compliance Operator のスキャンの管理

5.6.1. サポートされているコンプライアンスプロファイル

Compliance Operator (CO) のインストールの一部として利用可能なプロファイルは複数あります。次のプロファイルを使用すると、クラスター内のギャップを評価できます。ただし、使用するだけでは特定のプロファイルへの準拠を推測または保証できません。また、プロファイルは監査人はありません。

このようなさまざまな標準に対する準拠または認定を実現するには、Qualified Security Assessor (QSA)、Joint Authorization Board (JAB)、または業界で認められたその他の規制当局など、認定監査機関に依頼して、環境の評価を受ける必要があります。標準への準拠を実現するには、認定監査人と協力する必要があります。

重要

Compliance Operator は、OpenShift Dedicated や Azure Red Hat OpenShift などの一部のマネージドプラットフォームで誤った結果を報告する可能性があります。詳細は、Red Hat ナレッジベースソリューション Red Hat Knowledgebase Solution #6983418 を参照してください。

5.6.1.1. コンプライアンスプロファイル

Compliance Operator は、業界標準のベンチマークを満たすプロファイルを提供します。

注記

次の表は、Compliance Operator で利用可能な最新のプロファイルを反映しています。

5.6.1.1.1. CIS コンプライアンスプロファイル
表5.1 サポートされている CIS コンプライアンスプロファイル
プロファイルプロファイルタイトルApplication業界コンプライアンスベンチマークサポートされているアーキテクチャーサポート対象のプラットフォーム

ocp4-cis [1]

CIS Red Hat OpenShift Container Platform Benchmark v1.5.0

プラットフォーム

CIS Benchmarks ™ [1]

x86_64 ppc64le s390x

 

ocp4-cis-1-4 [3]

CIS Red Hat OpenShift Container Platform Benchmark v1.4.0

プラットフォーム

CIS Benchmarks ™ [4]

x86_64 ppc64le s390x

 

ocp4-cis-1-5

CIS Red Hat OpenShift Container Platform Benchmark v1.5.0

プラットフォーム

CIS Benchmarks ™ [4]

x86_64 ppc64le s390x

 

ocp4-cis-node [1]

CIS Red Hat OpenShift Container Platform Benchmark v1.5.0

ノード [2]

CIS Benchmarks ™ [4]

x86_64 ppc64le s390x

Red Hat OpenShift Service on AWS with hosted control planes (ROSA with HCP)

ocp4-cis-node-1-4 [3]

CIS Red Hat OpenShift Container Platform Benchmark v1.4.0

ノード [2]

CIS Benchmarks ™ [4]

x86_64 ppc64le s390x

Red Hat OpenShift Service on AWS with hosted control planes (ROSA with HCP)

ocp4-cis-node-1-5

CIS Red Hat OpenShift Container Platform Benchmark v1.5.0

ノード [2]

CIS Benchmarks ™ [4]

x86_64 ppc64le s390x

Red Hat OpenShift Service on AWS with hosted control planes (ROSA with HCP)

  1. ocp4-cis および ocp4-cis-node プロファイルは、Compliance Operator で利用可能になると、CIS ベンチマークの最新バージョンを維持します。CIS v1.4.0 などの特定のバージョンに準拠する場合は、ocp4-cis-1-4 および ocp4-cis-node-1-4 プロファイルを使用します。
  2. ノードプロファイルは、関連するプラットフォームプロファイルとともに使用する必要があります。詳細は、Compliance Operator のプロファイルタイプ を参照してください。
  3. CIS v1.4.0 は CIS v1.5.0 に置き換えられました。最新のプロファイルを環境に適用することを推奨します。
  4. CIS OpenShift Container Platform v4 ベンチマークを見つけるには、CIS ベンチマーク に移動し、最新の CIS ベンチマークをダウンロード をクリックします。ここでベンチマークをダウンロードするために登録できます。
5.6.1.1.2. Essential Eight コンプライアンスプロファイル
表5.2 サポートされている Essential Eight コンプライアンスプロファイル
プロファイルプロファイルタイトルApplication業界コンプライアンスベンチマークサポートされているアーキテクチャーサポート対象のプラットフォーム

ocp4-e8

Australian Cyber Security Centre (ACSC) Essential Eight

プラットフォーム

ACSC Hardening Linux ワークステーションおよびサーバー

x86_64

 

rhcos4-e8

Australian Cyber Security Centre (ACSC) Essential Eight

ノード

ACSC Hardening Linux ワークステーションおよびサーバー

x86_64

Red Hat OpenShift Service on AWS with hosted control planes (ROSA with HCP)

5.6.1.1.3. FedRAMP High コンプライアンスプロファイル
表5.3 サポートされている FedRAMP High コンプライアンスプロファイル
プロファイルプロファイルタイトルApplication業界コンプライアンスベンチマークサポートされているアーキテクチャーサポート対象のプラットフォーム

ocp4-high [1]

NIST 800-53 High-Impact Baseline for Red Hat OpenShift - プラットフォームレベル

プラットフォーム

NIST SP-800-53 Release Search

x86_64

 

ocp4-high-node [1]

NIST 800-53 High-Impact Baseline for Red Hat OpenShift - ノードレベル

ノード [2]

NIST SP-800-53 Release Search

x86_64

Red Hat OpenShift Service on AWS with hosted control planes (ROSA with HCP)

ocp4-high-node-rev-4

NIST 800-53 High-Impact Baseline for Red Hat OpenShift - ノードレベル

ノード [2]

NIST SP-800-53 Release Search

x86_64

Red Hat OpenShift Service on AWS with hosted control planes (ROSA with HCP)

ocp4-high-rev-4

NIST 800-53 High-Impact Baseline for Red Hat OpenShift - プラットフォームレベル

プラットフォーム

NIST SP-800-53 Release Search

x86_64

 

rhcos4-high [1]

NIST 800-53 High-Impact Baseline for Red Hat Enterprise Linux CoreOS

ノード

NIST SP-800-53 Release Search

x86_64

Red Hat OpenShift Service on AWS with hosted control planes (ROSA with HCP)

rhcos4-high-rev-4

NIST 800-53 High-Impact Baseline for Red Hat Enterprise Linux CoreOS

ノード

NIST SP-800-53 Release Search

x86_64

Red Hat OpenShift Service on AWS with hosted control planes (ROSA with HCP)

  1. ocp4-highocp4-high-node、および rhcos4-high プロファイルは、Compliance Operator で利用可能になると、FedRAMP High 標準の最新バージョンを維持します。FedRAMP high R4 などの特定のバージョンに準拠する場合は、ocp4-high-rev-4 および ocp4-high-node-rev-4 プロファイルを使用します。
  2. ノードプロファイルは、関連するプラットフォームプロファイルとともに使用する必要があります。詳細は、Compliance Operator のプロファイルタイプ を参照してください。
5.6.1.1.4. FedRAMP Moderate コンプライアンスプロファイル
表5.4 サポートされている FedRAMP Moderate コンプライアンスプロファイル
プロファイルプロファイルタイトルApplication業界コンプライアンスベンチマークサポートされているアーキテクチャーサポート対象のプラットフォーム

ocp4-moderate [1]

NIST 800-53 Moderate-Impact Baseline for Red Hat OpenShift - プラットフォームレベル

プラットフォーム

NIST SP-800-53 Release Search

x86_64 ppc64le s390x

 

ocp4-moderate-node [1]

NIST 800-53 Moderate-Impact Baseline for Red Hat OpenShift - ノードレベル

ノード [2]

NIST SP-800-53 Release Search

x86_64 ppc64le s390x

Red Hat OpenShift Service on AWS with hosted control planes (ROSA with HCP)

ocp4-moderate-node-rev-4

NIST 800-53 Moderate-Impact Baseline for Red Hat OpenShift - ノードレベル

ノード [2]

NIST SP-800-53 Release Search

x86_64 ppc64le s390x

Red Hat OpenShift Service on AWS with hosted control planes (ROSA with HCP)

ocp4-moderate-rev-4

NIST 800-53 Moderate-Impact Baseline for Red Hat OpenShift - プラットフォームレベル

プラットフォーム

NIST SP-800-53 Release Search

x86_64 ppc64le s390x

 

rhcos4-moderate [1]

NIST 800-53 Moderate-Impact Baseline for Red Hat Enterprise Linux CoreOS

ノード

NIST SP-800-53 Release Search

x86_64

Red Hat OpenShift Service on AWS with hosted control planes (ROSA with HCP)

rhcos4-moderate-rev-4

NIST 800-53 Moderate-Impact Baseline for Red Hat Enterprise Linux CoreOS

ノード

NIST SP-800-53 Release Search

x86_64

Red Hat OpenShift Service on AWS with hosted control planes (ROSA with HCP)

  1. ocp4-moderateocp4-moderate-noderhcos4-moderate プロファイルは、Compliance Operator で利用可能になると、FedRAMP Moderate 標準の最新バージョンを維持します。FedRAMP Moderate R4 などの特定のバージョンに準拠する場合は、ocp4-moderate-rev-4 および ocp4-moderate-node-rev-4 プロファイルを使用します。
  2. ノードプロファイルは、関連するプラットフォームプロファイルとともに使用する必要があります。詳細は、Compliance Operator のプロファイルタイプ を参照してください。
5.6.1.1.5. NERC-CIP コンプライアンスプロファイル
表5.5 サポートされている NERC-CIP コンプライアンスプロファイル
プロファイルプロファイルタイトルApplication業界コンプライアンスベンチマークサポートされているアーキテクチャーサポート対象のプラットフォーム

ocp4-nerc-cip

North American Electric Reliability Corporation (NERC) Critical Infrastructure Protection (CIP) cybersecurity standards profile for the OpenShift Container Platform - Platform レベル

プラットフォーム

NERC CIP 標準

x86_64

 

ocp4-nerc-cip-node

North American Electric Reliability Corporation (NERC) Critical Infrastructure Protection (CIP) cybersecurity standards profile for the OpenShift Container Platform - Node レベル

ノード [1]

NERC CIP 標準

x86_64

Red Hat OpenShift Service on AWS with hosted control planes (ROSA with HCP)

rhcos4-nerc-cip

North American Electric Reliability Corporation (NERC) Critical Infrastructure Protection (CIP) cybersecurity standards profile for Red Hat Enterprise Linux CoreOS

ノード

NERC CIP 標準

x86_64

Red Hat OpenShift Service on AWS with hosted control planes (ROSA with HCP)

  1. ノードプロファイルは、関連するプラットフォームプロファイルとともに使用する必要があります。詳細は、Compliance Operator のプロファイルタイプ を参照してください。
5.6.1.1.6. PCI-DSS コンプライアンスプロファイル
表5.6 サポートされている PCI-DSS コンプライアンスプロファイル
プロファイルプロファイルタイトルApplication業界コンプライアンスベンチマークサポートされているアーキテクチャーサポート対象のプラットフォーム

ocp4-pci-dss [1]

PCI-DSS v4 Control Baseline for OpenShift Container Platform 4

プラットフォーム

PCI Security Standards ® Council Document Library

x86_64

 

ocp4-pci-dss-3-2 [3]

PCI-DSS v3.2.1 Control Baseline for OpenShift Container Platform 4

プラットフォーム

PCI Security Standards ® Council Document Library

x86_64

 

ocp4-pci-dss-4-0

PCI-DSS v4 Control Baseline for OpenShift Container Platform 4

プラットフォーム

PCI Security Standards ® Council Document Library

x86_64

 

ocp4-pci-dss-node [1]

PCI-DSS v4 Control Baseline for OpenShift Container Platform 4

ノード [2]

PCI Security Standards ® Council Document Library

x86_64

Red Hat OpenShift Service on AWS with hosted control planes (ROSA with HCP)

ocp4-pci-dss-node-3-2 [3]

PCI-DSS v3.2.1 Control Baseline for OpenShift Container Platform 4

ノード [2]

PCI Security Standards ® Council Document Library

x86_64

Red Hat OpenShift Service on AWS with hosted control planes (ROSA with HCP)

ocp4-pci-dss-node-4-0

PCI-DSS v4 Control Baseline for OpenShift Container Platform 4

ノード [2]

PCI Security Standards ® Council Document Library

x86_64

Red Hat OpenShift Service on AWS with hosted control planes (ROSA with HCP)

  1. ocp4-pci-dss および ocp4-pci-dss-node プロファイルは、Compliance Operator で利用可能になると、最新バージョンの PCI-DSS 標準を維持します。PCI-DSS v3.2.1 などの特定のバージョンに準拠する場合は、ocp4-pci-dss-3-2 および ocp4-pci-dss-node-3-2 プロファイルを使用します。
  2. ノードプロファイルは、関連するプラットフォームプロファイルとともに使用する必要があります。詳細は、Compliance Operator のプロファイルタイプ を参照してください。
  3. PCI-DSS v3.2.1 は PCI-DSS v4 に置き換えられました。最新のプロファイルを環境に適用することを推奨します。
5.6.1.1.7. STIG コンプライアンスプロファイル
表5.7 サポートされている STIG コンプライアンスプロファイル
プロファイルプロファイルタイトルApplication業界コンプライアンスベンチマークサポートされているアーキテクチャーサポート対象のプラットフォーム

ocp4-stig [1]

Defense Information Systems Agency Security Technical Implementation Guide (DISA STIG) for Red Hat Openshift

プラットフォーム

DISA-STIG

x86_64

 

ocp4-stig-node [1]

Defense Information Systems Agency Security Technical Implementation Guide (DISA STIG) for Red Hat Openshift

ノード [2]

DISA-STIG

x86_64

Red Hat OpenShift Service on AWS with hosted control planes (ROSA with HCP)

ocp4-stig-node-v1r1 [3]

Defense Information Systems Agency Security Technical Implementation Guide (DISA STIG) for Red Hat Openshift V1R1

ノード [2]

DISA-STIG

x86_64

Red Hat OpenShift Service on AWS with hosted control planes (ROSA with HCP)

ocp4-stig-node-v2r1

Defense Information Systems Agency Security Technical Implementation Guide (DISA STIG) for Red Hat Openshift V2R1

ノード [2]

DISA-STIG

x86_64

Red Hat OpenShift Service on AWS with hosted control planes (ROSA with HCP)

ocp4-stig-v1r1 [3]

Defense Information Systems Agency Security Technical Implementation Guide (DISA STIG) for Red Hat Openshift V1R1

プラットフォーム

DISA-STIG

x86_64

 

ocp4-stig-v2r1

Defense Information Systems Agency Security Technical Implementation Guide (DISA STIG) for Red Hat Openshift V2R1

プラットフォーム

DISA-STIG

x86_64

 

rhcos4-stig

Defense Information Systems Agency Security Technical Implementation Guide (DISA STIG) for Red Hat Openshift

ノード

DISA-STIG

x86_64

Red Hat OpenShift Service on AWS with hosted control planes (ROSA with HCP)

rhcos4-stig-v1r1 [3]

Defense Information Systems Agency Security Technical Implementation Guide (DISA STIG) for Red Hat Openshift V1R1

ノード

DISA-STIG [3]

x86_64

Red Hat OpenShift Service on AWS with hosted