セキュリティーおよびコンプライアンス
OpenShift Container Platform のセキュリティーについての理解および管理
概要
第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 のお客様においては、システムが実稼働環境で使用される前に、一定レベルでの規制への対応またはコンプライアンスが必要になります。この規制対応は、国家標準、業界標準または組織の企業ガバナンスフレームワークによって課せられます。
コンプライアンスの確認
管理者は コンプライアンス Operator を使用してコンプライアンススキャンを実行し、検出された問題の修復を提案できます。
ファイルの整合性チェック
管理者は 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.6 は RHCOS ホストで実行され、Red Hat Enterprise Linux (RHEL) をワーカーノードとして使用するオプションが指定されるため、デフォルトで以下の概念がデプロイされた OpenShift Container Platform クラスターに適用されます。これらの RHEL セキュリティー機能は、OpenShift で実行中のコンテナーのセキュリティーを強化するためのコアとなる機能です。
- Linux namespace は特定のグローバルシステムリソースを抽象化し、これを namespace 内の複数のプロセスに対して分離したインスタンスとして表示できます。これにより、複数のコンテナーが競合せずに同じコンピューティングリソースを同時に使用することができます。デフォルトでホストから分離されているコンテナーの namespace には、マウントテーブル、プロセステーブル、ネットワークインターフェイス、ユーザー、コントロールグループ、UTS、および IPC namespace が含まれます。ホスト namespace に直接アクセスする必要のあるコンテナーには、そのアクセスを要求するために特権昇格が必要です。namespace のタイプについての詳細は、RHEL 7 コンテナーのドキュメントの 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 が必要とする機能のみを実装してコンテナーを実行し、管理することで、その攻撃対象領域をさらに削減します。
RHCOS は、OpenShift Container Platform クラスターでコントロールプレーン (マスター) およびワーカーノードとして機能するように特別に設定された Red Hat Enterprise Linux (RHEL) のバージョンです。そのため、RHCOS は、Kubernetes および OpenShift サービスと共にコンテナーのワークロードを効率的に実行するように調整されます。
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 をデプロイする際に、インストーラーでプロビジョニングされるインフラストラクチャー (利用可能ないくつかのプラットフォーム) またはユーザーによってプロビジョニングされるインフラストラクチャーを選択できます。FIPS コンプライアンスの有効化や初回の起動時に必要なカーネルモジュールの追加など、低レベルのセキュリティー関連の設定は、ユーザーによってプロビジョニングされるインフラストラクチャーの場合に役立つ場合があります。同様に、ユーザーによってプロビジョニングされるインフラストラクチャーは、非接続の OpenShift Container Platform デプロイメントに適しています。
セキュリティーが強化され、OpenShift Container Platform に他の設定変更が行われる場合、以下を含む目標を明確にするようにしてください。
- 基礎となるノードを可能な限り汎用的な状態で維持する。同様のノードをすぐ、かつ指定した方法で破棄したり起動したりできるようにする必要があります。
- ノードに対して直接的に 1 回限りの変更を行うのではなく、OpenShift Container Platform でのノードへの変更をできる限り管理する。
上記を目標とすると、ほとんどのノードの変更はインストール時に Ignition で行うか、または Machine Config Operator によってノードのセットに適用される MachineConfig を使用して後で行う必要があります。この方法で実行できるセキュリティー関連の設定変更の例を以下に示します。
- カーネル引数の追加
- カーネルモジュールの追加
- FIPS 暗号のサポートの有効化
- ディスク暗号化の設定
- 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 のインストールの場合は難易度が上がりますが、この場合、OpenShift Container Platform インストールを開始する前にオペレーティングシステムの変更を取得することができます。これは、ディスクの暗号化や特別なネットワーク設定など、特定の機能を可能な限り早期に設定する必要がある場合に重要になります。
RHCOS ノードでの SELinux の無効化はサポートされていません。
2.3.2.2. インストール時のハードニング
OpenShift インストールプロセスを中断し、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 の署名の検証の有効化
コンテナーの署名の検証を有効にするには、レジストリー URL を sigstore にリンクし、次にイメージを検証するキーを指定するためのファイルが必要です。
手順
レジストリー URL を sigstore にリンクし、イメージの検証に使用するキーを指定するためのファイルを作成します。
policy.json
ファイルを作成します。$ cat > policy.json <<EOF { "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" } ] } } } EOF
registry.access.redhat.com.yaml
ファイルを作成します。$ cat <<EOF > registry.access.redhat.com.yaml docker: registry.access.redhat.com: sigstore: https://access.redhat.com/webassets/docker/content/sigstore EOF
registry.redhat.io.yaml
ファイルを作成します。$ cat <<EOF > registry.redhat.io.yaml docker: registry.redhat.io: sigstore: https://registry.redhat.io/containers/sigstore EOF
マシン設定テンプレートに使用される
base64
でエンコードされた形式でファイルを設定します。$ export ARC_REG=$( cat registry.access.redhat.com.yaml | base64 -w0 ) $ export RIO_REG=$( cat registry.redhat.io.yaml | base64 -w0 ) $ export POLICY_CONFIG=$( cat policy.json | base64 -w0 )
エクスポートされたファイルをワーカーノードのディスクに書き込むマシン設定を作成します。
$ cat > 51-worker-rh-registry-trust.yaml <<EOF apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfig metadata: labels: machineconfiguration.openshift.io/role: worker name: 51-worker-rh-registry-trust spec: config: ignition: config: {} security: tls: {} timeouts: {} version: 2.2.0 networkd: {} passwd: {} storage: files: - contents: source: data:text/plain;charset=utf-8;base64,${ARC_REG} verification: {} filesystem: root mode: 420 path: /etc/containers/registries.d/registry.access.redhat.com.yaml - contents: source: data:text/plain;charset=utf-8;base64,${RIO_REG} verification: {} filesystem: root mode: 420 path: /etc/containers/registries.d/registry.redhat.io.yaml - contents: source: data:text/plain;charset=utf-8;base64,${POLICY_CONFIG} verification: {} filesystem: root mode: 420 path: /etc/containers/policy.json osImageURL: "" EOF
作成されたマシン設定を適用します。
$ oc apply -f 51-worker-rh-registry-trust.yaml
エクスポートしたファイルをマスターノードのディスクに書き込むマシン設定を作成します。
$ cat > 51-master-rh-registry-trust.yaml <<EOF apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfig metadata: labels: machineconfiguration.openshift.io/role: master name: 51-master-rh-registry-trust spec: config: ignition: config: {} security: tls: {} timeouts: {} version: 2.2.0 networkd: {} passwd: {} storage: files: - contents: source: data:text/plain;charset=utf-8;base64,${ARC_REG} verification: {} filesystem: root mode: 420 path: /etc/containers/registries.d/registry.access.redhat.com.yaml - contents: source: data:text/plain;charset=utf-8;base64,${RIO_REG} verification: {} filesystem: root mode: 420 path: /etc/containers/registries.d/registry.redhat.io.yaml - contents: source: data:text/plain;charset=utf-8;base64,${POLICY_CONFIG} verification: {} filesystem: root mode: 420 path: /etc/containers/policy.json osImageURL: "" EOF
マスターマシン設定の変更をクラスターに適用します。
$ oc apply -f 51-master-rh-registry-trust.yaml
2.4.2. 署名の検証設定の確認
マシン設定をクラスターに適用すると、Machine Config Controller は新規の MachineConfig
オブジェクトを検出し、新規の rendered-worker-<hash>
バージョンを生成します。
前提条件
- マシン設定ファイルを使用して署名の検証を有効にしている。
手順
コマンドラインで以下のコマンドを実行し、必要なワーカーの情報を表示します。
$ 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>
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
設定を参照します。以下のコマンドを使用して、
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" } ] } } }
以下のコマンドを使用して、
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
以下のコマンドを使用して、
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. 関連情報
2.5. コンプライアンスについて
多くの OpenShift Container Platform のお客様においては、システムが実稼働環境で使用される前に、一定レベルでの規制への対応またはコンプライアンスが必要になります。この規制対応は、国家標準、業界標準または組織の企業ガバナンスフレームワークによって課せられます。
2.5.1. コンプライアンスおよびリスク管理について
FIPS コンプライアンスは、安全な環境で必要とされる最も重要なコンポーネントの 1 つであり、サポートされている暗号化技術のみがノード上で許可されるようにします。
FIPS 検証済み/進行中のモジュール (Modules in Process) 暗号ライブラリーの使用は、x86_64
アーキテクチャーの OpenShift Container Platform デプロイメントでのみサポートされています。
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 の標準 UBI イメージ (
ubi7/ubi
およびubi8/ubi
)、およびそれらのシステムをベースとする最小イメージ (ubi7/ubi-minimal
およびubi8/ubi-mimimal
) があります。これらのイメージはすべて、標準の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>: {}
コンポーネント | 説明 | 許可される値 |
---|---|---|
| メタデータのタイプ |
|
| プロバイダー ID の文字列 |
|
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: {}
イメージの品質アノテーションの値は、以下の形式に従った構造化データになります。
フィールド | 必須 ? | 説明 | タイプ |
---|---|---|---|
| はい | プロバイダーの表示名 | 文字列 |
| はい | スキャンのタイムスタンプ | 文字列 |
| いいえ | 簡単な説明 | 文字列 |
| はい | 情報ソースの URL または詳細情報。ユーザーのデータ検証に必要。 | 文字列 |
| いいえ | スキャナーバージョン | 文字列 |
| いいえ | コンプライアンスの合否 | ブール値 |
| いいえ | 検出された問題の要約 | 一覧 (以下の表を参照) |
summary
フィールドは、以下の形式に従う必要があります。
フィールド | 説明 | タイプ |
---|---|---|
| コンポーネントの表示ラベル (例: critical、important、moderate、low または health) | 文字列 |
| このコンポーネントのデータ (例: 検出された脆弱性の数またはスコア) | 文字列 |
|
順序付けおよびグラフィック表示の割り当てを可能にするコンポーネントのインデックス。値は | 整数 |
| 情報ソースの 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 Container 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.6 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 ではコンテナーのコンテンツの脆弱性を監視し、コンテンツを定期的に更新しています。glibc、DROWN、または 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 ストレージ に保存し、後に検索および分析に使用できるようにします。
- Clair security scanning (Clair セキュリティースキャン): 各コンテナーイメージの起点に基づいて、さまざまな Linux 脆弱性データベースに対してイメージをスキャンします。各コンテナーイメージの起点に基づいて、さまざまな 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 Container Platform レジストリーを Red Hat Quay に置き換えることができます。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 プロセスを使用して自動的にデプロイされます。
統合された OpenShift Container レジストリーを使用して、最終イメージへのアクセスを管理できます。S2I イメージおよびネイティブビルドイメージの両方は OpenShift Container レジストリーに自動的にプッシュされます。
CI の組み込まれた Jenkins のほかに、独自のビルドおよび CI 環境を RESTful API および API 準拠のイメージレジストリーを使用して OpenShift Container Platform に統合することもできます。
2.8.3. ビルド時の入力のセキュリティー保護
シナリオによっては、ビルド操作において、依存するリソースにアクセスするために認証情報が必要になる場合がありますが、この認証情報をビルドで生成される最終的なアプリケーションイメージで利用可能にすることは適切ではありません。このため、入力シークレットを定義することができます。
たとえば、Node.js アプリケーションのビルド時に、Node.js モジュールのプライベートミラーを設定できます。プライベートミラーからモジュールをダウンロードするには、URL、ユーザー名、パスワードを含む、ビルド用のカスタム .npmrc
ファイルを指定する必要があります。セキュリティー上の理由により、認証情報はアプリケーションイメージで公開しないでください。
この例で示したシナリオを使用して、入力シークレットを新規の BuildConfig
オブジェクトに追加できます。
シークレットがない場合は作成します。
$ oc create secret generic secret-npmrc --from-file=.npmrc=~/.npmrc
これにより、
secret-npmrc
という名前の新規シークレットが作成されます。 これには、~/.npmrc
ファイルの base64 でエンコードされたコンテンツが含まれます。シークレットを既存の
BuildConfig
オブジェクトのsource
セクションに追加します。source: git: uri: https://github.com/sclorg/nodejs-ex.git secrets: - destinationDir: . secret: name: secret-npmrc
シークレットを新規の
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. シークレットおよび設定マップの作成
Secret
オブジェクトタイプはパスワード、OpenShift Container Platform クライアント設定ファイル、dockercfg
ファイル、プライベートソースリポジトリーの認証情報などの機密情報を保持するメカニズムを提供します。シークレットは機密内容を Pod から切り離します。シークレットはボリュームプラグインを使用してコンテナーにマウントすることも、システムが Pod の代わりにシークレットを使用して各種アクションを実行することもできます。
たとえば、プライベートイメージリポジトリーにアクセスできるように、シークレットをデプロイメント設定に追加するには、以下を実行します。
手順
- OpenShift Container Platform Web コンソールにログインします。
- 新規プロジェクトを作成します。
-
Resources → Secrets に移動し、新規シークレットを作成します。
Secret Type
をImage Secret
に、Authentication Type
をImage Registry Credentials
に設定し、プライベートイメージリポジトリーにアクセスするために必要な認証情報を入力します。 -
デプロイメント設定を作成する場合 (例: Add to Project → Deploy Image ページに移動する)、
Pull Secret
を新規シークレットに設定します。
設定マップはシークレットに似ていますが、機密情報を含まない文字列の使用をサポートするように設計されています。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 では、クラスター全体のロールおよびバインディングをクラスターのすべてのプロジェクトに割り当てることができます。admin
、basic-user
、 cluster-admin
、および cluster-status
アクセスを提供するために割り当てることのできるデフォルトのクラスターロールがあります。
2.10.2. 受付プラグインでのコントロールプレーンの保護
RBAC はユーザーおよびグループと利用可能なプロジェクト間のアクセスルールを制御しますが、受付プラグイン は OpenShift Container Platform マスター API へのアクセスを定義します。受付プラグインは、以下で設定されるルールのチェーンを形成します。
- デフォルトの受付プラグイン: これは、OpenShift Container Platform コントロールプレーンのコンポーネントに適用されるポリシーおよびリソース制限のデフォルトセットを実装します。
- 変更用の受付プラグイン: これらのプラグインは受付チェーンを動的に拡張します。これらは Webhook サーバーに対する呼び出しを実行し、要求の認証および選択されたリソースの変更の両方を実行します。
- 検証用の受付プラグイン: 選択されたリソースの要求を検証し、要求を検証すると共にリソースが再度変更されないようにすることができます。
API 要求はチェーン内の受付プラグインを通過し、途中で失敗した場合には要求が拒否されます。それぞれの受付プラグインは特定のリソースに関連付けられ、それらのリソースの要求にのみ応答します。
2.10.2.1. SCC (Security Context Constraints)
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 Container Storage *
- 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 には、ReadWriteOnce
、ReadOnlyMany
、および ReadWriteMany
など、特定の PV 機能を説明したアクセスモードの独自のセットがあります。
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 および Cluster Logging Operator を使用してクラスターロギングのデプロイ、管理、およびアップグレードをすることができます。
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 形式のファイルにコピーします。
手順
ワイルドカード証明書の署名に使用されるルート 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 証明書ファイルへのパスです。
新たに作成された設定マップでクラスター全体のプロキシー設定を更新します。
$ oc patch proxy/cluster \ --type=merge \ --patch='{"spec":{"trustedCA":{"name":"custom-ca"}}}'
ワイルドカード証明書チェーンおよびキーが含まれるシークレットを作成します。
$ oc create secret tls <secret> \1 --cert=</path/to/cert.crt> \2 --key=</path/to/cert.key> \3 -n openshift-ingress
Ingress コントローラー設定を、新規に作成されたシークレットで更新します。
$ oc patch ingresscontroller.operator default \ --type=merge -p \ '{"spec":{"defaultCertificate": {"name": "<secret>"}}}' \1 -n openshift-ingress-operator
- 1
<certificate>
を、直前の手順でシークレットに使用された名前に置き換えます。
関連情報
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>
)。これを指定すると、クラスターの状態は動作の低下した状態になります。
手順
kubeadmin
ユーザーとして新しい API にログインします。$ oc login -u kubeadmin -p <password> https://FQDN:6443
kubeconfig
ファイルを取得します。$ oc config view --flatten > kubeconfig-newapi
openshift-config
namespace に証明書およびプライベートキーが含まれるシークレットを作成します。$ oc create secret tls <secret> \1 --cert=</path/to/cert.crt> \2 --key=</path/to/cert.key> \3 -n openshift-config
API サーバーを作成されたシークレットを参照するように更新します。
$ oc patch apiserver cluster \ --type=merge -p \ '{"spec":{"servingCerts": {"namedCertificates": [{"names": ["<FQDN>"], 1 "servingCertificate": {"name": "<secret>"}}]}}}' 2
apiserver/cluster
オブジェクトを検査し、シークレットが参照されていることを確認します。$ oc get apiserver cluster -o yaml
出力例
... spec: servingCerts: namedCertificates: - names: - <FQDN> servingCertificate: name: <secret> ...
kube-apiserver
Operator を確認し、Kubernetes API サーバーの新しいリビジョンがロールアウトされることを確認します。Operator が設定の変更を検出して新しいデプロイメントをトリガーするのに 1 分かかる場合があります。新しいリビジョンが公開されている間、PROGRESSING
はTrue
を報告します。$ oc get clusteroperators kube-apiserver
以下の出力にあるように、
PROGRESSING
がFalse
と表示されるまで次の手順に移行しないでください。出力例
NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE kube-apiserver 4.6.0 True False False 145m
PROGRESSING
がTrue
と表示されている場合は、数分待機してから再試行します。
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
にのみ有効であり、内部通信用にのみ有効です。
前提条件
- サービスが定義されていること。
手順
サービスに
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
たとえば、以下のコマンドを使用してサービス
test1
にアノテーションを付けます。$ oc annotate service test1 service.beta.openshift.io/serving-cert-secret-name=test1
アノテーションが存在することを確認するためにサービスを検査します。
$ 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 ...
-
クラスターがサービスのシークレットを生成した後に、
Pod
仕様がこれをマウントでき、Pod はシークレットが利用可能になった後にこれを実行できます。
関連情報
- サービス証明書を使用して、reencrypt TLS 終端を使用してセキュアなルートを設定できます。詳細は、カスタム証明書を使用した re-encrypt ルートの作成 を参照してください。
3.3.3. サービス CA バンドルの設定マップへの追加
Pod は、service.beta.openshift.io/inject-cabundle=true
のアノテーションの付いた ConfigMap
オブジェクトをマウントしてサービス CA 証明書にアクセスできます。アノテーションが付けられると、クラスターはサービス CA 証明書を設定マップの service-ca.crt
キーに自動的に挿入します。この CA 証明書にアクセスできると、TLS クライアントはサービス提供証明書を使用してサービスへの接続を検証できます。
このアノテーションが設定マップに追加されると、その中に含まれるすべての既存データが削除されます。service-ca.crt
を組み込む設定マップとしては、Pod の設定の保存先と同じ設定マップではなく、別の設定マップを使用することが推奨されます。
手順
設定マップに
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
設定マップを表示して、サービス 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 証明書を検証することができます。
手順
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
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 バンドルを挿入することは役に立ちます。
手順
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
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 について挿入されます。
手順
変更用 Webhook 設定に
service.beta.openshift.io/inject-cabundle=true
のアノテーションを付けます。$ oc annotate mutatingwebhookconfigurations <mutating_webhook_name> \1 service.beta.openshift.io/inject-cabundle=true
- 1
<mutatingwebhook-name>
を、アノテーションを付ける変更用 webhook 設定の名前に置き換えます。
たとえば、以下のコマンドを使用して変更用 webhook 設定
test1
にアノテーションを付けます。$ oc annotate mutatingwebhookconfigurations test1 service.beta.openshift.io/inject-cabundle=true
変更用 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 について挿入されます。
手順
検証用 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
検証用 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. 生成されたサービス証明書の手動によるローテーション
関連付けられたシークレットを削除することにより、サービス証明書をローテーションできます。シークレットを削除すると、新規のシークレットが自動的に作成され、新規証明書が作成されます。
前提条件
- 証明書とキーのペアを含むシークレットがサービス用に生成されていること。
手順
証明書を含むシークレットを確認するためにサービスを検査します。これは、以下に示すように
serving-cert-secret-name
アノテーションにあります。$ oc describe service <service_name>
出力例
... service.beta.openshift.io/serving-cert-secret-name: <secret> ...
サービスの生成されたシークレットを削除します。このプロセスで、シークレットが自動的に再作成されます。
$ oc delete secret <secret> 1
- 1
<secret>
を、直前の手順のシークレットの名前に置き換えます。
新規シークレットを取得し、
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 で発行されるサービス提供証明書を使用できるようになります。
前提条件
- クラスター管理者としてログインしている必要があります。
手順
以下のコマンドを使用して、現在のサービス CA 証明書の有効期限を表示します。
$ oc get secrets/signing-key -n openshift-service-ca \ -o template='{{index .data "tls.crt"}}' \ | base64 --decode \ | openssl x509 -noout -enddate
サービス CA を手動でローテーションします。このプロセスは、新規サービス証明書に署名するために使用される新規サービス CA を生成します。
$ oc delete secret/signing-key -n openshift-service-ca
新規証明書をすべてのサービスに適用するには、クラスター内のすべての 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 バンドルの更新
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 バンドル証明書の置き換え
手順
ワイルドカード証明書の署名に使用されるルート 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 証明書バンドルへのパスです。
新たに作成された設定マップでクラスター全体のプロキシー設定を更新します。
$ 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://<https://username:password@proxy.example.com:123/> httpsProxy: https://<https://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 で発行されるサービス提供証明書を使用できるようになります。
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. 目的
ノード証明書はクラスターによって署名されます。それらは、ブートストラッププロセスで生成される認証局 (CA) からの証明書です。クラスターがインストールされると、ノード証明書は自動的にローテーションされます。
4.4.2. 管理
これらの証明書は、ユーザーではなく、システムによって管理されます。
関連情報
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. 有効期限
このブートストラップ CA は 10 年間有効です。
kubelet が管理する証明書は 1 年間有効であり、その 1 年の約 80 パーセントマークで自動的にローテーションします。
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-client
、etcd-metric-client
、etcd-metric-signer
、およびetcd-signer
) はopenshift-config
、openshift-monitoring
、およびopenshift-kube-apiserver
namespace に追加されます。 - サーバー証明書: クライアント要求を認証するために etcd サーバーによって使用されます。
- メトリクス証明書: メトリクスのすべてのコンシューマーは metric-client 証明書を使用してプロキシーに接続します。
関連情報
4.7. OLM 証明書
4.7.1. 管理
OpenShift Lifecycle Manager (OLM) コンポーネント (olm-operator
、catalog-operator
、packageserver
、および marketplace-operator
) のすべての証明書はシステムによって管理されます。
Webhook または API サービスを含む Operator を ClusterServiceVersion
(CSV) オブジェクトにインストールする場合、OLM はこれらのリソースの証明書を作成し、ローテーションします。openshift-operator-lifecycle-manager
namespace のリソースの証明書は OLM によって管理されます。
OLM はプロキシー環境で管理する Operator の証明書を更新しません。これらの証明書は、ユーザーがサブスクリプション設定で管理する必要があります。
4.8. デフォルト ingress のユーザーによって提供される証明書
4.8.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.8.2. 場所
ユーザーによって提供される証明書は、openshift-ingress
namespace の tls
タイプの Secret
で指定される必要があります。ユーザーがユーザーによって提供される証明書を有効にできるようにするために、openshift-ingress-operator
namespace で IngressController
CR を更新します。このプロセスについての詳細は、カスタムデフォルト証明書の設定 を参照してください。
4.8.3. 管理
ユーザーによって提供される証明書はユーザーによって管理されます。
4.8.4. 有効期限
ユーザーによって提供される証明書はユーザーによって管理されます。
4.8.5. サービス
クラスターにデプロイされるアプリケーションは、デフォルト Ingress にユーザーによって提供される証明書を使用します。
4.8.6. カスタマイズ
必要に応じて、ユーザーが管理する証明書を含むシークレットを更新します。
関連情報
4.9. Ingress 証明書
4.9.1. 目的
Ingress Operator は以下の目的で証明書を使用します。
- Prometheus のメトリクスへのアクセスのセキュリティーを保護する。
- ルートへのアクセスのセキュリティーを保護する。
4.9.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.9.3. ワークフロー
図4.1 カスタム証明書のワークフロー
図4.2 デフォルトの証明書ワークフロー
空の defaultCertificate
フィールドにより、Ingress Operator はその自己署名 CA を使用して指定されたドメインの提供証明書を生成します。
Ingress Operator によって生成されるデフォルトの CA 証明書およびキー。Operator が生成するデフォルトの提供証明書に署名するために使用されます。
デフォルトのワークフローでは、Ingress Operator によって作成され、生成されるデフォルト CA 証明書を使用して署名されるワイルドカードのデフォルト提供証明書です。カスタムワークフローでは、これはユーザーによって提供される証明書です。
ルーターのデプロイメント。secrets/router-certs-default
の証明書を、デフォルトのフロントエンドサーバー証明書として使用します。
デフォルトのワークフローでは、ワイルドカードのデフォルト提供証明書 (パブリックおよびプライベートの部分) の内容がここにコピーされ、OAuth 統合が有効になります。カスタムワークフローでは、これはユーザーによって提供される証明書です。
デフォルト提供証明書のパブリック (証明書) の部分です。configmaps/router-ca
リソースを置き換えます。
ユーザーは ingresscontroller
提供証明書に署名した CA 証明書でクラスタープロキシー設定を更新します。これにより、auth
、console
などのコンポーネントや、提供証明書を信頼するために使用するレジストリーが有効になります。
ユーザーバンドルが指定されていない場合に、組み合わせた Red Hat Enterprise Linux CoreOS (RHCOS) およびユーザーによって提供される CA バンドルまたは RHCOS のみのバンドルを含むクラスター全体の信頼される CA バンドルです。
他のコンポーネント (auth
および console
など) がカスタム証明書で設定された ingresscontroller
を信頼するよう指示するカスタム CA 証明書バンドルです。
trustedCA
フィールドは、ユーザーによって提供される CA バンドルを参照するように使用されます。
Cluster Network Operator は、信頼される CA バンドルを proxy-ca
設定マップに挿入します。
OpenShift Container Platform 4.6 以降では、default-ingress-cert
を使用します。
4.9.4. 有効期限
Ingress Operator の証明書の有効期限は以下の通りです。
-
service-ca
コントローラーが作成するメトリクス証明書の有効期限は、作成日から 2 年間です。 - Operator の署名証明書の有効期限は、作成日から 2 年間です。
- Operator が生成するデフォルト証明書の有効期限は、作成日から 2 年間です。
Ingress Operator または service-ca
コントローラーが作成する証明書のカスタム有効期限を指定することはできません。
Ingress Operator または service-ca
コントローラーが作成する証明書について OpenShift Container Platform をインストールする場合に、有効期限を指定することはできません。
4.9.5. サービス
Prometheus はメトリクスのセキュリティーを保護する証明書を使用します。
Ingress Operator はその署名証明書を使用して、カスタムのデフォルト証明書を設定しない Ingress コントローラー用に生成するデフォルト証明書に署名します。
セキュリティー保護されたルートを使用するクラスターコンポーネントは、デフォルトの Ingress コントローラーのデフォルト証明書を使用できます。
セキュリティー保護されたルート経由でのクラスターへの Ingress は、ルートが独自の証明書を指定しない限り、ルートがアクセスされる Ingress コントローラーのデフォルト証明書を使用します。
4.9.6. 管理
Ingress 証明書はユーザーによって管理されます。詳細は、デフォルト ingress 証明書の置き換え を参照してください。
4.9.7. 更新
service-ca
コントローラーは、これが発行する証明書を自動的にローテーションします。ただし、oc delete secret <secret>
を使用してサービス提供証明書を手動でローテーションすることができます。
Ingress Operator は、独自の署名証明書または生成するデフォルト証明書をローテーションしません。Operator が生成するデフォルト証明書は、設定するカスタムデフォルト証明書のプレースホルダーとして使用されます。
4.10. モニターリングおよびクラスターロギング Operator コンポーネント証明書
4.10.1. 有効期限
モニターリングコンポーネントは、サービス CA 証明書でトラフィックのセキュリティーを保護します。これらの証明書は 2 年間有効であり、13 ヵ月ごとに実行されるサービス CA のローテーションで自動的に置き換えられます。
証明書が openshift-monitoring
または openshift-logging
namespace にある場合、これはシステムで管理され、自動的にローテーションされます。
4.10.2. 管理
これらの証明書は、ユーザーではなく、システムによって管理されます。
4.11. コントロールプレーンの証明書
4.11.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.11.2. 管理
コントロールプレーンの証明書はシステムによって管理され、自動的にローテーションされます。
稀なケースとしてコントロールプレーンの証明書の有効期限が切れる場合は、コントロールプレーン証明書の期限切れの状態からのリカバリー を参照してください。
第5章 コンプライアンス Operator
5.1. コンプライアンス Operator リリースノート
コンプライアンス Operator を使用すると、OpenShift Container Platform 管理者はクラスターの必要なコンプライアンス状態を記述し、存在するギャップやそれらを修復する方法についての概要を提供します。
これらのリリースノートは、OpenShift Container Platform での コンプライアンス Operator の開発を追跡します。
Compliance Operator の概要については、Compliance Operator について を参照してください。
5.1.1. OpenShift Compliance Operator 0.1.53
OpenShift コンプライアンス Operator 0.1.53 については、以下のアドバイザリーが利用できます。
5.1.1.1. バグ修正
-
以前は、
ocp4-kubelet-enable-streaming-connections
ルールに誤った変数比較が含まれていたため、スキャン結果が誤検出されていました。現在、コンプライアンス 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) -
以前は、デプロイメント内のセキュリティーコンテキスト制約 (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
ルールは、タイムアウトのコンプライアンスを評価するときに、デプロイメントによって設定された設定可能なタイムアウトを考慮していませんでした。その結果、タイムアウトが有効であってもルールが失敗していました。現在、コンプライアンス Operator は、var_oauth_inactivity_timeout
変数を使用して、有効なタイムアウトの長さを設定しています。(BZ#2081952) - 以前は、コンプライアンス Operator は、特権使用に適切にラベル付けされていない namespace に対して管理者権限を使用していたため、Pod のセキュリティーレベル違反に関する警告メッセージが表示されていました。現在、コンプライアンス Operator は、適切な namespace ラベルと権限調整を行い、権限に違反することなく結果にアクセスできるようになっています。(BZ#2088202)
-
以前は、
rhcos4-high-master-sysctl-kernel-yama-ptrace-scope
およびrhcos4-sysctl-kernel-core-pattern
に自動修復を適用すると、それらのルールが修復されても、その後のスキャン結果で失敗することがありました。現在、修復が適用された後でも、ルールはPASS
を正確に報告します。(BZ#2094382) -
以前は、コンプライアンス Operator は、メモリー不足の例外が原因で
CrashLoopBackoff
状態で失敗していました。現在では、コンプライアンス Operator は、メモリー内の大規模なマシン設定データセットを処理し、正しく機能するように改良されました。(BZ#2094854)
5.1.1.2. 既知の問題
ScanSettingBinding
オブジェクト内でdebug:true
が設定されている場合に、そのバインディングが削除されても、ScanSettingBinding
オブジェクトによって生成された Pod は削除されません。回避策として、次のコマンドを実行して残りの Pod を削除します。$ oc delete pods -l compliance.openshift.io/scan-name=ocp4-cis
5.1.2. OpenShift コンプライアンス Operator 0.1.52
OpenShift コンプライアンス Operator 0.1.52 については、以下のアドバイザリーが利用できます。
5.1.2.1. 新機能および機能拡張
- FedRAMP の SCAP プロファイル high が、OpenShift Container Platform 環境で使用できるようになりました。詳細は、サポート対象のコンプライアンスプロファイル を参照してください。
5.1.2.2. バグ修正
-
以前は、
DAC_OVERRIDE
機能が削除されているセキュリティー環境でのマウントパーミッションの問題が原因で、OpenScap
コンテナーがクラッシュしていました。今回は、実行可能なマウントパーミッションがすべてのユーザーに適用されるようになりました。(BZ#2082151) -
以前は、コンプライアンスルール
ocp4-configure-network-policies
をMANUAL
として設定できました。今回は、コンプライアンスルールocp4-configure-network-policies
がAUTOMATIC
に設定されるようになりました。(BZ#2072431) - 以前は、コンプライアンス Operator のスキャン Pod はスキャン後に削除されないため、Cluster Autoscaler はスケールダウンできませんでした。今回は、デバッグ目的で明示的に保存されていない限り、Pod はデフォルトで各ノードから削除されるようになりました。(BZ#2075029)
-
以前は、コンプライアンス Operator を
KubeletConfig
に適用すると、マシン設定プールの一時停止が早すぎてノードがNotReady
状態になることがありました。今回は、マシン設定プールは停止されず、ノードが正常に機能するようになりました。(BZ#2071854) -
以前のバージョンでは、Machine Config Operator は最新のリリースで
url-encoded
コードではなくbase64
を使用していたため、コンプライアンス Operator の修復が失敗していました。コンプライアンス Operator は、base64
およびurl-encoded
マシン設定コードの両方を処理するようにエンコーディングをチェックし、修復が適切に実行されるようになりました。(BZ#2082431)
5.1.2.3. 既知の問題
ScanSettingBinding
オブジェクト内でdebug:true
が設定されている場合に、そのバインディングが削除されても、ScanSettingBinding
オブジェクトによって生成された Pod は削除されません。回避策として、次のコマンドを実行して残りの Pod を削除します。$ oc delete pods -l compliance.openshift.io/scan-name=ocp4-cis
5.1.3. OpenShift コンプライアンス Operator 0.1.49
OpenShift コンプライアンス Operator 0.1.49 については、以下のアドバイザリーが利用できます。
5.1.3.1. バグ修正
-
以前は、
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 のリストが切り捨てられたため、ルールが失敗しました。これで、namespaces リスト全体がリクエストされ、設定されたネットワークポリシーをチェックするためのルールは、500 を超える namespaces を持つデプロイメントで機能します。(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.1.4. OpenShift コンプライアンス Operator 0.1.48
OpenShift コンプライアンス Operator 0.1.48 については、以下のアドバイザリーを利用できます。
5.1.4.1. バグ修正
-
以前は、拡張された Open Vulnerability and Assessment Language (OVAL) 定義に関連する一部のルールの
checkType
はNone
でした。これは、コンプライアンス Operator が、ルールを解析するときに拡張 OVAL 定義を処理していなかったためです。この更新により、拡張 OVAL 定義のコンテンツが解析され、これらのルールのcheckType
がNode
またはPlatform
になります。(BZ#2040282) -
以前は、
KubeletConfig
用に手動で作成されたMachineConfig
オブジェクトにより、KubeletConfig
オブジェクトが修復用に生成されなくなり、修復がPending
状態のままになりました。このリリースでは、KubeletConfig
用に手動で作成されたMachineConfig
オブジェクトがあるかどうかに関係なく、修復によってKubeletConfig
オブジェクトが作成されます。その結果、KubeletConfig
の修正が期待どおりに機能するようになりました。(BZ#2040401)
5.1.5. OpenShift コンプライアンス Operator 0.1.47
OpenShift コンプライアンス Operator 0.1.47 については、以下のアドバイザリーを利用できます。
5.1.5.1. 新機能および機能拡張
コンプライアンス 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.1.5.2. バグ修正
以前は、クラスターが OpenShift Container Platform 4.6 以前を実行していた場合、中程度のプロファイルでは USBGuard 関連のルールの修正が失敗していました。これは、コンプライアンス Operator によって作成された修正が、ドロップインディレクトリーをサポートしていない古いバージョンの USBGuard に基づいていたためです。現在、OpenShift Container Platform 4.6 を実行しているクラスターでは、USBGuard 関連のルールの無効な修復は作成されません。クラスターが OpenShift Container Platform 4.6 を使用している場合は、USBGuard 関連のルールの修正を手動で作成する必要があります。
さらに、修正は、最小バージョン要件を満たすルールに対してのみ作成されます。(BZ#1965511)
-
以前のリリースでは、修正をレンダリングする場合には、コンプライアンス Operator は、その修正が適切に設定されているかを、厳密すぎる正規表現を使用して確認していました。その結果、
sshd_config
をレンダリングするような一部の修正は、正規表現チェックに合格しないため、作成されませんでした。正規表現は不要であることが判明し、削除されました。修復が正しくレンダリングされるようになりました。(BZ#2033009)
5.1.6. OpenShift コンプライアンス Operator 0.1.44
OpenShift コンプライアンス Operator 0.1.44 については、以下のアドバイザリーを利用できます。
5.1.6.1. 新機能および機能拡張
-
このリリースでは、
strictNodeScan
オプションがComplianceScan
、ComplianceSuite
、およびScanSetting
CR に追加されました。このオプションのデフォルトはtrue
で、これは以前の動作と一致します。ノードでスキャンをスケジュールできなかった場合にエラーが発生しました。このオプションをfalse
に設定すると、コンプライアンス Operator は、スキャンのスケジュールについてより寛容になります。エフェメラルノードのある環境では、strictNodeScan
値を false に設定できます。これにより、クラスター内の一部のノードがスケジューリングに使用できない場合でも、コンプライアンススキャンを続行できます。 -
ScanSetting
オブジェクトのnodeSelector
属性とtolerations
属性を設定することにより、結果サーバーのワークロードをスケジュールするために使用されるノードをカスタマイズできるようになりました。これらの属性は、PV ストレージボリュームをマウントし、生の Asset Reporting Format (ARF) 結果を格納するために使用される Pod であるResultServer
Pod を配置するために使用されます。以前は、nodeSelector
パラメーターおよびtolerations
パラメーターは、デフォルトでコントロールプレーンノードの 1 つを選択し、node-role.kubernetes.io/master taint
を許容していました。これは、コントロールプレーンノードが PV をマウントすることを許可されていない環境では機能しませんでした。この機能は、ノードを選択し、それらの環境で異なる汚染を許容する方法を提供します。 -
コンプライアンス Operator は、
KubeletConfig
オブジェクトを修正できるようになりました。 - エラーメッセージを含むコメントが追加され、コンテンツ開発者がクラスターに存在しないオブジェクトとフェッチできないオブジェクトを区別できるようになりました。
-
ルールオブジェクトには、
checkType
およびdescription
の 2 つの新しい属性が含まれるようになりました。これらの属性を使用すると、ルールがノードチェックとプラットフォームチェックのどちらに関連しているかを判断したり、ルールの機能を確認したりできます。 -
この機能拡張により、調整されたプロファイルを作成するために既存のプロファイルを拡張する必要があるという要件がなくなります。これは、
TailoredProfile
CRD のextends
フィールドが必須ではなくなったことを意味します。これで、ルールオブジェクトのリストを選択して、調整されたプロファイルを作成できます。compliance.openshift.io/product-type:
アノテーションを設定するか、TailoredProfile
CR の-node
接尾辞を設定して、プロファイルをノードに適用するかプラットフォームに適用するかを選択する必要があることに注意してください。 -
このリリースでは、コンプライアンス Operator は、汚染に関係なく、すべてのノードでスキャンをスケジュールできるようになりました。以前は、スキャン Pod は
node-role.kubernetes.io/master taint
のみを許容していました。つまり、汚染のないノードで実行するか、node-role.kubernetes.io/master
汚染のあるノードでのみ実行していました。ノードにカスタム汚染を使用するデプロイメントでは、これにより、それらのノードでスキャンがスケジュールされませんでした。現在、スキャン Pod はすべてのノードの汚染を許容します。 このリリースでは、コンプライアンス Operator は、次の North American Electric Reliability Corporation (NERC) のセキュリティープロファイルをサポートしています。
- ocp4-nerc-cip
- ocp4-nerc-cip-node
- rhcos4-nerc-cip
- このリリースでは、コンプライアンス Operator は、NIST 800-53 Moderate-Impact Baseline for the Red Hat OpenShift - Node level, ocp4-moderate-node セキュリティープロファイルをサポートします。
5.1.6.2. テンプレートと変数の使用
- このリリースでは、修復テンプレートで複数値の変数を使用できるようになりました。
-
この更新により、コンプライアンス Operator は、コンプライアンスプロファイルで設定された変数に基づいて修正を変更できます。これは、タイムアウト、NTP サーバーのホスト名などのデプロイメント固有の値を含む修復に役立ちます。さらに、
ComplianceCheckResult
オブジェクトは、チェックが使用した変数をリストするラベルcompliance.openshift.io/check-has-value
を使用するようになりました。
5.1.6.3. バグ修正
- 以前は、スキャンの実行中に、Pod のスキャナーコンテナーの 1 つで予期しない終了が発生しました。このリリースでは、コンプライアンス 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.1.7. コンプライアンス Operator 0.1.39 リリースノート
OpenShift コンプライアンス Operator 0.1.39 については、以下のアドバイザリーが利用できます。
5.1.7.1. 新機能および機能拡張
- 以前は、コンプライアンス Operator は、Payment Card Industry Data Security Standard (PCI DSS) 参照を解析できませんでした。これで、オペレーターは PCI DSS プロファイルに付属するコンプライアンスコンテンツを解析できます。
- 以前は、コンプライアンス Operator は、中程度のプロファイルで AU-5 制御のルールを実行できませんでした。これで、Prometheusrules.monitoring.coreos.com オブジェクトを読み取り、中程度のプロファイルで AU-5 コントロールを扱うルールを実行できるように、Operator にアクセス許可が追加されました。
5.1.8. 関連情報
5.2. サポートされているコンプライアンスプロファイル
コンプライアンス Operator (CO) のインストールの一部として利用可能なプロファイルは複数あります。
5.2.1. コンプライアンスプロファイル
コンプライアンス Operator は、次のコンプライアンスプロファイルを提供します。
プロファイル | プロファイルタイトル | コンプライアンス Operator バージョン | 業界コンプライアンスベンチマーク | サポートされているアーキテクチャー |
---|---|---|---|---|
ocp4-cis | CIS Red Hat OpenShift Container Platform 4 Benchmark | 0.1.39+ |
CIS Benchmarks ™ footnote:cisbenchmark[CIS Red Hat OpenShift Container Platform v4 ベンチマークを見つけるには、CIS ベンチマーク に移動し、検索ボックスに |
|
ocp4-cis-node | CIS Red Hat OpenShift Container Platform 4 Benchmark | 0.1.39+ | CIS Benchmarks ™ footnote:cisbenchmark[] |
|
ocp4-e8 | Australian Cyber Security Centre (ACSC) Essential Eight | 0.1.39+ |
| |
ocp4-moderate | NIST 800-53 Moderate-Impact Baseline for Red Hat OpenShift - Platform level | 0.1.39+ |
| |
rhcos4-e8 | Australian Cyber Security Centre (ACSC) Essential Eight | 0.1.39+ |
| |
rhcos4-moderate | NIST 800-53 Moderate-Impact Baseline for Red Hat Enterprise Linux CoreOS | 0.1.39+ |
| |
ocp4-moderate-node | NIST 800-53 Moderate-Impact Baseline for Red Hat OpenShift - Node level | 0.1.44+ |
| |
ocp4-nerc-cip | North American Electric Reliability Corporation (NERC) Critical Infrastructure Protection (CIP) cybersecurity standards profile for the Red Hat OpenShift Container Platform - Platform レベル | 0.1.44+ |
| |
ocp4-nerc-cip-node | North American Electric Reliability Corporation (NERC) Critical Infrastructure Protection (CIP) cybersecurity standards profile for the Red Hat OpenShift Container Platform - Node レベル | 0.1.44+ |
| |
rhcos4-nerc-cip | North American Electric Reliability Corporation (NERC) Critical Infrastructure Protection (CIP) cybersecurity standards profile for Red Hat Enterprise Linux CoreOS | 0.1.44+ |
| |
ocp4-pci-dss | PCI-DSS v3.2.1 Control Baseline for Red Hat OpenShift Container Platform 4 | 0.1.47+ |
| |
ocp4-pci-dss-node | PCI-DSS v3.2.1 Control Baseline for Red Hat OpenShift Container Platform 4 | 0.1.47+ |
| |
ocp4-high | NIST 800-53 Moderate-Impact Baseline for Red Hat OpenShift - プラットフォームレベル | 0.1.52+ |
| |
ocp4-high-node | NIST 800-53 High-Impact Baseline for Red Hat OpenShift - ノードレベル | 0.1.52+ |
| |
rhcos4-high | NIST 800-53 High-Impact Baseline for Red Hat Enterprise Linux CoreOS | 0.1.52+ |
|
5.2.2. 関連情報
- システムで使用可能なコンプライアンスプロファイルの表示の詳細については、Compliance Operator についての Compliance Operator profiles を参照してください。
5.3. コンプライアンス Operator のインストール
コンプライアンス Operator を使用する前に、これがクラスターにデプロイされていることを確認する必要があります。
5.3.1. Web コンソールを使用したコンプライアンス Operator のインストール
前提条件
-
admin
権限がある。
手順
- OpenShift Container Platform Web コンソールで、Operators → OperatorHub ページに移動します。
- コンプライアンス Operator を検索し、Install をクリックします。
-
Installation mode および namespace のデフォルトの選択を維持し、Operator が
openshift-compliance
namespace にインストールされていることを確認します。 - Install をクリックします。
検証
インストールが正常に行われたことを確認するには、以下を実行します。
- Operators → Installed Operators ページに移動します。
-
コンプライアンス Operator が
openshift-compliance
namespace にインストールされ、そのステータスがSucceeded
であることを確認します。
Operator が正常にインストールされていない場合、以下を実行します。
-
Operators → Installed Operators ページに移動し、
Status
列でエラーまたは失敗の有無を確認します。 -
Workloads → Pods ページに移動し、
openshift-compliance
プロジェクトの Pod で問題を報告しているログの有無を確認します。
5.3.2. CLI を使用したコンプライアンス Operator のインストール
前提条件
-
admin
権限がある。
手順
Namespace
オブジェクトを定義します。namespace-object.yaml
の例apiVersion: v1 kind: Namespace metadata: labels: openshift.io/cluster-monitoring: "true" name: openshift-compliance
Namespace
オブジェクトを作成します。$ oc create -f namespace-object.yaml
OperatorGroup
オブジェクトを定義します。operator-group-object.yaml
の例apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: compliance-operator namespace: openshift-compliance spec: targetNamespaces: - openshift-compliance
OperatorGroup
オブジェクトを作成します。$ oc create -f operator-group-object.yaml
Subscription
オブジェクトを定義します。subscription-object.yaml
の例apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: compliance-operator-sub namespace: openshift-compliance spec: channel: "release-0.1" installPlanApproval: Automatic name: compliance-operator source: redhat-operators sourceNamespace: openshift-marketplace
Subscription
オブジェクトを作成します。$ oc create -f subscription-object.yaml
グローバルスケジューラー機能を設定する際に、defaultNodeSelector
を有効にする場合、namespace を手動で作成し、openshift-compliance
のアノテーションを更新するか、または openshift.io/node-selector: “"
を使用してコンプライアンス Operator がインストールされている namespace のアノテーションを更新する必要があります。これにより、デフォルトのノードセレクターが削除され、デプロイメントの失敗を防ぐことができます。
検証
CSV ファイルを確認して、インストールが正常に完了したことを確認します。
$ oc get csv -n openshift-compliance
コンプライアンス Operator が稼働していることを確認します。
$ oc get deploy -n openshift-compliance
5.3.3. 関連情報
- コンプライアンス Operator はネットワークが制限された環境でサポートされています。詳細は、ネットワークが制限された環境での Operator Lifecycle Manager の使用 を参照してください。
5.4. コンプライアンス Operator のスキャン
ScanSetting および
ScanSettingBinding
API は、コンプライアンス Operator でコンプライアンススキャンを実行するために使用することが推奨されます。これらの API オブジェクトの詳細については、以下を実行します。
$ oc explain scansettings
または
$ oc explain scansettingbindings
5.4.1. コンプライアンススキャンの実行
Center for Internet Security (CIS) プロファイルを使用してスキャンを実行できます。便宜上、コンプライアンス Operator は起動時に適切なデフォルト値を持つ ScanSetting
オブジェクトを作成します。この ScanSetting
オブジェクトの名前は default
です。
オールインワンのコントロールプレーンノードとワーカーノードの場合、コンプライアンススキャンはワーカーノードとコントロールプレーンノードで 2 回実行されます。コンプライアンススキャンは、一貫性のないスキャン結果を生成する可能性があります。ScanSetting
オブジェクトで単一のロールのみを定義することにより、一貫性のない結果を回避できます。
手順
以下を実行して
ScanSetting
オブジェクトを検査します。$ oc describe scansettings default -n openshift-compliance
出力例
apiVersion: compliance.openshift.io/v1alpha1 kind: ScanSetting metadata: name: default namespace: openshift-compliance rawResultStorage: pvAccessModes: - ReadWriteOnce 1 rotation: 3 2 size: 1Gi 3 roles: - worker 4 - master 5 scanTolerations: 6 default: - operator: Exists schedule: 0 1 * * * 7
- 1
- コンプライアンス Operator は、スキャンの結果が含まれる永続ボリューム (PV) を作成します。デフォルトで、コンプライアンス Operator はクラスターに設定されるストレージクラスについて何らかの仮定をすることができないため、PV はアクセスモード
ReadWriteOnce
を使用します。さらに、ReadWriteOnce
アクセスモードはほとんどのクラスターで利用できます。スキャン結果を取得する必要がある場合は、ボリュームもバインドするヘルパー Pod を使用して実行できます。ReadWriteOnce
アクセスモードを使用するボリュームは、一度に 1 つの Pod のみがマウントできるため、必ずヘルパー Pod を削除してください。そうでない場合は、コンプライアンス Operator は後続のスキャンのためにボリュームを再利用できません。 - 2
- コンプライアンス Operator は、後続の 3 つのスキャンの結果をボリュームに保持し、古いスキャンはローテーションされます。
- 3
- コンプライアンス Operator はスキャンの結果用に 1 GB のストレージを割り当てます。
- 4 5
- スキャン設定がクラスターノードをスキャンするプロファイルを使用する場合は、これらのノードロールをスキャンします。
- 6
- デフォルトのスキャン設定オブジェクトはすべてのノードもスキャンします。
- 7
- デフォルトのスキャン設定オブジェクトは、毎日 01:00 にスキャンを実行します。
デフォルトのスキャン設定の代わりに、以下の設定を含む
default-auto-apply
を使用できます。apiVersion: compliance.openshift.io/v1alpha1 kind: ScanSetting metadata: name: default-auto-apply namespace: openshift-compliance autoUpdateRemediations: true 1 autoApplyRemediations: true 2 rawResultStorage: pvAccessModes: - ReadWriteOnce rotation: 3 size: 1Gi schedule: 0 1 * * * roles: - worker - master scanTolerations: default: - operator: Exists
デフォルトの
ScanSetting
オブジェクトにバインドし、cis
およびcis-node
プロファイルを使用してクラスターをスキャンするScanSettingBinding
オブジェクトを作成します。以下に例を示します。apiVersion: compliance.openshift.io/v1alpha1 kind: ScanSettingBinding metadata: name: cis-compliance namespace: openshift-compliance profiles: - name: ocp4-cis-node kind: Profile apiGroup: compliance.openshift.io/v1alpha1 - name: ocp4-cis kind: Profile apiGroup: compliance.openshift.io/v1alpha1 settingsRef: name: default kind: ScanSetting apiGroup: compliance.openshift.io/v1alpha1
以下を実行して
ScanSettingBinding
オブジェクトを作成します。$ oc create -f <file-name>.yaml -n openshift-compliance
プロセスのこの時点で、
ScanSettingBinding
オブジェクトは調整され、Binding
およびBound
設定に基づいて調整されます。コンプライアンス Operator はComplianceSuite
オブジェクトおよび関連付けられるComplianceScan
オブジェクトを作成します。以下を実行してコンプライアンススキャンの進捗を確認します。
$ oc get compliancescan -w -n openshift-compliance
スキャンはスキャンフェーズに進み、完了すると最終的に
DONE
フェーズに移行します。ほとんどの場合、スキャンの結果はNON-COMPLIANT
になります。スキャン結果を確認し、クラスターがコンプライアンスに基づくように修復の適用を開始することができます。詳細は、コンプライアンス Operator 修復の管理 について参照してください。
5.4.2. ワーカーノードでの結果サーバー Pod のスケジューリング
結果サーバー Pod は、生の Asset Reporting Format (ARF) スキャン結果を格納する永続ボリューム (PV) をマウントします。nodeSelector
属性および tolerations
属性を使用すると、結果サーバー Pod の場所を設定できます。
これは、コントロールプレーンノードが永続ボリュームをマウントすることを許可されていない環境で役立ちます。
手順
コンプライアンス Operator 用の
ScanSetting
カスタムリソース (CR) を作成します。ScanSetting
CR を定義し、YAML ファイルを保存します (例:rs-workers.yaml
)。apiVersion: compliance.openshift.io/v1alpha1 kind: ScanSetting metadata: name: rs-on-workers namespace: openshift-compliance rawResultStorage: nodeSelector: node-role.kubernetes.io/worker: "" 1 pvAccessModes: - ReadWriteOnce rotation: 3 size: 1Gi tolerations: - operator: Exists 2 roles: - worker - master scanTolerations: - operator: Exists schedule: 0 1 * * *
ScanSetting
CR を作成するには、次のコマンドを実行します。$ oc create -f rs-workers.yaml
検証
ScanSetting
オブジェクトが作成されたことを確認するには、次のコマンドを実行します。$ oc get scansettings rs-on-workers -n openshift-compliance -o yaml
出力例
apiVersion: compliance.openshift.io/v1alpha1 kind: ScanSetting metadata: creationTimestamp: "2021-11-19T19:36:36Z" generation: 1 name: rs-on-workers namespace: openshift-compliance resourceVersion: "48305" uid: 43fdfc5f-15a7-445a-8bbc-0e4a160cd46e rawResultStorage: nodeSelector: node-role.kubernetes.io/worker: "" pvAccessModes: - ReadWriteOnce rotation: 3 size: 1Gi tolerations: - operator: Exists roles: - worker - master scanTolerations: - operator: Exists schedule: 0 1 * * * strictNodeScan: true
5.5. コンプライアンス Operator について
コンプライアンス Operator を使用すると、OpenShift Container Platform 管理者はクラスターの必要なコンプライアンス状態を記述し、存在するギャップやそれらを修復する方法についての概要を提供します。コンプライアンス Operator は、OpenShift Container Platform の Kubernetes API リソースと、クラスターを実行するノードの両方のコンプライアンスを評価します。コンプライアンス Operator は、NIST 認定ツールである OpenSCAP を使用して、コンテンツが提供するセキュリティーポリシーをスキャンし、これを適用します。
コンプライアンス Operator は Red Hat Enterprise Linux CoreOS (RHCOS) デプロイメントでのみ利用できます。
5.5.1. コンプライアンス Operator のプロファイル
コンプライアンス Operator のインストールの一部として利用可能なプロファイルは複数あります。oc get
コマンドを使用して、使用可能なプロファイル、プロファイルの詳細、および特定のルールを表示できます。
利用可能なプロファイルを表示します。
$ oc get -n <namespace> profiles.compliance
次の例では、デフォルトの
openshift-compliance
名前空間のプロファイルを表示します。$ oc get -n openshift-compliance profiles.compliance
出力例
NAME AGE ocp4-cis 32m ocp4-cis-node 32m ocp4-e8 32m ocp4-moderate 32m ocp4-moderate-node 32m ocp4-nerc-cip 32m ocp4-nerc-cip-node 32m ocp4-pci-dss 32m ocp4-pci-dss-node 32m rhcos4-e8 32m rhcos4-moderate 32m rhcos4-nerc-cip 32m
これらのプロファイルは、複数の異なるコンプライアンスベンチマークを表します。各プロファイルには、適用先の製品名がプロファイル名の接頭辞として追加されます。
ocp4-e8
は Essential 8 ベンチマークを OpenShift Container Platform 製品に適用し、rhcos4-e8
は Essential 8 ベンチマークを Red Hat Enterprise Linux CoreOS (RHCOS) 製品に適用します。プロファイルの詳細を表示します。
$ oc get -n <namespace> -oyaml profiles.compliance <profile name>
この例では、
rhcos4-e8
プロファイルの詳細を表示します。$ oc get -n openshift-compliance -oyaml profiles.compliance rhcos4-e8
出力例
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: ... id: xccdf_org.ssgproject.content_profile_e8 kind: Profile metadata: annotations: compliance.openshift.io/image-digest: pb-rhcos426smj compliance.openshift.io/product: redhat_enterprise_linux_coreos_4 compliance.openshift.io/product-type: Node 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 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
必要なプロファイル内のルールを表示します。
$ oc get -n <namespace> -oyaml rules.compliance <rule_name>
この例では、
rhcos4
プロファイルにrhcos4-audit-rules-login-events
ルールを表示します。$ oc get -n openshift-compliance -oyaml rules.compliance rhcos4-audit-rules-login-events
出力例
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-rhcos426smj 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 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 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.6. コンプライアンス Operator の管理
本セクションでは、コンプライアンスコンテンツの更新されたバージョンを使用する方法や、カスタム ProfileBundle
オブジェクトを作成する方法など、セキュリティーコンテンツのライフサイクルについて説明します。
5.6.1. セキュリティーコンテンツの更新
セキュリティーコンテンツは、ProfileBundle
オブジェクトが参照するコンテナーイメージとして提供されます。ProfileBundles
や、ルールまたはプロファイルなどのバンドルから解析されたカスタムリソースへの更新を正確に追跡するには、タグの代わりにダイジェストを使用してコンプライアンスコンテンツを持つコンテナーイメージを識別します。
出力例
apiVersion: compliance.openshift.io/v1alpha1
kind: ProfileBundle
metadata:
name: rhcos4
spec:
contentImage: quay.io/user/ocp4-openscap-content@sha256:a1749f5150b19a9560a5732fe48a89f07bffc79c0832aa8c49ee5504590ae687 1
contentFile: ssg-rhcos4-ds.xml
- 1
- セキュリティーコンテナーイメージ。
それぞれの ProfileBundle
はデプロイメントでサポートされます。コンプライアンス Operator がコンテナーイメージダイジェストが変更されたことを検知すると、デプロイメントは変更を反映し、コンテンツを再び解析するように更新されます。タグの代わりにダイジェストを使用すると、安定した予測可能なプロファイルセットを使用できます。
5.6.2. イメージストリームの使用
contentImage
参照は有効な ImageStreamTag
を参照し、コンプライアンス Operator はコンテンツを自動的に最新の状態に維持します。
さらに、ProfileBundle
オブジェクトは ImageStream
参照を受け入れます。
イメージストリームのサンプル
$ oc get is -n openshift-compliance
出力例
NAME IMAGE REPOSITORY TAGS UPDATED openscap-ocp4-ds image-registry.openshift-image-registry.svc:5000/openshift-compliance/openscap-ocp4-ds latest 32 seconds ago
手順
ルックアップポリシーが local に設定されていることを確認します。
$ oc patch is openscap-ocp4-ds \ -p '{"spec":{"lookupPolicy":{"local":true}}}' \ --type=merge imagestream.image.openshift.io/openscap-ocp4-ds patched -n openshift-compliance
istag
名を取得して、ProfileBundle
のImageStreamTag
の名前を使用します。$ oc get istag -n openshift-compliance
出力例
NAME IMAGE REFERENCE UPDATED openscap-ocp4-ds:latest image-registry.openshift-image-registry.svc:5000/openshift-compliance/openscap-ocp4-ds@sha256:46d7ca9b7055fe56ade818ec3e62882cfcc2d27b9bf0d1cbae9f4b6df2710c96 3 minutes ago
ProfileBundle
を作成します。$ cat << EOF | oc create -f - apiVersion: compliance.openshift.io/v1alpha1 kind: ProfileBundle metadata: name: mybundle spec: contentImage: openscap-ocp4-ds:latest contentFile: ssg-rhcos4-ds.xml EOF
この ProfileBundle
はイメージを追跡し、これに適用される変更 (異なるハッシュを参照するようにタグを更新するなど) は ProfileBundle
にただちに反映されます。
5.6.3. ProfileBundle CR の例
バンドルオブジェクトには、contentImage
が含まれるコンテナーイメージの URL とコンプライアンスコンテンツが含まれるファイルの 2 つの情報が必要です。contentFile
パラメーターはファイルシステムのルートに相対します。ビルトインの rhcos4
ProfileBundle
オブジェクトは以下の例で定義できます。
apiVersion: compliance.openshift.io/v1alpha1 kind: ProfileBundle metadata: name: rhcos4 spec: contentImage: quay.io/complianceascode/ocp4:latest 1 contentFile: ssg-rhcos4-ds.xml 2
コンテンツイメージに使用されるベースイメージには、coreutils
が含まれる必要があります。
5.6.4. 関連情報
- コンプライアンス Operator はネットワークが制限された環境でサポートされています。詳細は、ネットワークが制限された環境での Operator Lifecycle Manager の使用 を参照してください。
5.7. コンプライアンス Operator の調整
コンプライアンス Operator には、追加の設定なしで使用できるプロファイルが同梱されますが、それらは組織のニーズおよび要件を満たすために変更される必要があります。プロファイルを変更するプロセスは、テーラリング と呼ばれます。
コンプライアンス Operator は、TailoredProfile
というプロファイルを簡単に調整できるオブジェクトを提供します。これは、既存のプロファイルを拡張していることを前提とし、ProfileBundle
からのルールおよび値を有効/無効を可能にします。
拡張する必要のあるプロファイルが属する ProfileBundle
の一部として利用できるルールおよび変数のみを使用できます。
5.7.1. 調整されたプロファイルの使用
TailoredProfile
CR は最も一般的なテーラリング操作を有効にする一方で、XCCDF 標準は OpenSCAP プロファイルの調整におけるより多くの柔軟性を提供します。さらに、組織が以前に OpenScap を使用していた場合、既存の XCCDF テーラリングファイルが存在し、これを再利用できる可能性があります。
ComplianceSuite
オブジェクトには、カスタムのテーラリングファイルにポイントできるオプションの TailoringConfigMap
属性が含まれます。TailoringConfigMap
属性の値は設定マップの名前です。これには、tailoring.xml
というキーが含まれる必要があり、このキーの値はテーラリングのコンテンツです。
手順
Red Hat Enterprise Linux CoreOS (RHCOS)
ProfileBundle
の利用可能なルールを参照します。$ oc get rules.compliance -n openshift-compliance -l compliance.openshift.io/profile-bundle=rhcos4
同じ
ProfileBundle
で利用可能な変数を参照します。$ oc get variables.compliance -n openshift-compliance -l compliance.openshift.io/profile-bundle=rhcos4
nist-moderate-modified
という名前の調整されたプロファイルを作成します。調整されたプロファイル
nist-moderate-modified
に追加するルールを選択します。この例では、2 つのルールを無効にし、1 つの値を変更することにより、rhcos4-moderate
プロファイルを拡張します。rationale
値を使用して、これらの変更が加えられた理由を記述します。new-profile-node.yaml
の例apiVersion: compliance.openshift.io/v1alpha1 kind: TailoredProfile metadata: name: nist-moderate-modified spec: extends: rhcos4-moderate description: NIST moderate profile title: My modified NIST moderate profile disableRules: - name: rhcos4-file-permissions-var-log-messages rationale: The file contains logs of error messages in the system - name: rhcos4-account-disable-post-pw-expiration rationale: No need to check this as it comes from the IdP setValues: - name: rhcos4-var-selinux-state rationale: Organizational requirements value: permissive
表5.2 スペック変数の属性 属性 説明 extends
この
TailoredProfile
がビルドされるProfile
オブジェクトの名前。title
人間が判読できる
TailoredProfile
のタイトル。disableRules
名前および理論的根拠のペアの一覧。名前ごとに、無効にするルールオブジェクトの名前を参照します。理論的根拠の値は、人間が判読できるテキストで、ルールが無効になっている理由を記述します。
enableRules
名前および理論的根拠のペアの一覧。名前ごとに、有効にするルールオブジェクトの名前を参照します。理論的根拠の値は、人間が判読できるテキストで、ルールが有効になっている理由を記述します。
description
TailoredProfile
を記述する人間が判読できるテキスト。setValues
名前、理論的根拠、および値のグループ化の一覧。各名前は値セットの名前を参照します。この理論的根拠は、値セットを記述する、人間が判読できるテキストです。この値は実際の設定です。
TailoredProfile
オブジェクトを作成します。$ oc create -n openshift-compliance -f new-profile-node.yaml 1
- 1
TailoredProfile
オブジェクトは、デフォルトのopenshift-compliance
namespace で作成されます。
出力例
tailoredprofile.compliance.openshift.io/nist-moderate-modified created
ScanSettingBinding
オブジェクトを定義して、新しい調整されたプロファイルnist-moderate-modified
をデフォルトのScanSetting
オブジェクトにバインドします。new-scansettingbinding.yaml
の例apiVersion: compliance.openshift.io/v1alpha1 kind: ScanSettingBinding metadata: name: nist-moderate-modified profiles: - apiGroup: compliance.openshift.io/v1alpha1 kind: Profile name: ocp4-moderate - apiGroup: compliance.openshift.io/v1alpha1 kind: TailoredProfile name: nist-moderate-modified settingsRef: apiGroup: compliance.openshift.io/v1alpha1 kind: ScanSetting name: default
ScanSettingBinding
オブジェクトを作成します。$ oc create -n openshift-compliance -f new-scansettingbinding.yaml
出力例
scansettingbinding.compliance.openshift.io/nist-moderate-modified created
5.8. コンプライアンス Operator の未加工の結果の取得
OpenShift Container Platform クラスターのコンプライアンスを証明する際に、監査目的でスキャンの結果を提供する必要がある場合があります。
5.8.1. 永続ボリュームからのコンプライアンス Operator の未加工の結果の取得
手順
コンプライアンス Operator は、未加工の結果を生成し、これを永続ボリュームに保存します。これらの結果は Asset Reporting Format (ARF) で生成されます。
ComplianceSuite
オブジェクトを確認します。$ oc get compliancesuites nist-moderate-modified -o json \ | jq '.status.scanStatuses[].resultsStorage' { "name": "rhcos4-moderate-worker", "namespace": "openshift-compliance" } { "name": "rhcos4-moderate-master", "namespace": "openshift-compliance" }
これは、未加工の結果にアクセスできる永続ボリューム要求 (PVC) を表示します。
結果のいずれかの名前と namespace を使用して、未加工データの場所を確認します。
$ oc get pvc -n openshift-compliance rhcos4-moderate-worker
出力例
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE rhcos4-moderate-worker Bound pvc-548f6cfe-164b-42fe-ba13-a07cfbc77f3a 1Gi RWO gp2 92m
ボリュームをマウントする Pod を起動し、結果をコピーして、未加工の結果をフェッチします。
サンプル Pod
apiVersion: "v1" kind: Pod metadata: name: pv-extract spec: containers: - name: pv-extract-pod image: registry.access.redhat.com/ubi8/ubi command: ["sleep", "3000"] volumeMounts: - mountPath: "/workers-scan-results" name: workers-scan-vol volumes: - name: workers-scan-vol persistentVolumeClaim: claimName: rhcos4-moderate-worker
Pod の実行後に、結果をダウンロードします。
$ oc cp pv-extract:/workers-scan-results .
重要永続ボリュームをマウントする Pod を起動すると、要求は
Bound
として保持されます。使用中のボリュームのストレージクラスのパーミッションがReadWriteOnce
に設定されている場合、ボリュームは一度に 1 つの Pod によってのみマウント可能です。完了したら Pod を削除する必要があります。そうしないと、Operator は Pod をスケジュールし、継続して結果をこの場所に保存し続けることができなくなります。展開が完了した後に、Pod を削除できます。
$ oc delete pod pv-extract
5.9. コンプライアンス Operator の結果と修復の管理
それぞれの ComplianceCheckResult
は、1 つのコンプライアンスルールチェックの結果を表します。ルールを自動的に修復できる場合、ComplianceCheckResult
によって所有される、同じ名前を持つ ComplianceRemediation
オブジェクトが作成されます。修復が要求されない限り、修復は自動的に適用されません。これにより、OpenShift Container Platform の管理者は修復内容を確認し、検証後にのみ修復を適用することができます。
5.9.1. コンプライアンスチェック結果のフィルター
デフォルトで、ComplianceCheckResult
オブジェクトには、チェックのクエリーおよび結果の生成後に次のステップを決定することを可能にする便利なラベルが複数付けられます。
特定のスイートに属するチェックを一覧表示します。
$ oc get compliancecheckresults -l compliance.openshift.io/suite=example-compliancesuite
特定のスキャンに属するチェックを一覧表示します。
$ oc get compliancecheckresults -l compliance.openshift.io/scan=example-compliancescan
すべての ComplianceCheckResult
オブジェクトが ComplianceRemediation
オブジェクトを作成する訳ではありません。自動的に修復できる ComplianceCheckResult
オブジェクトのみになります。ComplianceCheckResult
オブジェクトには、compliance.openshift.io/automated-remediation
ラベルでラベル付けされる場合に関連する修復が含まれます。修復の名前はチェックの名前と同じです。
自動的に修復できる障害のあるチェックをすべて一覧表示します。
$ oc get compliancecheckresults -l 'compliance.openshift.io/check-status=FAIL,compliance.openshift.io/automated-remediation'
手動で修復する必要のある障害のあるチェックをすべて一覧表示します。
$ oc get compliancecheckresults -l 'compliance.openshift.io/check-status=FAIL,!compliance.openshift.io/automated-remediation'
手動による修復の手順は、通常 ComplianceCheckResult
オブジェクトの description
属性に保存されます。
ComplianceCheckResult Status | 説明 |
---|---|
PASS | コンプライアンスチェックが完了し、パスしました。 |
FAIL | コンプライアンスチェックが完了するまで実行され、失敗しました。 |
INFO | コンプライアンスチェックが完了するまで実行され、エラーと見なされるほど深刻ではないものが見つかりました。 |
MANUAL | コンプライアンスチェックには、成功または失敗を自動的に評価する方法がないため、手動でチェックする必要があります。 |
INCONSISTENT | コンプライアンスチェックは、さまざまなソース (通常はクラスターノード) からのさまざまな結果を報告します。 |
ERROR | コンプライアンスチェックは実行されましたが、正しく完了できませんでした。 |
NOT-APPLICABLE | 該当しない、または選択されていないため、コンプライアンスチェックは実行されませんでした。 |
5.9.2. 修復の確認
ComplianceRemediation
オブジェクト、および修復を所有する ComplianceCheckResult
オブジェクトの両方を確認します。ComplianceCheckResult
オブジェクトには、チェック内容やサーバーの強化措置などの人間が判読できる記述、および重大度や関連するセキュリティーコントロールなどの他の metadata
が含まれます。ComplianceRemediation
オブジェクトは、ComplianceCheckResult
に説明されている問題を修正する方法を表します。最初のスキャン後、MissingDependencies
状態の修復を確認します。
以下は、sysctl-net-ipv4-conf-all-accept-redirects
というチェックおよび修復の例です。この例では、spec
および status
のみを表示し、metadata
は省略するように編集されています。
spec: apply: false current: object: apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfig spec: config: ignition: version: 3.1.0 storage: files: - path: /etc/sysctl.d/75-sysctl_net_ipv4_conf_all_accept_redirects.conf mode: 0644 contents: source: data:,net.ipv4.conf.all.accept_redirects%3D0 outdated: {} status: applicationState: NotApplied
修復ペイロードは spec.current
属性に保存されます。ペイロードには Kubernetes オブジェクトを使用することができますが、この修復はノードスキャンによって生成されたため、上記の例の修復ペイロードは MachineConfig
オブジェクトになります。Platform スキャンでは、修復ペイロードは多くの場合 (ConfigMap
や Secret
オブジェクトなど) 異なる種類のオブジェクトになりますが、通常は修復を適用については管理者が判断します。そうでない場合には、コンプライアンス Operator には汎用の Kubernetes オブジェクトを操作するために非常に幅広いパーミッションのセットが必要になるためです。Platform チェックの修復例は、後ほど提供されます。
修復が適用される際に修復内容を正確に確認できるようにするために、MachineConfig
オブジェクトの内容は設定の Ignition オブジェクトを使用します。形式についての詳細は、Ignition 仕様 を参照してください。この例では、spec.config.storage.files[0].path
属性は、この修復によって作成されるファイル (/etc/sysctl.d/75-sysctl_net_ipv4_conf_all_accept_redirects.conf
) を指定し、spec.config.storage.files[0].contents.source
属性はそのファイルの内容を指定します。
ファイルの内容は URL でエンコードされます。
以下の Python スクリプトを使用して、コンテンツを表示します。
$ echo "net.ipv4.conf.all.accept_redirects%3D0" | python3 -c "import sys, urllib.parse; print(urllib.parse.unquote(''.join(sys.stdin.readlines())))"
出力例
net.ipv4.conf.all.accept_redirects=0
5.9.3. カスタマイズされたマシン設定プールを使用するときに修復を適用する
カスタム MachineConfigPool
を作成するときは、MachineConfigPool
にラベルを追加して、KubeletConfig
に存在する machineConfigPoolSelector
がそのラベルを MachineConfigPool
と一致させることができるようにします。
コンプライアンス Operator が修復の適用を終了した後に、MachineConfigPool
オブジェクトが予期せず一時停止を解除できない可能性があるため、KubeletConfig
ファイルでは、protectKernelDefaults:false
を設定しないでください。
手順
ノードを一覧表示します。
$ oc get nodes
出力例
NAME STATUS ROLES AGE VERSION ip-10-0-128-92.us-east-2.compute.internal Ready master 5h21m v1.23.3+d99c04f ip-10-0-158-32.us-east-2.compute.internal Ready worker 5h17m v1.23.3+d99c04f ip-10-0-166-81.us-east-2.compute.internal Ready worker 5h17m v1.23.3+d99c04f ip-10-0-171-170.us-east-2.compute.internal Ready master 5h21m v1.23.3+d99c04f ip-10-0-197-35.us-east-2.compute.internal Ready master 5h22m v1.23.3+d99c04f
ノードにラベルを追加します。
$ oc label node ip-10-0-166-81.us-east-2.compute.internal node-role.kubernetes.io/<machine_config_pool_name>=
出力例
node/ip-10-0-166-81.us-east-2.compute.internal labeled
カスタム
MachineConfigPool
CR を作成します。apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfigPool metadata: name: <machine_config_pool_name> labels: pools.operator.machineconfiguration.openshift.io/<machine_config_pool_name>: '' 1 spec: machineConfigSelector: matchExpressions: - {key: machineconfiguration.openshift.io/role, operator: In, values: [worker,<machine_config_pool_name>]} nodeSelector: matchLabels: node-role.kubernetes.io/<machine_config_pool_name>: ""
- 1
labels
フィールドは、マシン設定プール (MCP) に追加するラベル名を定義します。
MCP が正常に作成されたことを確認します。
$ oc get mcp -w
5.9.4. 修復の適用
ブール値の属性 spec.apply
は、コンプライアンス Operator で修復を適用するかどうかを制御します。属性を true
に設定すると、修復を適用することができます。
$ oc patch complianceremediations/<scan_name>-sysctl-net-ipv4-conf-all-accept-redirects --patch '{"spec":{"apply":true}}' --type=merge
コンプライアンス Operator が適用された修復を処理した後に、status.ApplicationState
属性は Applied に、または正しくない場合には Error に切り替わります。マシン設定の修復が適用されると、その修復と他のすべての適用済みの修復が 75-$scan-name-$suite-name
という名前の MachineConfig
オブジェクトにレンダリングされます。MachineConfig
オブジェクトはその後 Machine Config Operator によってレンダリングされ、最終的に各ノードで実行されるマシン制御デーモンのインスタンスによってマシン設定プールのすべてのノードに適用されます。
Machine Config Operator が新規 MachineConfig
オブジェクトをプール内のノードに適用すると、そのプールに属するすべてのノードが再起動されることに注意してください。これは、それぞれが複合の 75-$scan-name-$suite-name
MachineConfig
オブジェクトを再度レンダリングする、複数の修復を適用する際に不都合が生じる可能性があります。修復をすぐに適用しないようにするには、MachineConfigPool
オブジェクトの .spec.paused
属性を true
に設定してマシン設定プールを一時停止できます。
コンプライアンス Operator は修復を自動的に適用できます。ScanSetting
の最上位のオブジェクトに autoApplyRemediations: true
を設定します。
修復の自動敵に適用するかどうかについては、慎重に考慮する必要があります。
5.9.5. プラットフォームチェックの手動による修復
通常、プラットフォームスキャンをチェックする場合、以下の 2 つの理由のために管理者が手動で修復する必要があります。
- 設定する必要のある値は、常に自動的に判別できる訳ではありません。チェックのいずれかで許可されたレジストリーの一覧が指定されることが必要になりますが、スキャナー側が組織が許可する必要のあるレジストリーを認識する方法はありません。
-
異なるチェックで異なる API オブジェクトが変更されるため、クラスター内のオブジェクトを変更するために自動化された修復で
root
またはスーパーユーザーアクセスを所有することが要求されますが、これは推奨されていません。
手順
以下の例では、
ocp4-ocp-allowed-registries-for-import
ルールを使用します。これはデフォルトの OpenShift Container Platform のインストール時に失敗します。ルールoc get rule.compliance/ocp4-ocp-allowed-registries-for-import -oyaml
を検査します。このルールは、allowedRegistriesForImport
属性を設定して、ユーザーのイメージのインポートを許可するレジストリーを制限します。さらに、ルールの warning 属性はチェックされた API オブジェクトを表示するため、これを変更し、問題を修復できます。$ oc edit image.config.openshift.io/cluster
出力例
apiVersion: config.openshift.io/v1 kind: Image metadata: annotations: release.openshift.io/create-only: "true" creationTimestamp: "2020-09-10T10:12:54Z" generation: 2 name: cluster resourceVersion: "363096" selfLink: /apis/config.openshift.io/v1/images/cluster uid: 2dcb614e-2f8a-4a23-ba9a-8e33cd0ff77e spec: allowedRegistriesForImport: - domainName: registry.redhat.io status: externalRegistryHostnames: - default-route-openshift-image-registry.apps.user-cluster-09-10-12-07.devcluster.openshift.com internalRegistryHostname: image-registry.openshift-image-registry.svc:5000
スキャンを再実行します。
$ oc annotate compliancescans/<scan_name> compliance.openshift.io/rescan=
5.9.6. 修復の更新
新しいバージョンのコンプライアンスコンテンツが使用されると、以前のバージョンとは異なる新しいバージョンの修復が提供される可能性があります。コンプライアンス Operator は、適用される修復の以前のバージョンを保持します。OpenShift Container Platform の管理者は、確認し、適用する新規バージョンについても通知されます。以前に適用されたものの、更新された ComplianceRemediation オブジェクトはそのステータスを Outdated に変更します。古いオブジェクトには簡単に検索できるようにラベルが付けられます。
以前に適用された修復内容は ComplianceRemediation
オブジェクトの spec.outdated
属性に保存され、新規に更新された内容は spec.current
属性に保存されます。コンテンツを新しいバージョンに更新した後に、管理者は修復を確認する必要があります。spec.outdated
属性が存在する限り、これは結果として作成される MachineConfig
オブジェクトをレンダリングするために使用されます。spec.outdated
属性が削除された後に、コンプライアンス Operator は結果として生成される MachineConfig
オブジェクトを再度レンダリングし、これにより Operator は設定をノードにプッシュします。
手順
古い修復について検索します。
$ oc get complianceremediations -lcomplianceoperator.openshift.io/outdated-remediation=
出力例
NAME STATE workers-scan-no-empty-passwords Outdated
現在適用されている修復は
Outdated
属性に保存され、新規の、適用されていない修復はCurrent
属性に保存されます。新規バージョンに問題がなれば、Outdated
フィールドを削除します。更新された内容を保持する必要がある場合には、Current
およびOutdated
属性を削除します。修復の新しいバージョンを適用します。
$ oc patch complianceremediations workers-scan-no-empty-passwords --type json -p '[{"op":"remove", "path":/spec/outdated}]'
修復の状態は、
Outdated
からApplied
に切り替わります。$ oc get complianceremediations workers-scan-no-empty-passwords
出力例
NAME STATE workers-scan-no-empty-passwords Applied
- ノードは新規の修復バージョンを適用し、再起動します。
5.9.7. 修復の適用解除
以前に適用された修復を適用解除することが必要になる場合があります。
手順
apply
フラグをfalse
に設定します。$ oc patch complianceremediations/<scan_name>-sysctl-net-ipv4-conf-all-accept-redirects -p '{"spec":{"apply":false}}' --type=merge
修復ステータスは
NotApplied
に変更され、複合のMachineConfig
オブジェクトは修復を含まないように再度レンダリングされます。重要修復を含む影響を受けるすべてのノードが再起動されます。
5.9.8. KubeletConfig 修復の削除
KubeletConfig
の修正は、ノードレベルのプロファイルに含まれています。KubeletConfig 修復を削除するには、KubeletConfig
オブジェクトから手動で削除する必要があります。この例は、one-rule-tp-node-master-kubelet-eviction-thresholds-set-hard-imagefs-available
修正のコンプライアンスチェックを削除する方法を示しています。
手順
one-rule-tp-node-master-kubelet-eviction-thresholds-set-hard-imagefs-available
修復のscan-name
およびコンプライアンスチェックを見つけます。$ oc get remediation one-rule-tp-node-master-kubelet-eviction-thresholds-set-hard-imagefs-available -o yaml
出力例
apiVersion: compliance.openshift.io/v1alpha1 kind: ComplianceRemediation metadata: annotations: compliance.openshift.io/xccdf-value-used: var-kubelet-evictionhard-imagefs-available creationTimestamp: "2022-01-05T19:52:27Z" generation: 1 labels: compliance.openshift.io/scan-name: one-rule-tp-node-master 1 compliance.openshift.io/suite: one-rule-ssb-node name: one-rule-tp-node-master-kubelet-eviction-thresholds-set-hard-imagefs-available namespace: openshift-compliance ownerReferences: - apiVersion: compliance.openshift.io/v1alpha1 blockOwnerDeletion: true controller: true kind: ComplianceCheckResult name: one-rule-tp-node-master-kubelet-eviction-thresholds-set-hard-imagefs-available uid: fe8e1577-9060-4c59-95b2-3e2c51709adc resourceVersion: "84820" uid: 5339d21a-24d7-40cb-84d2-7a2ebb015355 spec: apply: true current: object: apiVersion: machineconfiguration.openshift.io/v1 kind: KubeletConfig spec: kubeletConfig: evictionHard: imagefs.available: 10% 2 outdated: {} type: Configuration status: applicationState: Applied
注記修復によって
evictionHard
kubelet 設定が呼び出される場合は、すべてのevictionHard
パラメーター (memory.available
、nodefs.available
、nodefs.inodesFree
、imagefs.available
、およびimagefs.inodesFree
) を指定する必要があります。すべてのパラメーターを指定しないと、指定したパラメーターのみが適用され、修正が正しく機能しません。修復を削除します。
修復オブジェクトの
apply
を false に設定します。$ oc patch complianceremediations/one-rule-tp-node-master-kubelet-eviction-thresholds-set-hard-imagefs-available -p '{"spec":{"apply":false}}' --type=merge
scan-name
を使用して、修復が適用されたKubeletConfig
オブジェクトを見つけます。$ oc get kubeletconfig --selector compliance.openshift.io/scan-name=one-rule-tp-node-master
出力例
NAME AGE compliance-operator-kubelet-master 2m34s
KubeletConfig
オブジェクトから修復imagefs.available: 10%
を手動で削除します。$ oc edit KubeletConfig compliance-operator-kubelet-master
重要修復を含む影響を受けるすべてのノードが再起動されます。
また、修正を自動適用する調整済みプロファイルのスケジュールされたスキャンからルールを除外する必要があります。除外しない場合、修正は次のスケジュールされたスキャン中に再適用されます。
5.9.9. 一貫性のない ComplianceScan
ScanSetting
オブジェクトは、ScanSetting
または ScanSettingBinding
オブジェクトから生成されるコンプライアンススキャンがスキャンするノードロールを一覧表示します。通常、各ノードのロールはマシン設定プールにマップされます。
マシン設定プールのすべてのマシンが同一であり、プールのノードからのすべてのスキャン結果が同一であることが予想されます。
一部の結果が他とは異なる場合、コンプライアンス Operator は一部のノードが INCONSISTENT
として報告される ComplianceCheckResult
オブジェクトにフラグを付けます。すべての ComplianceCheckResult
オブジェクトには、compliance.openshift.io/inconsistent-check
のラベルも付けられます。
プール内のマシン数は非常に大きくなる可能性があるため、コンプライアンス Operator は最も一般的な状態を検索し、一般的な状態とは異なるノードを一覧表示しようとします。最も一般的な状態は compliance.openshift.io/most-common-status
アノテーションに保存され、アノテーション compliance.openshift.io/inconsistent-source
には、最も一般的なステータスとは異なるチェックステータスの hostname:status
のペアが含まれます。共通状態が見つからない場合、すべての hostname:status
ペアが compliance.openshift.io/inconsistent-source
アノテーションに一覧表示されます。
可能な場合は、修復が依然として作成され、クラスターが準拠したステータスに収束できるようにします。ただし、これが常に実行可能な訳ではなく、ノード間の差異の修正は手作業で行う必要があります。スキャンに compliance.openshift.io/rescan=
オプションのアノテーションを付けて一貫性のある結果を取得するために、コンプライアンススキャンを再実行する必要があります。
$ oc annotate compliancescans/<scan_name> compliance.openshift.io/rescan=
5.9.10. 関連情報
5.10. 高度なコンプライアンス Operator タスクの実行
コンプライアンス Operator には、デバッグや既存のツールとの統合を目的とする上級ユーザー向けのオプションが含まれます。
5.10.1. ComplianceSuite オブジェクトおよび ComplianceScan オブジェクトの直接使用
ユーザーは ScanSetting
および ScanSettingBinding
オブジェクトを利用してスイートおよびスキャンを定義することが推奨されますが、 ComplianceSuite
オブジェクトを直接定義する有効なユースケースもあります。
-
スキャンする単一ルールのみを指定する。これは、デバッグモードが非常に詳細な情報を取得する可能性があるため、
debug: true
属性を使用してデバッグする際に役立ちます。これにより、OpenSCAP スキャナーの詳細度が上がります。テストを 1 つのルールに制限すると、デバッグ情報の量を減らすことができます。 - カスタム nodeSelector を指定する。修復を適用可能にするには、nodeSelector はプールと一致する必要があります。
- テーラリングファイルでスキャンをカスタム設定マップをポイントする。
- テストまたは開発目的の場合で、バンドルからのプロファイルの解析に伴うオーバーヘッドが不要な場合。
以下の例は、単一のルールのみでワーカーマシンをスキャンする ComplianceSuite
を示しています。
apiVersion: compliance.openshift.io/v1alpha1 kind: ComplianceSuite metadata: name: workers-compliancesuite spec: scans: - name: workers-scan profile: xccdf_org.ssgproject.content_profile_moderate content: ssg-rhcos4-ds.xml contentImage: quay.io/complianceascode/ocp4:latest debug: true rule: xccdf_org.ssgproject.content_rule_no_direct_root_logins nodeSelector: node-role.kubernetes.io/worker: ""
上記の ComplianceSuite
オブジェクトおよび ComplianceScan
オブジェクトは、OpenSCAP が想定する形式で複数の属性を指定します。
プロファイル、コンテンツ、またはルールの値を見つけるには、最初に ScanSetting
および ScanSettingBinding
から同様の Suite を作成して開始するか、またはルールやプロファイルなどの ProfileBundle
オブジェクトから解析されたオブジェクトを検査することができます。これらのオブジェクトには、ComplianceSuite
から参照するために使用できる xccdf_org
識別子が含まれます。
5.10.2. 未加工の調整済みプロファイルの使用
TailoredProfile
CR は最も一般的なテーラリング操作を有効にする一方で、XCCDF 標準は OpenSCAP プロファイルの調整におけるより多くの柔軟性を提供します。さらに、組織が以前に OpenScap を使用していた場合、既存の XCCDF テーラリングファイルが存在し、これを再利用できる可能性があります。
ComplianceSuite
オブジェクトには、カスタムのテーラリングファイルにポイントできるオプションの TailoringConfigMap
属性が含まれます。TailoringConfigMap
属性の値は設定マップの名前です。これには、tailoring.xml
というキーが含まれる必要があり、このキーの値はテーラリングのコンテンツです。
手順
ファイルから
ConfigMap
オブジェクトを作成します。$ oc create configmap <scan_name> --from-file=tailoring.xml=/path/to/the/tailoringFile.xml
スイートに属するスキャンでテーラリングファイルを参照します。
apiVersion: compliance.openshift.io/v1alpha1 kind: ComplianceSuite metadata: name: workers-compliancesuite spec: debug: true scans: - name: workers-scan profile: xccdf_org.ssgproject.content_profile_moderate content: ssg-rhcos4-ds.xml contentImage: quay.io/complianceascode/ocp4:latest debug: true tailoringConfigMap: name: <scan_name> nodeSelector: node-role.kubernetes.io/worker: ""
5.10.3. 再スキャンの実行
通常、毎週月曜日または日次など、定義されたスケジュールでスキャンを再実行する必要がある場合があります。また、ノードの問題を修正した後にスキャンを 1 回再実行することは役に立ちます。単一スキャンを実行するには、スキャンに compliance.openshift.io/rescan=
オプションでアノテーションを付けます。
$ oc annotate compliancescans/<scan_name> compliance.openshift.io/rescan=
再スキャンにより、rhcos-moderate
プロファイルの 4 つの追加 mc
が生成されます。
$ oc get mc
出力例
75-worker-scan-chronyd-or-ntpd-specify-remote-server 75-worker-scan-configure-usbguard-auditbackend 75-worker-scan-service-usbguard-enabled 75-worker-scan-usbguard-allow-hid-and-hub
スキャン設定の default-auto-apply
ラベルが適用されると、修復は自動的に適用され、古い修復が自動的に更新されます。依存関係により適用されなかった修復や、古くなった修復がある場合には、再スキャンにより修復が適用され、再起動がトリガーされる可能性があります。MachineConfig
オブジェクトを使用する修復のみが再起動をトリガーします。適用する更新または依存関係がない場合は、再起動は発生しません。
5.10.4. 結果についてのカスタムストレージサイズの設定
ComplianceCheckResult
などのカスタムリソースは、スキャンされたすべてのノード間での単一チェックの集計された結果を表しますが、スキャナーによって生成される未加工の結果を確認することが役に立つ場合もあります。未加工の結果は ARF 形式で生成され、サイズが大きくなる可能性がありますが (ノードあたり数十メガバイト)、それらを etcd
のキーと値のストアでサポートされる Kubernetes リソースに保存することは実際的ではありません。すべてのスキャンは、1GB のサイズにデフォルト設定される永続ボリューム (PV) を作成します。環境によっては、PV サイズを適宜増やす必要がある場合があります。これは、ScanSetting
および ComplianceScan
リソースの両方に公開される rawResultStorage.size
属性を使用して実行されます。
関連するパラメーターは rawResultStorage.rotation
であり、これは古いスキャンのローテーションが行われる前に保持されるスキャンの数を制御します。デフォルト値は 3 です。ローテーションポリシーを 0 に設定するとローテーションは無効になります。デフォルトのローテーションポリシーと、未加工の ARF スキャンレポートにつき 100 MB を見積もり、お使いの環境に適した PV サイズを計算できます。
5.10.4.1. カスタム結果ストレージ値の使用
OpenShift Container Platform は各種のパブリッククラウドまたはベアメタルにデプロイできるので、コンプライアンス Operator は利用可能なストレージ設定を判別できません。デフォルトで、コンプライアンス Operator はクラスターのデフォルトのストレージクラスを使用して結果を保存するために PV の作成を試行しますが、カスタムストレージクラスは rawResultStorage.StorageClassName
属性を使用して設定できます。
クラスターがデフォルトのストレージクラスを指定しない場合、この属性を設定する必要があります。
標準ストレージクラスを使用するように ScanSetting
カスタムリソースを設定し、サイズが 10GB の永続ボリュームを作成し、最後の 10 件の結果を保持します。
ScanSetting
CR の例
apiVersion: compliance.openshift.io/v1alpha1 kind: ScanSetting metadata: name: default namespace: openshift-compliance rawResultStorage: storageClassName: standard rotation: 10 size: 10Gi roles: - worker - master scanTolerations: - effect: NoSchedule key: node-role.kubernetes.io/master operator: Exists schedule: '0 1 * * *'
5.10.5. スイートスキャンによって生成される修復の適用
ComplianceSuite
オブジェクトで autoApplyRemediations
ブール値パラメーターを使用することもできますが、オブジェクトに compliance.openshift.io/apply-remediations
のアノテーションを付けることもできます。これにより、Operator は作成されるすべての修復を適用できます。
手順
-
以下を実行して、
compliance.openshift.io/apply-remediations
アノテーションを適用します。
$ oc annotate compliancesuites/<suite-_name> compliance.openshift.io/apply-remediations=
5.10.6. 修復の自動更新
新しいコンテンツを含むスキャンは、修復に OUTDATED
というマークを付ける可能性があります。管理者は、compliance.openshift.io/remove-outdated
アノテーションを適用して新規の修復を適用し、古い修復を削除できます。
手順
-
compliance.openshift.io/remove-outdated
アノテーションを適用します。
$ oc annotate compliancesuites/<suite_name> compliance.openshift.io/remove-outdated=
または、ScanSetting
または ComplianceSuite
オブジェクトに autoUpdateRemediations
フラグを設定し、修復を自動的に更新します。
5.11. コンプライアンス Operator のトラブルシューティング
このセクションでは、コンプライアンス Operator のトラブルシューティングの方法について説明します。この情報は、問題を診断したり、バグレポートに情報を提供したりする際に役立ちます。一般的なヒントには、以下が含まれます。
コンプライアンス Operator は、重要なことが発生すると Kubernetes イベントを生成します。コマンドを使用して、クラスター内のすべてのイベントを表示できます。
$ oc get events -n openshift-compliance
または、コマンドを使用してスキャンなどのオブジェクトのイベントを表示します。
$ oc describe compliancescan/<scan_name>
コンプライアンス Operator は複数のコントローラーで設定されており、API オブジェクトごとに約 1 つのコントローラーで設定されます。問題のある API オブジェクトに対応するコントローラーのみをフィルターすることが役に立つ場合があります。
ComplianceRemediation
を適用できない場合、remediationctrl
コントローラーのメッセージを表示します。jq
で解析することにより、単一のコントローラーからのメッセージをフィルターできます。$ oc logs compliance-operator-775d7bddbd-gj58f | jq -c 'select(.logger == "profilebundlectrl")'
タイムスタンプについては、UTC の UNIX エポックからの経過時間で秒単位でログに記録されます。人間が判読可能な日付に変換するには、
date -d @timestamp --utc
を使用します。以下は例になります。$ date -d @1596184628.955853 --utc
-
数多くのカスタムリソースで、最も重要な
ComplianceSuite
およびScanSetting
でdebug
オプションを設定できます。このオプションを有効にすると、OpenSCAP スキャナー Pod や他のヘルパー Pod の詳細度が上がります。 -
単一ルールの合否が予期せずに出される場合、そのルールのみを使用して単一スキャンまたはスイートを実行し、対応する
ComplianceCheckResult
オブジェクトからルール ID を見つけ、それをScan
CR のrule
属性として使用することが役に立つ場合があります。次に、debug
オプションが有効になると、スキャナー Pod のscanner
コンテナーログに未加工の OpenSCAP ログが表示されます。
5.11.1. スキャンの仕組み
以下のセクションでは、コンプライアンス Operator スキャンのコンポーネントおよびステージについて説明します。
5.11.1.1. コンプライアンスのソース
コンプライアンスコンテンツは、ProfileBundle
オブジェクトから生成される Profile
オブジェクトに保存されます。コンプライアンス Operator は、ProfileBundle
をクラスター用とクラスターノード用に作成します。
$ oc get profilebundle.compliance
$ oc get profile.compliance
ProfileBundle
オブジェクトは、 Bundle
の名前でラベルが付けられたデプロイメントで処理されます。Bundle
で問題のトラブルシューティングを行うには、デプロイメントを見つけ、デプロイメントで Pod のログを表示できます。
$ oc logs -lprofile-bundle=ocp4 -c profileparser
$ oc get deployments,pods -lprofile-bundle=ocp4
$ oc logs pods/<pod-name>
$ oc describe pod/<pod-name> -c profileparser
5.11.1.2. ScanSetting および ScanSettingBinding のライフサイクルおよびデバッグ
有効なコンプライアンスコンテンツソースを使用して、高レベルの ScanSetting
および ScanSettingBinding
オブジェクトを、ComplianceSuite
および ComplianceScan
オブジェクトを生成するために使用できます。
apiVersion: compliance.openshift.io/v1alpha1 kind: ScanSetting metadata: name: my-companys-constraints debug: true # For each role, a separate scan will be created pointing # to a node-role specified in roles roles: - worker --- apiVersion: compliance.openshift.io/v1alpha1 kind: ScanSettingBinding metadata: name: my-companys-compliance-requirements profiles: # Node checks - name: rhcos4-e8 kind: Profile apiGroup: compliance.openshift.io/v1alpha1 # Cluster checks - name: ocp4-e8 kind: Profile apiGroup: compliance.openshift.io/v1alpha1 settingsRef: name: my-companys-constraints kind: ScanSetting apiGroup: compliance.openshift.io/v1alpha1
ScanSetting
および ScanSettingBinding
オブジェクトはどちらも、 logger=scansettingbindingctrl
のタグの付けられた同じコントローラーで処理されます。これらのオブジェクトにはステータスがありません。問題はイベントの形式で通信されます。
Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal SuiteCreated 9m52s scansettingbindingctrl ComplianceSuite openshift-compliance/my-companys-compliance-requirements created
今回のリリースにより、ComplianceSuite
オブジェクトが作成されました。フローは新規に作成された ComplianceSuite
を継続して調整します。
5.11.1.3. ComplianceSuite カスタムリソースのライフサイクルおよびデバッグ
ComplianceSuite
CR は ComplianceScan
CR に関連したラッパーです。ComplianceSuite
CR は、 logger=suitectrl
のタグが付けられたコントローラーによって処理されます。このコントローラーは、スイートからのスキャンの作成を処理し、個別のスキャンのステータスを調整し、これを単一の Suite ステータスに集約します。スイートが定期的に実行するよう設定されている場合、suitectrl
は、初回の実行後にスキャンをスイートで再実行する CronJob
CR の作成にも対応します。
$ oc get cronjobs
出力例
NAME SCHEDULE SUSPEND ACTIVE LAST SCHEDULE AGE <cron_name> 0 1 * * * False 0 <none> 151m
最も重要な問題について、イベントが生成されます。oc describe compliancesuites/<name>
を使用してそれらを表示します。Suite
オブジェクトには、 Status
サブリソースも含まれており、これはこのスイートに属する Scan
オブジェクトが Status
サブリソースを更新すると更新されます。予想されるすべてのスキャンが作成されると、コントローラーがスキャンコントローラーに渡されます。
5.11.1.4. ComplianceScan カスタムリソースのライフサイクルおよびデバッグ
ComplianceScan
CR は scanctrl
コントローラーによって処理されます。これは、実際のスキャンとスキャン結果が作成される場所でもあります。それぞれのスキャンは複数のフェーズを経由します。
5.11.1.4.1. Pending (保留) フェーズ
このフェーズでは、スキャンがその正確性について検証されます。ストレージサイズなどの一部のパラメーターが無効な場合、スキャンは ERROR 結果と共に DONE に移行します。それ以外の場合は、Launching (起動) フェーズに進みます。
5.11.1.4.2. Launching (起動) フェーズ
このフェーズでは、いくつかの設定マップにスキャナー Pod の環境またはスキャナー Pod が評価するスクリプトが直接含まれます。設定マップを一覧表示します。
$ oc get cm -lcompliance.openshift.io/scan-name=rhcos4-e8-worker,complianceoperator.openshift.io/scan-script=
これらの設定マップはスキャナー Pod によって使用されます。スキャナーの動作を変更したり、スキャナーのデバッグレベルを変更したり、未加工の結果を出力したりする必要がある場合は、1 つの方法として設定マップを変更することができます。その後、未加工の ARF の結果を保存するために永続ボリューム要求 (PVC) がスキャンごとに作成されます。
$ oc get pvc -lcompliance.openshift.io/scan-name=<scan_name>
PVC はスキャンごとの ResultServer
デプロイメントでマウントされます。ResultServer
は、個別のスキャナー Pod が完全な ARF 結果をアップロードする単純な HTTP サーバーです。各サーバーは、異なるノードで実行できます。完全な ARF の結果のサイズは非常に大きくなる可能性があり、複数のノードから同時にマウントできるボリュームを作成することができると想定することはできません。スキャンが終了した後に、ResultServer
デプロイメントはスケールダウンされます。未加工の結果のある PVC は別のカスタム Pod からマウントでき、結果はフェッチしたり、検査したりできます。スキャナー Pod と ResultServer
間のトラフィックは相互 TLS プロトコルで保護されます。
最後に、スキャナー Pod はこのフェーズで起動します。Platform
スキャンインスタンスの 1 つのスキャナー Pod と、node
スキャンインスタンスの一致するノードごとに 1 つのスキャナー Pod です。ノードごとの Pod にはノード名のラベルが付けられます。それぞれの Pod には、常に ComplianceScan
という名前のラベルが付けられます。
$ oc get pods -lcompliance.openshift.io/scan-name=rhcos4-e8-worker,workload=scanner --show-labels
出力例
NAME READY STATUS RESTARTS AGE LABELS rhcos4-e8-worker-ip-10-0-169-90.eu-north-1.compute.internal-pod 0/2 Completed 0 39m compliance.openshift.io/scan-name=rhcos4-e8-worker,targetNode=ip-10-0-169-90.eu-north-1.compute.internal,workload=scanner At this point, the scan proceeds to the Running phase.
5.11.1.4.3. Running (実行) フェーズ
実行フェーズは、スキャナー Pod の完了後に開始します。以下の用語およびプロセスは実行フェーズで使用されます。
-
init container:
content-container
という 1 つの init コンテナーがあります。これは、contentImage コンテナーを実行し、contentFile を、この Pod の他のコンテナーで共有される/content
ディレクトリーにコピーします。 -
scanner: このコンテナーはスキャンを実行します。ノードのスキャンの場合には、コンテナーはノードファイルシステムを
/host
としてマウントし、init コンテナーによって配信されるコンテンツをマウントします。また、コンテナーは Launching (起動) フェーズで作成されるentrypoint
ConfigMap
をマウントし、これを実行します。エントリーポイントConfigMap
のデフォルトスクリプトは OpenSCAP を実行し、結果ファイルを Pod のコンテナー間で共有される/results
ディレクトリーに保存します。この Pod のログを表示して、OpenSCAP スキャナーがチェックした内容を判別できます。より詳細な出力は、debug
フラグを使用して表示できます。 logcollector: logcollector コンテナーは、スキャナーコンテナーが終了するまで待機します。その後、これは
ConfigMap
として完全な ARF 結果をResultServer
にアップロードし、スキャン結果および OpenSCAP 結果コードと共に XCCDF 結果を個別にアップロードします。これらの結果の設定マップには、スキャン名 (compliance.openshift.io/scan-name=<scan_name>
) のラベルが付けられます。$ oc describe cm/rhcos4-e8-worker-ip-10-0-169-90.eu-north-1.compute.internal-pod
出力例
Name: rhcos4-e8-worker-ip-10-0-169-90.eu-north-1.compute.internal-pod Namespace: openshift-compliance Labels: compliance.openshift.io/scan-name-scan=rhcos4-e8-worker complianceoperator.openshift.io/scan-result= Annotations: compliance-remediations/processed: compliance.openshift.io/scan-error-msg: compliance.openshift.io/scan-result: NON-COMPLIANT OpenSCAP-scan-result/node: ip-10-0-169-90.eu-north-1.compute.internal Data ==== exit-code: ---- 2 results: ---- <?xml version="1.0" encoding="UTF-8"?> ...
Platform
スキャンのスキャナー Pod も同様ですが、以下の点で異なります。
-
api-resource-collector
という追加の init コンテナーがあります。これは content-container init、コンテナーで提供される OpenSCAP コンテンツを読み取り、コンテンツで確認する必要のある API リソースを判別し、それらの API リソースをscanner
コンテナーが読み取りを行う共有ディレクトリーに保存します。 -
scanner
コンテナーは、ホストファイルシステムをマウントする必要はありません。
スキャナー Pod が実行されると、スキャンは Aggregating (集計) フェーズに移行します。
5.11.1.4.4. Aggregating (集計) フェーズ
Aggregating (集計) フェーズでは、スキャンコントローラーがアグリゲーター Pod と呼ばれる別の Pod を起動します。その目的は、結果の ConfigMap
オブジェクトを取り、結果を読み取り、それぞれのチェックの結果について対応する Kubernetes オブジェクトを作成することにあります。チェックの失敗を自動的に修復できる場合は、 ComplianceRemediation
オブジェクトが作成されます。チェックと修復についての人間が判読できるメタデータを提供するために、アグリゲーター Pod は init コンテナーを使用して OpenSCAP コンテンツもマウントします。
設定マップがアグリゲーター Pod によって処理される場合、これには compliance-remediations/processed
ラベルでラベルが付けられます。このフェーズの結果は ComplianceCheckResult
オブジェクトになります。
$ oc get compliancecheckresults -lcompliance.openshift.io/scan-name=rhcos4-e8-worker
出力例
NAME STATUS SEVERITY rhcos4-e8-worker-accounts-no-uid-except-zero PASS high rhcos4-e8-worker-audit-rules-dac-modification-chmod FAIL medium
ComplianceRemediation
オブジェクト:
$ oc get complianceremediations -lcompliance.openshift.io/scan-name=rhcos4-e8-worker
出力例
NAME STATE rhcos4-e8-worker-audit-rules-dac-modification-chmod NotApplied rhcos4-e8-worker-audit-rules-dac-modification-chown NotApplied rhcos4-e8-worker-audit-rules-execution-chcon NotApplied rhcos4-e8-worker-audit-rules-execution-restorecon NotApplied rhcos4-e8-worker-audit-rules-execution-semanage NotApplied rhcos4-e8-worker-audit-rules-execution-setfiles NotApplied
これらの CR が作成されると、アグリゲーター Pod は終了し、スキャンは Done (終了) フェーズに移行します。
5.11.1.4.5. Done (終了) フェーズ
最終のスキャンフェーズでは、必要な場合にスキャンリソースがクリーンアップされ、ResultServer
デプロイメントは (スキャンが 1 回限りの場合) スケールダウンされるか、または (スキャンが継続される場合) 削除されます。次回のスキャンインスタンスではデプロイメントを再作成します。
また、Done (終了) フェーズでは、スキャンにアノテーションを付けてスキャンの再実行をトリガーすることもできます。
$ oc annotate compliancescans/<scan_name> compliance.openshift.io/rescan=
スキャンが Done (終了) フェーズに到達した後に、修復が autoApplyRemediations: true
を指定して自動的に適用されるように設定されていない限り、自動的に実行されることは何もありません。OpenShift Container Platform 管理者は、修復を確認し、必要に応じてそれらを適用できるようになりました。修復が自動的に適用されるように設定されている場合、ComplianceSuite
コントローラーが Done (終了) フェーズで引き継ぎ、マシン設定プールをスキャンがマップされるポイントで一時停止し、すべての修復を 1 回で適用します。修復が適用されると、ComplianceRemediation
コントローラーが引き継ぎます。
5.11.1.5. ComplianceRemediation コントローラーのライフサイクルおよびデバッグ
サンプルスキャンは特定の結果を報告します。修復の 1 つを有効にするには、apply
属性を true
に切り替えます。
$ oc patch complianceremediations/rhcos4-e8-worker-audit-rules-dac-modification-chmod --patch '{"spec":{"apply":true}}' --type=merge
ComplianceRemediation
コントローラー (logger=remediationctrl
) は変更されたオブジェクトを調整します。調整の結果として、調整される修復オブジェクトのステータスが変更されますが、適用されたすべての修復が含まれる、レンダリングされるスイートごとの MachineConfig
オブジェクトも変更されます。
MachineConfig
オブジェトは常に 75-
で開始し、スキャンとスィートに基づいて名前が付けられます。
$ oc get mc | grep 75-
出力例
75-rhcos4-e8-worker-my-companys-compliance-requirements 2.2.0 2m46s
mc
を現在設定している修復はマシン設定のアノテーションに一覧表示されます。
$ oc describe mc/75-rhcos4-e8-worker-my-companys-compliance-requirements
出力例
Name: 75-rhcos4-e8-worker-my-companys-compliance-requirements Labels: machineconfiguration.openshift.io/role=worker Annotations: remediation/rhcos4-e8-worker-audit-rules-dac-modification-chmod:
ComplianceRemediation
コントローラーのアルゴリズムは以下のようになります。
- 現在適用されているすべての修復は初期の修復セットに読み込まれます。
- 調整された修復が適用されることが予想される場合、それはセットに追加されます。
-
MachineConfig
オブジェクトはセットからレンダリングされ、セット内の修復の名前でアノテーションが付けられます。セットが空の場合 (最後の修復は適用されない)、レンダリングされるMachineConfig
オブジェクトは削除されます。 - レンダリングされたマシン設定がクラスターにすでに適用されているものとは異なる場合にのみ、適用される MC は更新されます (または作成されるか、削除されます)。
-
MachineConfig
オブジェクトの作成または変更により、machineconfiguration.openshift.io/role
ラベルに一致するノードの再起動がトリガーされます。詳細は、Machine Config Operator のドキュメントを参照してください。
修復ループは、レンダリングされたマシン設定が更新され (必要な場合)、調整された修復オブジェクトのステータスが更新されると終了します。この場合、修復を適用すると再起動がトリガーされます。再起動後、スキャンにアノテーションを付け、再度実行します。
$ oc annotate compliancescans/<scan_name> compliance.openshift.io/rescan=
スキャンが実行され、終了します。渡される修復の有無を確認します。
$ oc get compliancecheckresults/rhcos4-e8-worker-audit-rules-dac-modification-chmod
出力例
NAME STATUS SEVERITY rhcos4-e8-worker-audit-rules-dac-modification-chmod PASS medium
5.11.1.6. 役に立つラベル
コンプライアンス Operator によって起動する各 Pod には、それが属するスキャンおよびその機能にとくに関連するラベルが付けられます。スキャン ID には compliance.openshift.io/scan-name
ラベルが付けられます。ワークロード ID には、workload
ラベルでラベルが付けられます。
コンプライアンス Operator は以下のワークロードをスケジュールします。
- scanner: コンプライアンススキャンを実行します。
- resultserver: コンプライアンススキャンの未加工の結果を保存します。
- aggregator: 結果を集計し、不整合を検出し、結果オブジェクト (チェックの結果と修復) を出力します。
- suitererunner: 再実行するスイートにタグを付けます (スケジュールが設定されている場合)。
- profileparser: データストリームを解析し、適切なプロファイル、ルールおよび変数を作成します。
デバッグおよびログが特定のワークロードに必要な場合は、以下を実行します。
$ oc logs -l workload=<workload_name> -c <container_name>
5.11.2. サポート
本書で説明されている手順、または OpenShift Container Platform で問題が発生した場合は、Red Hat カスタマーポータル にアクセスしてください。カスタマーポータルでは、次のことができます。
- Red Hat 製品に関するアーティクルおよびソリューションについての Red Hat ナレッジベースの検索またはブラウズ。
- Red Hat サポートに対するサポートケースの送信。
- その他の製品ドキュメントへのアクセス。
クラスターの問題を特定するには、OpenShift Cluster Manager で Insights を使用できます。Insights により、問題の詳細と、利用可能な場合は問題の解決方法に関する情報が提供されます。
本書の改善への提案がある場合、またはエラーを見つけた場合は、最も関連性の高いドキュメントコンポーネントの Jira Issue を送信してください。セクション名や OpenShift Container Platform バージョンなどの具体的な情報を提供してください。
5.12. コンプライアンス Operator のアンインストール
OpenShift Container Platform Web コンソールを使用して、クラスターから OpenShift コンプライアンス Operator を削除できます。
5.12.1. OpenShift Container Platform からの OpenShift コンプライアンス Operator のアンインストール
コンプライアンス Operator を削除するには、最初に コンプライアンス Operator のカスタムリソース定義 (CRD) を削除する必要があります。CRD が削除された後、openshift-compliance プロジェクトを削除することにより、Operator とその namespace を削除できます。
前提条件
-
cluster-admin
パーミッションを持つアカウントを使用して OpenShift Container Platform クラスターにアクセスできる。 - OpenShift コンプライアンス Operator をインストールする必要があります。
手順
OpenShift Container Platform Web コンソールを使用して Compliance Operator を削除するには、以下を行います。
Compliance Operator によってインストールされた CRD を削除します。
- Administration → Custom Resource Definitions ページに切り替えます。
-
Name フィールドで
compliance.openshift.io
を検索します。 以下の各 CRD の横にある Options メニュー をクリックし、Delete Custom Resource Definition を選択します。
-
ComplianceCheckResult
-
ComplianceRemediation
-
ComplianceScan
-
ComplianceSuite
-
ProfileBundle
-
プロファイル
-
**ルール**
-
ScanSettingBinding
-
ScanSetting
-
TailoredProfile
-
変数
-
OpenShift Compliance プロジェクトを削除します。
- Home → Projects ページに切り替えます。
- openshift-compliance プロジェクトの横にある Options メニュー をクリックし、Delete Project を選択します。
-
ダイアログボックスに
openshift-compliance
と入力して削除を確認し、Delete をクリックします。
5.13. カスタムリソース定義を理解する
OpenShift Container Platform の コンプライアンス Operator は、コンプライアンススキャンを実行するためのいくつかのカスタムリソース定義 (CRD) を提供します。コンプライアンススキャンを実行するには、ComplianceAsCode コミュニティープロジェクトから派生した事前定義されたセキュリティーポリシーを利用します。コンプライアンスオペレーターは、これらのセキュリティーポリシーを CRD に変換します。これを使用して、コンプライアンススキャンを実行し、見つかった問題の修正を取得できます。
5.13.1. CRD ワークフロー
CRD は、コンプライアンススキャンを完了するための次のワークフローを提供します。
- コンプライアンススキャン要件を定義する
- コンプライアンススキャン設定を設定する
- コンプライアンススキャン設定を使用してコンプライアンス要件を処理する
- コンプライアンススキャンをモニターする
- コンプライアンススキャンの結果を確認する
5.13.2. コンプライアンススキャン要件の定義
デフォルトでは、コンプライアンス Operator CRD には ProfileBundle
オブジェクトと Profile
オブジェクトが含まれており、これらのオブジェクトでコンプライアンススキャン要件のルールを定義および設定できます。TailoredProfile
オブジェクトを使用して、デフォルトのプロファイルをカスタマイズすることもできます。
5.13.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 spec: contentFile: ssg-ocp4-ds.xml 1 contentImage: quay.io/complianceascode/ocp4:latest 2 status: dataStreamStatus: VALID 3
contentFile
が失敗すると、発生したエラーの詳細を提供する errorMessage
属性が表示されます。
トラブルシューティング
無効なイメージから既知のコンテンツイメージにロールバックすると、ProfileBundle
オブジェクトは応答を停止し、PENDING
状態を表示します。回避策として、前のイメージとは異なるイメージに移動できます。または、ProfileBundle
オブジェクトを削除して再作成し、作業状態に戻すこともできます。
5.13.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>
5.13.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>
Rule
オブジェクトは、関連付けられた ProfileBundle
オブジェクトを簡単に識別できるように適切なラベルを取得します。ProfileBundle
は、このオブジェクトの OwnerReferences
でも指定されます。
5.13.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
名を指定します。これは、ComplianceScan
のtailoringConfigMap.name
属性の値として使用できます。- 4
READY
、PENDING
、FAILURE
などのオブジェクトの状態を表示します。オブジェクトの状態がERROR
の場合、属性status.errorMessage
が失敗の理由を提供します。
TailoredProfile
オブジェクトを使用すると、TailoredProfile
コンストラクトを使用して新しい Profile
オブジェクトを作成できます。新しい Profile
を作成するには、次の設定パラメーターを設定します。
- 適切なタイトル
-
extends
は空でなければなりません TailoredProfile
オブジェクトのスキャンタイプアノテーション:compliance.openshift.io/product-type: <scan type>
注記product-type
のアノテーションを設定していない場合、コンプライアンスオペレーターはデフォルトでPlatform
スキャンタイプになります。TailoredProfile
オブジェクトの名前に-node
接尾辞を追加すると、node
スキャンタイプになります。
5.13.3. コンプライアンススキャン設定の設定
コンプライアンススキャンの要件を定義した後、スキャンのタイプ、スキャンの発生、およびスキャンの場所を指定することにより、コンプライアンススキャンを設定できます。そのために、コンプライアンス Operator は ScanSetting
オブジェクトを提供します。
5.13.3.1. ScanSetting オブジェクト
ScanSetting
オブジェクトを使用して、スキャンを実行するための運用ポリシーを定義および再利用します。デフォルトでは、コンプライアンスオペレータは次の ScanSetting
オブジェクトを作成します。
- default - 1Gi Persistent Volume (PV) を使用して、マスターノードとワーカーノードの両方で毎日午前 1 時にスキャンを実行し、最後の 3 つの結果を保持します。修復は自動的に適用も更新もされません。
-
default - 1Gi Persistent Volume (PV) を使用して、コントロールプレーンとワーカーノードの両方で毎日午前 1 時にスキャンを実行し、最後の 3 つの結果を保持します。
autoApplyRemediations
とautoUpdateRemediations
の両方が true に設定されています。
ScanSetting
オブジェクトの例
apiVersion: compliance.openshift.io/v1alpha1 kind: ScanSetting metadata: name: <name of the scan> autoApplyRemediations: false 1 autoUpdateRemediations: false 2 schedule: "0 1 * * *" 3 rawResultStorage: size: "2Gi" 4 rotation: 10 5 roles: 6 - worker - master
- 1
- 自動修復を有効にするには、
true
に設定します。自動修復を無効にするには、false
に設定します。 - 2
- コンテンツ更新の自動修復を有効にするには、
true
に設定します。コンテンツ更新の自動修復を無効にするには、false
に設定します。 - 3
- スキャンを実行する頻度を cron 形式で指定します。
- 4
- 生の結果を保存するためにスキャン用に作成する必要があるストレージサイズを指定します。デフォルト値は
1Gi
です。 - 5
- 生の結果が保存されるスキャンの量を指定します。デフォルト値は
3
です。古い結果がローテーションされると、管理者はローテーションが発生する前に結果を別の場所に保存する必要があります。注記ローテーションポリシーを無効にするには、値を
0
に設定します。 - 6
node-role.kubernetes.io
ラベル値を指定して、Node
タイプのスキャンをスケジュールします。この値は、MachineConfigPool
の名前と一致する必要があります。
5.13.4. コンプライアンススキャン設定を使用したコンプライアンススキャン要件の処理
コンプライアンススキャン要件を定義し、スキャンを実行するように設定すると、コンプライアンスオペレーターは ScanSettingBinding
オブジェクトを使用してそれを処理します。
5.13.4.1. ScanSettingBinding オブジェクト
ScanSettingBinding
オブジェクトを使用して、Profile
または TailoredProfile
オブジェクトを参照してコンプライアンス要件を指定します。次に、スキャンの操作上の制約を提供する ScanSetting
オブジェクトにリンクされます。次に、コンプライアンス 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
ScanSetting
オブジェクトと ScanSettingBinding
オブジェクトを作成すると、コンプライアンススイートが作成されます。コンプライアンススイートのリストを取得するには、次のコマンドを実行します。
$ oc get compliancesuites
ScanSettingBinding
を削除すると、コンプライアンススイートも削除されます。
5.13.5. コンプライアンススキャンの追跡
コンプライアンススイートの作成後、ComplianceSuite
オブジェクトを使用して、デプロイされたスキャンのステータスをモニターできます。
5.13.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: quay.io/complianceascode/ocp4:latest 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
バックグラウンドのスイートは、scans
パラメーターに基づいて ComplianceScan
オブジェクトを作成します。プログラムで ComplianceSuites
イベントを取得できます。スイートのイベントを取得するには、次のコマンドを実行します。
$ oc get events --field-selector involvedObject.kind=ComplianceSuite,involvedObject.name=<name of the suite>
手動で ComplianceSuite
を定義すると、XCCDF 属性が含まれているため、エラーが発生する可能性があります。
5.13.5.2. 高度な ComplianceScan オブジェクト
コンプライアンスオペレーターには、デバッグまたは既存のツールとの統合のための上級ユーザー向けのオプションが含まれています。ComplianceScan
オブジェクトを直接作成しないことをお勧めしますが、代わりに、ComplianceSuite
オブジェクトを使用してオブジェクトを管理できます。
AdvancedComplianceScan
オブジェクトの例
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: quay.io/complianceascode/ocp4:latest 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.13.6. コンプライアンス結果の表示
コンプライアンススイートが DONE
フェーズに達すると、スキャン結果と可能な修正を表示できます。
5.13.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
スイートからすべてのチェック結果を取得するには、次のコマンドを実行します。
oc get compliancecheckresults -l compliance.openshift.io/suite=<suit name>
5.13.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
スイートからすべての修復を取得するには、次のコマンドを実行します。
oc get complianceremediations -l compliance.openshift.io/suite=<suite name>
自動的に修正できるすべての失敗したチェックを一覧表示するには、次のコマンドを実行します。
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'
第6章 File Integrity Operator
6.1. File Integrity Operator リリースノート
OpenShift Container Platform のファイル整合性オペレーターは、RHCOS ノードでファイル整合性チェックを継続的に実行します。
これらのリリースノートは、OpenShift Container Platform での File Integrity Operator の開発を追跡します。
File Integrity Operator の概要については、File Integrity Operator について を参照してください。
6.1.1. OpenShift File Integrity Operator 0.1.30
OpenShift File Integrity Operator 0.1.30 については、以下のアドバイザリーを利用できます。
6.1.1.1. バグ修正
- 以前は、File Integrity Operator が発行したアラートでは namespace が設定されていなかったため、アラートの発生場所を理解することが困難でした。現在、Operator は適切な namespace を設定し、アラートが理解できるように改善されています。(BZ#2101393)
6.1.2. OpenShift File Integrity Operator 0.1.24
OpenShift File Integrity Operator 0.1.24 については、以下のアドバイザリーを利用できます。
6.1.2.1. 新機能および機能拡張
-
config.maxBackups
属性を使用して、FileIntegrity
カスタムリソース (CR) に保存されるバックアップの最大数を設定できるようになりました。この属性は、ノードに保持するためにre-init
プロセスから残された AIDE データベースおよびログのバックアップの数を指定します。設定された数を超える古いバックアップは自動的にプルーニングされます。デフォルトは 5 つのバックアップに設定されています。
6.1.2.2. バグ修正
-
以前は、Operator を 0.1.21 より古いバージョンから 0.1.22 にアップグレードすると、
re-init
機能が失敗する可能性がありました。これは、オペレーターがconfigMap
リソースラベルの更新に失敗した結果です。現在、最新バージョンにアップグレードすると、リソースラベルが修正されます。(BZ#2049206) -
以前は、デフォルトの
configMap
スクリプトの内容を適用するときに、間違ったデータキーが比較されていました。これにより、Operator のアップグレード後にaide-reinit
スクリプトが適切に更新されず、re-init
プロセスが失敗することがありました。これで、daemonSets
が完了するまで実行され、AIDE データベースのre-init
プロセスが正常に実行されます。(BZ#2072058)
6.1.3. OpenShift File Integrity Operator 0.1.22
OpenShift File Integrity Operator 0.1.22 については、以下のアドバイザリーを利用できます。
6.1.3.1. バグ修正
-
以前は、File Integrity Operator がインストールされているシステムが、
/etc/kubernetes/aid.reinit
ファイルが原因で、OpenShift Container Platform の更新を中断する可能性がありました。これは、/etc/kubernetes/aide.reinit
ファイルが存在したが、後でostree
検証の前に削除された場合に発生しました。今回の更新では、/etc/kubernetes/aide.reinit
が/run
ディレクトリーに移動し、OpenShift Container Platform の更新と競合しないようになっています。(BZ#2033311)
6.1.4. OpenShift File Integrity Operator 0.1.21
OpenShift File Integrity Operator 0.1.21 については、以下のアドバイザリーを利用できます。
6.1.4.1. 新機能および機能拡張
-
FileIntegrity
スキャン結果および処理メトリックに関連するメトリックは、Web コンソールの監視ダッシュボードに表示されます。結果には、file_integrity_operator_
の接頭辞が付けられます。 -
ノードの整合性障害が 1 秒を超えると、Operator の namespace で提供されるデフォルトの
PrometheusRule
が警告を発します。 次の動的な Machine Config Operator および Cluster Version Operator 関連のファイルパスは、ノードの更新中の誤検知を防ぐために、デフォルトの AIDE ポリシーから除外されています。
- /etc/machine-config-daemon/currentconfig
- /etc/pki/ca-trust/extracted/java/cacerts
- /etc/cvo/updatepayloads
- /root/.kube
- AIDE デーモンプロセスは v0.1.16 よりも安定性が向上しており、AIDE データベースの初期化時に発生する可能性のあるエラーに対する耐性が高くなっています。
6.1.4.2. バグ修正
- 以前は、Operator が自動的にアップグレードしたときに、古いデーモンセットは削除されませんでした。このリリースでは、自動アップグレード中に古いデーモンセットが削除されます。
6.1.5. 関連情報
6.2. File Integrity Operator のインストール
6.2.1. Web コンソールでの File Integrity Operator のインストール
前提条件
-
admin
権限がある。
手順
- OpenShift Container Platform Web コンソールで、Operators → OperatorHub ページに移動します。
- File Integrity Operator を検索し、Install をクリックします。
-
Installation mode および namespace のデフォルトの選択を維持し、Operator が
openshift-file-integrity
namespace にインストールされていることを確認します。 - Install をクリックします。
検証
インストールが正常に行われたことを確認するには、以下を実行します。
- Operators → Installed Operators ページに移動します。
-
Operator が
openshift-file-integrity
namespace にインストールされており、そのステータスがSucceeded
であることを確認します。
Operator が正常にインストールされていない場合、以下を実行します。
-
Operators → Installed Operators ページに移動し、
Status
列でエラーまたは失敗の有無を確認します。 -
Workloads → Pods ページに移動し、
openshift-file-integrity
プロジェクトの Pod で問題を報告しているログの有無を確認します。
6.2.2. CLI を使用した File Integrity Operator のインストール
前提条件
-
admin
権限がある。
手順
以下を実行して
Namespace
オブジェクト YAML ファイルを作成します。$ oc create -f <file-name>.yaml
出力例
apiVersion: v1 kind: Namespace metadata: labels: openshift.io/cluster-monitoring: "true" name: openshift-file-integrity
OperatorGroup
オブジェクト YAML ファイルを作成します。$ oc create -f <file-name>.yaml
出力例
apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: file-integrity-operator namespace: openshift-file-integrity spec: targetNamespaces: - openshift-file-integrity
Subscription
オブジェクト YAML ファイルを作成します。$ oc create -f <file-name>.yaml
出力例
apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: file-integrity-operator namespace: openshift-file-integrity spec: channel: "release-0.1" installPlanApproval: Automatic name: file-integrity-operator source: redhat-operators sourceNamespace: openshift-marketplace
検証
CSV ファイルを確認して、インストールが正常に完了したことを確認します。
$ oc get csv -n openshift-file-integrity
File Integrity Operator が稼働していることを確認します。
$ oc get deploy -n openshift-file-integrity
6.2.3. 関連情報
- File Integrity Operator はネットワークが制限された環境でサポートされています。詳細は、ネットワークが制限された環境での Operator Lifecycle Manager の使用 を参照してください。
6.3. File Integrity Operator について
File Integrity Operator は OpenShift Container Platform Operator であり、クラスターノード上でファイルの整合性チェックを継続的に実行します。これは、各ノードで特権付きの AIDE (advanced intrusion detection environment; 高度な侵入検知環境) コンテナーを各ノードで初期化し、実行するデーモンセットをデプロイし、ステータスオブジェクトをデーモンセット Pod の初回実行時に変更されるファイルのログと共に提供します。
現時点では、Red Hat Enterprise Linux CoreOS (RHCOS) ノードのみがサポートされます。
6.3.1. FileIntegrity カスタムリソースの作成
FileIntegrity
カスタムリソース (CR) のインスタンスは、1 つ以上のノードの継続的なファイル整合性スキャンのセットを表します。
それぞれの FileIntegrity
CR は、 FileIntegrity
CR 仕様に一致するノード上で AIDE を実行するデーモンセットによってサポートされます。
手順
worker-fileintegrity.yaml
という名前の次の例のFileIntegrity
CR を作成して、ワーカーノードでのスキャンを有効にします。サンプル FileIntegrity CR
apiVersion: fileintegrity.openshift.io/v1alpha1 kind: FileIntegrity metadata: name: worker-fileintegrity namespace: openshift-file-integrity spec: nodeSelector: node-role.kubernetes.io/worker: "" config: {}
YAML ファイルを
openshift-file-integrity
namespace に適用します。$ oc apply -f worker-fileintegrity.yaml -n openshift-file-integrity
検証
次のコマンドを実行して、
FileIntegrity
オブジェクトが正常に作成されたことを確認します。$ oc get fileintegrities -n openshift-file-integrity
出力例
NAME AGE worker-fileintegrity 14s
6.3.2. FileIntegrity カスタムリソースのステータスの確認
FileIntegrity
カスタムリソース (CR) は、.status.phase
サブリソースでそのステータスを報告します。
手順
FileIntegrity
CR ステータスをクエリーするには、以下を実行します。$ oc get fileintegrities/worker-fileintegrity -o jsonpath="{ .status.phase }"
出力例
Active
6.3.3. FileIntegrity カスタムリソースの各種フェーズ
-
Pending
: カスタムリソース (CR) の作成後のフェーズ。 -
Active
: バッキングデーモンセットが実行するフェーズ。 -
Initializing
: AIDE データベースが再初期化されるフェーズ。
6.3.4. FileIntegrityNodeStatuses オブジェクトについて
FileIntegrity
CR のスキャン結果は、FileIntegrityNodeStatuses
という別のオブジェクトで報告されます。
$ oc get fileintegritynodestatuses
出力例
NAME AGE worker-fileintegrity-ip-10-0-130-192.ec2.internal 101s worker-fileintegrity-ip-10-0-147-133.ec2.internal 109s worker-fileintegrity-ip-10-0-165-160.ec2.internal 102s
FileIntegrityNodeStatus
オブジェクトの結果が利用可能になるまで、しばらく時間がかかる場合があります。
ノードごとに 1 つの結果オブジェクトがあります。それぞれの FileIntegrityNodeStatus
オブジェクトの nodeName
属性は、スキャンされるノードに対応します。ファイル整合性スキャンのステータスは、スキャン条件を保持する results
配列で表示されます。
$ oc get fileintegritynodestatuses.fileintegrity.openshift.io -ojsonpath='{.items[*].results}' | jq
fileintegritynodestatus
オブジェクトは AIDE 実行の最新のステータスを報告し、status
フィールドに Failed
、Succeeded
、または Errored
などのステータスを公開します。
$ oc get fileintegritynodestatuses -w
出力例
NAME NODE STATUS example-fileintegrity-ip-10-0-134-186.us-east-2.compute.internal ip-10-0-134-186.us-east-2.compute.internal Succeeded example-fileintegrity-ip-10-0-150-230.us-east-2.compute.internal ip-10-0-150-230.us-east-2.compute.internal Succeeded example-fileintegrity-ip-10-0-169-137.us-east-2.compute.internal ip-10-0-169-137.us-east-2.compute.internal Succeeded example-fileintegrity-ip-10-0-180-200.us-east-2.compute.internal ip-10-0-180-200.us-east-2.compute.internal Succeeded example-fileintegrity-ip-10-0-194-66.us-east-2.compute.internal ip-10-0-194-66.us-east-2.compute.internal Failed example-fileintegrity-ip-10-0-222-188.us-east-2.compute.internal ip-10-0-222-188.us-east-2.compute.internal Succeeded example-fileintegrity-ip-10-0-134-186.us-east-2.compute.internal ip-10-0-134-186.us-east-2.compute.internal Succeeded example-fileintegrity-ip-10-0-222-188.us-east-2.compute.internal ip-10-0-222-188.us-east-2.compute.internal Succeeded example-fileintegrity-ip-10-0-194-66.us-east-2.compute.internal ip-10-0-194-66.us-east-2.compute.internal Failed example-fileintegrity-ip-10-0-150-230.us-east-2.compute.internal ip-10-0-150-230.us-east-2.compute.internal Succeeded example-fileintegrity-ip-10-0-180-200.us-east-2.compute.internal ip-10-0-180-200.us-east-2.compute.internal Succeeded
6.3.5. FileIntegrityNodeStatus CR ステータスタイプ
これらの条件は、対応する FileIntegrityNodeStatus
CR ステータスの results 配列で報告されます。
-
Succeeded
: 整合性チェックにパスしました。データベースが最後に初期化されてから、AIDE チェックの対象となるファイルおよびディレクトリーは変更されていません。 -
Failed
: 整合性チェックにパスしません。データベースが最後に初期化されてから、AIDE チェックの対象となるファイルまたはディレクトリーが変更されています。 -
Errored
: AIDE スキャナーで内部エラーが発生しました。
6.3.5.1. FileIntegrityNodeStatus CR の成功例
成功ステータスのある状態の出力例
[ { "condition": "Succeeded", "lastProbeTime": "2020-09-15T12:45:57Z" } ] [ { "condition": "Succeeded", "lastProbeTime": "2020-09-15T12:46:03Z" } ] [ { "condition": "Succeeded", "lastProbeTime": "2020-09-15T12:45:48Z" } ]
この場合、3 つのスキャンがすべて正常に実行され、現時点ではその他の状態は存在しません。
6.3.5.2. FileIntegrityNodeStatus CR の失敗ステータスの例
障害のある状態をシミュレートするには、AIDE が追跡するファイルの 1 つを変更します。たとえば、ワーカーノードのいずれかで /etc/resolv.conf
を変更します。
$ oc debug node/ip-10-0-130-192.ec2.internal
出力例
Creating debug namespace/openshift-debug-node-ldfbj ... Starting pod/ip-10-0-130-192ec2internal-debug ... To use host binaries, run `chroot /host` Pod IP: 10.0.130.192 If you don't see a command prompt, try pressing enter. sh-4.2# echo "# integrity test" >> /host/etc/resolv.conf sh-4.2# exit Removing debug pod ... Removing debug namespace/openshift-debug-node-ldfbj ...
しばらくすると、Failed
状態が対応する FileIntegrityNodeStatus
オブジェクトの results 配列で報告されます。前回の Succeeded
状態は保持されるため、チェックが失敗した時間を特定することができます。
$ oc get fileintegritynodestatuses.fileintegrity.openshift.io/worker-fileintegrity-ip-10-0-130-192.ec2.internal -ojsonpath='{.results}' | jq -r
または、オブジェクト名に言及していない場合は、以下を実行します。
$ oc get fileintegritynodestatuses.fileintegrity.openshift.io -ojsonpath='{.items[*].results}' | jq
出力例
[ { "condition": "Succeeded", "lastProbeTime": "2020-09-15T12:54:14Z" }, { "condition": "Failed", "filesChanged": 1, "lastProbeTime": "2020-09-15T12:57:20Z", "resultConfigMapName": "aide-ds-worker-fileintegrity-ip-10-0-130-192.ec2.internal-failed", "resultConfigMapNamespace": "openshift-file-integrity" } ]
Failed
状態は、失敗した内容と理由に関する詳細を示す設定マップを参照します。
$ oc describe cm aide-ds-worker-fileintegrity-ip-10-0-130-192.ec2.internal-failed
出力例
Name: aide-ds-worker-fileintegrity-ip-10-0-130-192.ec2.internal-failed Namespace: openshift-file-integrity Labels: file-integrity.openshift.io/node=ip-10-0-130-192.ec2.internal file-integrity.openshift.io/owner=worker-fileintegrity file-integrity.openshift.io/result-log= Annotations: file-integrity.openshift.io/files-added: 0 file-integrity.openshift.io/files-changed: 1 file-integrity.openshift.io/files-removed: 0 Data integritylog: ------ AIDE 0.15.1 found differences between database and filesystem!! Start timestamp: 2020-09-15 12:58:15 Summary: Total number of files: 31553 Added files: 0 Removed files: 0 Changed files: 1 --------------------------------------------------- Changed files: --------------------------------------------------- changed: /hostroot/etc/resolv.conf --------------------------------------------------- Detailed information about changes: --------------------------------------------------- File: /hostroot/etc/resolv.conf SHA512 : sTQYpB/AL7FeoGtu/1g7opv6C+KT1CBJ , qAeM+a8yTgHPnIHMaRlS+so61EN8VOpg Events: <none>
設定マップのデータサイズの制限により、1 MB を超える AIDE ログが base64 でエンコードされた gzip アーカイブとして障害用の設定マップに追加されます。この場合は、上記のコマンドの出力を base64 --decode | gunzip
にパイプ処理する必要があります。圧縮されたログの有無は、設定マップにある file-integrity.openshift.io/compressed
アノテーションキーで示唆されます。
6.3.6. イベントについて
FileIntegrity
および FileIntegrityNodeStatus
オブジェクトのステータスの移行は イベント でログに記録されます。イベントの作成時間は、Initializing
から Active
など、最新の移行を反映し、必ずしも最新のスキャン結果ではありません。ただし、最新のイベントは常に最新のステータスを反映しています。
$ oc get events --field-selector reason=FileIntegrityStatus
出力例
LAST SEEN TYPE REASON OBJECT MESSAGE 97s Normal FileIntegrityStatus fileintegrity/example-fileintegrity Pending 67s Normal FileIntegrityStatus fileintegrity/example-fileintegrity Initializing 37s Normal FileIntegrityStatus fileintegrity/example-fileintegrity Active
ノードのスキャンに失敗すると、イベントは add/changed/removed
および設定マップ情報と共に作成されます。
$ oc get events --field-selector reason=NodeIntegrityStatus
出力例
LAST SEEN TYPE REASON OBJECT MESSAGE 114m Normal NodeIntegrityStatus fileintegrity/example-fileintegrity no changes to node ip-10-0-134-173.ec2.internal 114m Normal NodeIntegrityStatus fileintegrity/example-fileintegrity no changes to node ip-10-0-168-238.ec2.internal 114m Normal NodeIntegrityStatus fileintegrity/example-fileintegrity no changes to node ip-10-0-169-175.ec2.internal 114m Normal NodeIntegrityStatus fileintegrity/example-fileintegrity no changes to node ip-10-0-152-92.ec2.internal 114m Normal NodeIntegrityStatus fileintegrity/example-fileintegrity no changes to node ip-10-0-158-144.ec2.internal 114m Normal NodeIntegrityStatus fileintegrity/example-fileintegrity no changes to node ip-10-0-131-30.ec2.internal 87m Warning NodeIntegrityStatus fileintegrity/example-fileintegrity node ip-10-0-152-92.ec2.internal has changed! a:1,c:1,r:0 \ log:openshift-file-integrity/aide-ds-example-fileintegrity-ip-10-0-152-92.ec2.internal-failed
ノードのステータスが移行されなかった場合でも、追加、変更、または削除されたファイルの数を変更すると、新しいイベントが生成されます。
$ oc get events --field-selector reason=NodeIntegrityStatus
出力例
LAST SEEN TYPE REASON OBJECT MESSAGE 114m Normal NodeIntegrityStatus fileintegrity/example-fileintegrity no changes to node ip-10-0-134-173.ec2.internal 114m Normal NodeIntegrityStatus fileintegrity/example-fileintegrity no changes to node ip-10-0-168-238.ec2.internal 114m Normal NodeIntegrityStatus fileintegrity/example-fileintegrity no changes to node ip-10-0-169-175.ec2.internal 114m Normal NodeIntegrityStatus fileintegrity/example-fileintegrity no changes to node ip-10-0-152-92.ec2.internal 114m Normal NodeIntegrityStatus fileintegrity/example-fileintegrity no changes to node ip-10-0-158-144.ec2.internal 114m Normal NodeIntegrityStatus fileintegrity/example-fileintegrity no changes to node ip-10-0-131-30.ec2.internal 87m Warning NodeIntegrityStatus fileintegrity/example-fileintegrity node ip-10-0-152-92.ec2.internal has changed! a:1,c:1,r:0 \ log:openshift-file-integrity/aide-ds-example-fileintegrity-ip-10-0-152-92.ec2.internal-failed 40m Warning NodeIntegrityStatus fileintegrity/example-fileintegrity node ip-10-0-152-92.ec2.internal has changed! a:3,c:1,r:0 \ log:openshift-file-integrity/aide-ds-example-fileintegrity-ip-10-0-152-92.ec2.internal-failed
6.4. カスタム File Integrity Operator の設定
6.4.1. FileIntegrity オブジェクト属性の表示
Kubernetes カスタムリソース (CR) の場合と同様に、oc explain fileintegrity
を実行してから、以下を使用して個別の属性を参照できます。
$ oc explain fileintegrity.spec
$ oc explain fileintegrity.spec.config
6.4.2. 重要な属性
属性 | 説明 |
---|---|
|
AIDE Pod が該当ノードでスケジュール対象にするために使用する、ノードのラベルと一致する必要があるキーと値のペアのマップ。通常は、 |
|
ブール値の属性。 |
| カスタムテイントを持つノードにスケジュールする容認を指定します。指定されない場合は、デフォルトの容認 (Toleration) が適用され、これにより容認はコントロールプレーンノード (別名マスターノード) で実行できます。 |
|
AIDE 整合性チェックの間に一時停止する秒数。ノード上で AIDE チェックを頻繁に実行すると、多くのリソースが消費する可能性があるため、間隔をより長く指定することができます。デフォルトは |
|
ノードで保持する |
| カスタム AIDE 設定を含む configMap の名前。省略した場合、デフォルトの設定が作成されます。 |
| カスタム AIDE 設定を含む configMap の namespace。設定されていない場合、FIO は RHCOS システムに適したデフォルト設定を生成します。 |
|
|
6.4.3. デフォルト設定の確認
デフォルトの File Integrity Operator 設定は、 FileIntegrity
CR と同じ名前で設定マップに保存されます。
手順
デフォルトの設定を確認するには、以下を実行します。
$ oc describe cm/worker-fileintegrity
6.4.4. デフォルトの File Integrity Operator 設定について
以下は、設定マップの aide.conf
キーの抜粋です。
@@define DBDIR /hostroot/etc/kubernetes @@define LOGDIR /hostroot/etc/kubernetes database=file:@@{DBDIR}/aide.db.gz database_out=file:@@{DBDIR}/aide.db.gz gzip_dbout=yes verbose=5 report_url=file:@@{LOGDIR}/aide.log report_url=stdout PERMS = p+u+g+acl+selinux+xattrs CONTENT_EX = sha512+ftype+p+u+g+n+acl+selinux+xattrs /hostroot/boot/ CONTENT_EX /hostroot/root/\..* PERMS /hostroot/root/ CONTENT_EX
FileIntegrity
インスタンスのデフォルト設定は、以下のディレクトリー下にあるファイルの範囲を指定します。
-
/root
-
/boot
-
/usr
-
/etc
以下のディレクトリーは対象外です。
-
/var
-
/opt
-
/etc/
下の一部の OpenShift 固有の除外対象
6.4.5. カスタム AIDE 設定の指定
DBDIR
、LOGDIR
、database
、および database_out
などの AIDE 内部動作を設定するエントリーは Operator によって上書きされます。Operator は、整合性に関する変更の有無についてすべてのパスを監視できるよう接頭辞を /hostroot/
に追加します。これにより、コンテナー化された環境用にカスタマイズされない既存の AIDE 設定を再使用や、ルートディレクトリーからの開始がより容易になります。
/hostroot
は、AIDE を実行する Pod がホストのファイルシステムをマウントするディレクトリーです。設定を変更すると、データベースの再初期化がトリガーされます。
6.4.6. カスタム File Integrity Operator 設定の定義
この例では、worker-fileintegrity
CR に提供されるデフォルト設定に基づいてコントロールプレーンノード (別名マスターノード) で実行されるスキャナーのカスタム設定を定義することに重点を置いています。このワークフローは、デーモンセットとして実行されているカスタムソフトウェアをデプロイし、そのデータをコントロールプレーンノードの /opt/mydaemon
の下に保存する場合に役立ちます。
手順
- デフォルト設定のコピーを作成します。
- デフォルト設定を、監視するか、除外する必要があるファイルで編集します。
- 編集したコンテンツを新たな設定マップに保存します。
-
spec.config
の属性を使用して、FileIntegrity
オブジェクトを新規の設定マップにポイントします。 デフォルト設定を抽出します。
$ oc extract cm/worker-fileintegrity --keys=aide.conf
これにより、編集可能な
aide.conf
という名前のファイルが作成されます。この例では、Operator のパスの後処理方法を説明するために、接頭辞なしで除外ディレクトリーを追加します。$ vim aide.conf
出力例
/hostroot/etc/kubernetes/static-pod-resources !/hostroot/etc/kubernetes/aide.* !/hostroot/etc/kubernetes/manifests !/hostroot/etc/docker/certs.d !/hostroot/etc/selinux/targeted !/hostroot/etc/openvswitch/conf.db
コントロールプレーンノードに固有のパスを除外します。
!/opt/mydaemon/
その他のコンテンツを
/etc
に保存します。/hostroot/etc/ CONTENT_EX
このファイルに基づいて設定マップを作成します。
$ oc create cm master-aide-conf --from-file=aide.conf
設定マップを参照する
FileIntegrity
CR マニフェストを定義します。apiVersion: fileintegrity.openshift.io/v1alpha1 kind: FileIntegrity metadata: name: master-fileintegrity namespace: openshift-file-integrity spec: nodeSelector: node-role.kubernetes.io/master: "" config: name: master-aide-conf namespace: openshift-file-integrity
Operator は指定された設定マップファイルを処理し、結果を
FileIntegrity
オブジェクトと同じ名前の設定マップに保存します。$ oc describe cm/master-fileintegrity | grep /opt/mydaemon
出力例
!/hostroot/opt/mydaemon
6.4.7. カスタムのファイル整合性設定の変更
ファイル整合性の設定を変更するには、生成される設定マップを変更しないでください。その代わりに、spec.name
、namespace
、および key
属性を使用して FileIntegrity
オブジェクトにリンクされる設定マップを変更します。
6.5. 高度なカスタム File Integrity Operator タスクの実行
6.5.1. データベースの再初期化
File Integrity Operator が予定される変更を検知する場合、データベースの再初期化が必要になることがあります。
手順
FileIntegrity
カスタムリソース (CR) にfile-integrity.openshift.io/re-init
のアノテーションを付けます。$ oc annotate fileintegrities/worker-fileintegrity file-integrity.openshift.io/re-init=
古いデータベースとログファイルがバックアップされ、新しいデータベースが初期化されます。
oc debug
を使用して起動する Pod の以下の出力に示されるように、古いデータベースおよびログは/etc/kubernetes
の下にあるノードに保持されます。出力例
ls -lR /host/etc/kubernetes/aide.* -rw-------. 1 root root 1839782 Sep 17 15:08 /host/etc/kubernetes/aide.db.gz -rw-------. 1 root root 1839783 Sep 17 14:30 /host/etc/kubernetes/aide.db.gz.backup-20200917T15_07_38 -rw-------. 1 root root 73728 Sep 17 15:07 /host/etc/kubernetes/aide.db.gz.backup-20200917T15_07_55 -rw-r--r--. 1 root root 0 Sep 17 15:08 /host/etc/kubernetes/aide.log -rw-------. 1 root root 613 Sep 17 15:07 /host/etc/kubernetes/aide.log.backup-20200917T15_07_38 -rw-r--r--. 1 root root 0 Sep 17 15:07 /host/etc/kubernetes/aide.log.backup-20200917T15_07_55
レコードの永続性を確保するために、生成される設定マップは
FileIntegrity
オブジェクトによって所有されません。そのため、手動のクリーンアップが必要になります。結果として、以前の整合性の失敗が依然としてFileIntegrityNodeStatus
オブジェクトに表示されます。
6.5.2. マシン設定の統合
OpenShift Container Platform 4 では、クラスターノード設定は MachineConfig
オブジェクトで提供されます。MachineConfig
オブジェクトによって生じるファイルへの変更が予想されますが、ファイルの整合性スキャンは失敗しないことを前提にすることができます。MachineConfig
オブジェクトの更新によって生じるファイルの変更を抑制するために、File Integrity Operator はノードオブジェクトを監視します。ノードが更新されると、AIDE スキャンは更新の期間一時停止します。更新が完了すると、データベースが再初期化され、スキャンが再開されます。
この一時停止および再開ロジックは、ノードオブジェクトのアノテーションに反映されるため、MachineConfig
API での更新にのみ適用されます。
6.5.3. デーモンセットの参照
それぞれの FileIntegrity
オブジェクトはノード数についてのスキャンを表します。スキャン自体は、デーモンセットによって管理される Pod で実行されます。
FileIntegrity
オブジェクトを表すデーモンセットを見つけるには、以下を実行します。
$ oc -n openshift-file-integrity get ds/aide-worker-fileintegrity
そのデーモンセットの Pod を一覧表示するには、以下を実行します。
$ oc -n openshift-file-integrity get pods -lapp=aide-worker-fileintegrity
単一の AIDE Pod のログを表示するには、Pod のいずれかで oc logs
を呼び出します。
$ oc -n openshift-file-integrity logs pod/aide-worker-fileintegrity-mr8x6
出力例
Starting the AIDE runner daemon initializing AIDE db initialization finished running aide check ...
AIDE デーモンによって作成された設定マップは保持されず、File Integrity Operator がこれらを処理した後に削除されます。ただし、障害およびエラーの発生時に、これらの設定マップの内容は FileIntegrityNodeStatus
オブジェクトが参照する設定マップにコピーされます。
6.6. File Integrity Operator のトラブルシューティング
6.6.1. 一般的なトラブルシューティング
- 問題
- File Integrity Operator の問題をトラブルシューティングする必要がある場合があります。
- 解決策
-
FileIntegrity
オブジェクトでデフォルトフラグを有効にします。debug
フラグは、DaemonSet
Pod で実行されるデーモンの詳細度を上げ、AIDE チェックを実行します。
6.6.2. AIDE 設定の確認
- 問題
- AIDE 設定を確認する必要がある場合があります。
- 解決策
-
AIDE 設定は、
FileIntegrity
オブジェクトと同じ名前で設定マップに保存されます。すべての AIDE 設定の設定マップには、file-integrity.openshift.io/aide-conf
のラベルが付けられます。
6.6.3. FileIntegrity オブジェクトのフェーズの判別
- 問題
-
FileIntegrity
オブジェクトが存在するかどうかを判別し、その現在のステータスを確認する必要がある場合があります。 - 解決策
FileIntegrity
オブジェクトの現在のステータスを確認するには、以下を実行します。$ oc get fileintegrities/worker-fileintegrity -o jsonpath="{ .status }"
FileIntegrity
オブジェクトおよびサポートするデーモンセットが作成されると、ステータスはActive
に切り替わります。切り替わらない場合は、Operator Pod ログを確認してください。
6.6.4. デーモンセットの Pod が予想されるノードで実行されていることの判別
- 問題
- デーモンセットが存在し、その Pod が実行されることが予想されるノードで実行されていることを確認する必要がある場合があります。
- 解決策
以下を実行します。
$ oc -n openshift-file-integrity get pods -lapp=aide-worker-fileintegrity
注記-owide
を追加すると、Pod が実行されているノードの IP アドレスが含まれます。デーモン Pod のログを確認するには、
oc logs
を実行します。AIDE コマンドの戻り値をチェックして、チェックが合否を確認します。
第7章 監査ログの表示
OpenShift Container Platform 監査は、システムに影響を与えた一連のアクティビティーを個別のユーザー、管理者その他システムのコンポーネント別に記述したセキュリティー関連の時系列のレコードを提供します。
7.1. API の監査ログについて
監査は API サーバーレベルで実行され、サーバーに送られるすべての要求をログに記録します。それぞれの監査ログには、以下の情報が含まれます。
フィールド | 説明 |
---|---|
| イベントが生成された監査レベル。 |
| 要求ごとに生成される一意の監査 ID。 |
| このイベントインスタンスの生成時の要求処理のステージ。 |
| クライアントによってサーバーに送信される要求 URI。 |
| 要求に関連付けられる Kubernetes の動詞。リソース以外の要求の場合、これは小文字の HTTP メソッドになります。 |
| 認証されたユーザーの情報。 |
| オプション。偽装ユーザーの情報 (要求で別のユーザーを偽装する場合)。 |
| オプション。要求の送信元および中間プロキシーからのソース IP。 |
| オプション。クライアントが報告するユーザーエージェントの文字列。ユーザーエージェントはクライアントによって提供されており、信頼できないことに注意してください。 |
|
オプション。この要求のターゲットとなっているオブジェクト参照。これは、 |
|
オプション。 |
|
オプション。JSON 形式の要求からの API オブジェクト。 |
|
オプション。JSON 形式の応答で返される API オブジェクト。 |
| 要求が API サーバーに到達した時間。 |
| 要求が現在の監査ステージに達した時間。 |
|
オプション。監査イベントと共に保存される構造化されていないキーと値のマップ。これは、認証、認可、受付プラグインなど、要求提供チェーンで呼び出されるプラグインによって設定される可能性があります。これらのアノテーションは監査イベント用のもので、送信されたオブジェクトの |
Kubernetes API サーバーの出力例:
{"kind":"Event","apiVersion":"audit.k8s.io/v1","level":"Metadata","auditID":"ad209ce1-fec7-4130-8192-c4cc63f1d8cd","stage":"ResponseComplete","requestURI":"/api/v1/namespaces/openshift-kube-controller-manager/configmaps/cert-recovery-controller-lock?timeout=35s","verb":"update","user":{"username":"system:serviceaccount:openshift-kube-controller-manager:localhost-recovery-client","uid":"dd4997e3-d565-4e37-80f8-7fc122ccd785","groups":["system:serviceaccounts","system:serviceaccounts:openshift-kube-controller-manager","system:authenticated"]},"sourceIPs":["::1"],"userAgent":"cluster-kube-controller-manager-operator/v0.0.0 (linux/amd64) kubernetes/$Format","objectRef":{"resource":"configmaps","namespace":"openshift-kube-controller-manager","name":"cert-recovery-controller-lock","uid":"5c57190b-6993-425d-8101-8337e48c7548","apiVersion":"v1","resourceVersion":"574307"},"responseStatus":{"metadata":{},"code":200},"requestReceivedTimestamp":"2020-04-02T08:27:20.200962Z","stageTimestamp":"2020-04-02T08:27:20.206710Z","annotations":{"authorization.k8s.io/decision":"allow","authorization.k8s.io/reason":"RBAC: allowed by ClusterRoleBinding \"system:openshift:operator:kube-controller-manager-recovery\" of ClusterRole \"cluster-admin\" to ServiceAccount \"localhost-recovery-client/openshift-kube-controller-manager\""}}
7.2. 監査ログの表示
それぞれのコントロールプレーンノード (別名マスターノード) の OpenShift API サーバー、Kubernetes API サーバー、および OpenShift OAuth API サーバーのログを表示することができます。
手順
監査ログを表示するには、以下を実行します。
OpenShift API サーバーログを表示します。
各コントロールプレーンノードで利用可能な OpenShift API サーバーログを一覧表示します。
$ oc adm node-logs --role=master --path=openshift-apiserver/
出力例
ci-ln-m0wpfjb-f76d1-vnb5x-master-0 audit-2021-03-09T00-12-19.834.log ci-ln-m0wpfjb-f76d1-vnb5x-master-0 audit.log ci-ln-m0wpfjb-f76d1-vnb5x-master-1 audit-2021-03-09T00-11-49.835.log ci-ln-m0wpfjb-f76d1-vnb5x-master-1 audit.log ci-ln-m0wpfjb-f76d1-vnb5x-master-2 audit-2021-03-09T00-13-00.128.log ci-ln-m0wpfjb-f76d1-vnb5x-master-2 audit.log
ノード名とログ名を指定して、特定の OpenShift API サーバーログを表示します。
$ oc adm node-logs <node_name> --path=openshift-apiserver/<log_name>
以下に例を示します。
$ oc adm node-logs ci-ln-m0wpfjb-f76d1-vnb5x-master-0 --path=openshift-apiserver/audit-2021-03-09T00-12-19.834.log
出力例
{"kind":"Event","apiVersion":"audit.k8s.io/v1","level":"Metadata","auditID":"381acf6d-5f30-4c7d-8175-c9c317ae5893","stage":"ResponseComplete","requestURI":"/metrics","verb":"get","user":{"username":"system:serviceaccount:openshift-monitoring:prometheus-k8s","uid":"825b60a0-3976-4861-a342-3b2b561e8f82","groups":["system:serviceaccounts","system:serviceaccounts:openshift-monitoring","system:authenticated"]},"sourceIPs":["10.129.2.6"],"userAgent":"Prometheus/2.23.0","responseStatus":{"metadata":{},"code":200},"requestReceivedTimestamp":"2021-03-08T18:02:04.086545Z","stageTimestamp":"2021-03-08T18:02:04.107102Z","annotations":{"authorization.k8s.io/decision":"allow","authorization.k8s.io/reason":"RBAC: allowed by ClusterRoleBinding \"prometheus-k8s\" of ClusterRole \"prometheus-k8s\" to ServiceAccount \"prometheus-k8s/openshift-monitoring\""}}
Kubernetes API サーバーログを表示します。
各コントロールプレーンノードで利用可能な Kubernetes API サーバーログを一覧表示します。
$ oc adm node-logs --role=master --path=kube-apiserver/
出力例
ci-ln-m0wpfjb-f76d1-vnb5x-master-0 audit-2021-03-09T14-07-27.129.log ci-ln-m0wpfjb-f76d1-vnb5x-master-0 audit.log ci-ln-m0wpfjb-f76d1-vnb5x-master-1 audit-2021-03-09T19-24-22.620.log ci-ln-m0wpfjb-f76d1-vnb5x-master-1 audit.log ci-ln-m0wpfjb-f76d1-vnb5x-master-2 audit-2021-03-09T18-37-07.511.log ci-ln-m0wpfjb-f76d1-vnb5x-master-2 audit.log
ノード名とログ名を指定して、特定の Kubernetes API サーバーログを表示します。
$ oc adm node-logs <node_name> --path=kube-apiserver/<log_name>
以下に例を示します。
$ oc adm node-logs ci-ln-m0wpfjb-f76d1-vnb5x-master-0 --path=kube-apiserver/audit-2021-03-09T14-07-27.129.log
出力例
{"kind":"Event","apiVersion":"audit.k8s.io/v1","level":"Metadata","auditID":"cfce8a0b-b5f5-4365-8c9f-79c1227d10f9","stage":"ResponseComplete","requestURI":"/api/v1/namespaces/openshift-kube-scheduler/serviceaccounts/openshift-kube-scheduler-sa","verb":"get","user":{"username":"system:serviceaccount:openshift-kube-scheduler-operator:openshift-kube-scheduler-operator","uid":"2574b041-f3c8-44e6-a057-baef7aa81516","groups":["system:serviceaccounts","system:serviceaccounts:openshift-kube-scheduler-operator","system:authenticated"]},"sourceIPs":["10.128.0.8"],"userAgent":"cluster-kube-scheduler-operator/v0.0.0 (linux/amd64) kubernetes/$Format","objectRef":{"resource":"serviceaccounts","namespace":"openshift-kube-scheduler","name":"openshift-kube-scheduler-sa","apiVersion":"v1"},"responseStatus":{"metadata":{},"code":200},"requestReceivedTimestamp":"2021-03-08T18:06:42.512619Z","stageTimestamp":"2021-03-08T18:06:42.516145Z","annotations":{"authentication.k8s.io/legacy-token":"system:serviceaccount:openshift-kube-scheduler-operator:openshift-kube-scheduler-operator","authorization.k8s.io/decision":"allow","authorization.k8s.io/reason":"RBAC: allowed by ClusterRoleBinding \"system:openshift:operator:cluster-kube-scheduler-operator\" of ClusterRole \"cluster-admin\" to ServiceAccount \"openshift-kube-scheduler-operator/openshift-kube-scheduler-operator\""}}
OpenShift OAuth API サーバーログを表示します。
各コントロールプレーンノードで利用可能な OpenShift OAuth API サーバーログを一覧表示します。
$ oc adm node-logs --role=master --path=oauth-apiserver/
出力例
ci-ln-m0wpfjb-f76d1-vnb5x-master-0 audit-2021-03-09T13-06-26.128.log ci-ln-m0wpfjb-f76d1-vnb5x-master-0 audit.log ci-ln-m0wpfjb-f76d1-vnb5x-master-1 audit-2021-03-09T18-23-21.619.log ci-ln-m0wpfjb-f76d1-vnb5x-master-1 audit.log ci-ln-m0wpfjb-f76d1-vnb5x-master-2 audit-2021-03-09T17-36-06.510.log ci-ln-m0wpfjb-f76d1-vnb5x-master-2 audit.log
ノード名とログ名を指定して、特定の OpenShift OAuth API サーバーログを表示します。
$ oc adm node-logs <node_name> --path=oauth-apiserver/<log_name>
以下に例を示します。
$ oc adm node-logs ci-ln-m0wpfjb-f76d1-vnb5x-master-0 --path=oauth-apiserver/audit-2021-03-09T13-06-26.128.log
出力例
{"kind":"Event","apiVersion":"audit.k8s.io/v1","level":"Metadata","auditID":"dd4c44e2-3ea1-4830-9ab7-c91a5f1388d6","stage":"ResponseComplete","requestURI":"/apis/user.openshift.io/v1/users/~","verb":"get","user":{"username":"system:serviceaccount:openshift-monitoring:prometheus-k8s","groups":["system:serviceaccounts","system:serviceaccounts:openshift-monitoring","system:authenticated"]},"sourceIPs":["10.0.32.4","10.128.0.1"],"userAgent":"dockerregistry/v0.0.0 (linux/amd64) kubernetes/$Format","objectRef":{"resource":"users","name":"~","apiGroup":"user.openshift.io","apiVersion":"v1"},"responseStatus":{"metadata":{},"code":200},"requestReceivedTimestamp":"2021-03-08T17:47:43.653187Z","stageTimestamp":"2021-03-08T17:47:43.660187Z","annotations":{"authorization.k8s.io/decision":"allow","authorization.k8s.io/reason":"RBAC: allowed by ClusterRoleBinding \"basic-users\" of ClusterRole \"basic-user\" to Group \"system:authenticated\""}}
7.3. 監査ログのフィルター
jq
または別の JSON 解析ツールを使用して、API サーバー監査ログをフィルターできます。
API サーバー監査ログに記録する情報量は、設定される監査ログポリシーで制御できます。
以下の手順では、jq
を使用してコントロールプレーンノード node-1.example.com
で監査ログをフィルターする例を示します。jq
の使用についての詳細は、jq Manual を参照してください。
前提条件
-
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできる。 -
jq
がインストールされている。
手順
OpenShift API サーバー監査ログをユーザーでフィルターします。
$ oc adm node-logs node-1.example.com \ --path=openshift-apiserver/audit.log \ | jq 'select(.user.username == "myusername")'
OpenShift API サーバー監査ログをユーザーエージェントでフィルターします。
$ oc adm node-logs node-1.example.com \ --path=openshift-apiserver/audit.log \ | jq 'select(.userAgent == "cluster-version-operator/v0.0.0 (linux/amd64) kubernetes/$Format")'
Kubernetes API サーバー監査ログを特定の API バージョンでフィルターし、ユーザーエージェントのみを出力します。
$ oc adm node-logs node-1.example.com \ --path=kube-apiserver/audit.log \ | jq 'select(.requestURI | startswith("/apis/apiextensions.k8s.io/v1beta1")) | .userAgent'
動詞を除外して OpenShift OAuth API サーバー監査ログをフィルターします。
$ oc adm node-logs node-1.example.com \ --path=oauth-apiserver/audit.log \ | jq 'select(.verb != "get")'
7.4. 監査ログの収集
must-gather ツールを使用して、クラスターをデバッグするための監査ログを収集できます。このログは、確認したり、Red Hat サポートに送信したりできます。
手順
-- /usr/bin/gather_audit_logs
フラグを使用してoc adm must-gather
コマンドを実行します。$ oc adm must-gather -- /usr/bin/gather_audit_logs
作業ディレクトリーに作成された
must-gather
ディレクトリーから圧縮ファイルを作成します。たとえば、Linux オペレーティングシステムを使用するコンピューターで以下のコマンドを実行します。$ tar cvaf must-gather.tar.gz must-gather.local.472290403699006248 1
- 1
must-gather-local.472290403699006248
は、実際のディレクトリー名に置き換えます。
- 圧縮ファイルを Red Hat カスタマーポータル で作成したサポートケースに添付します。
7.5. 関連情報
第8章 監査ログポリシーの設定
使用する監査ログポリシープロファイルを選択して、API サーバー監査ログに記録する情報量を制御できます。
8.1. 監査ログポリシープロファイルについて
監査ログプロファイルは、OpenShift API サーバー、Kubernetes API サーバー、および OAuth API サーバーに送信される要求をログに記録する方法を定義します。
OpenShift Container Platform は、以下の事前定義された監査ポリシープロファイルを提供します。
プロファイル | 説明 |
---|---|
| 読み取りおよび書き込み要求のメタデータのみをログに記録します。OAuth アクセストークンの作成 (ログイン) 要求を除く要求の本文はログに記録されません。これはデフォルトポリシーになります。 |
|
すべての要求のメタデータをロギングする以外にも、API サーバーへの書き込み要求ごとに要求の本文をログに記録します ( |
|
すべての要求のメタデータをロギングする以外にも、API サーバーへの読み取りおよび書き込み要求ごとに要求の本文をログに記録します ( |
-
Secret
、Route
、OAuthClient
オブジェクトなどの機密リソースは、メタデータレベルを超えるとログに記録されません。クラスターが OpenShift Container Platform 4.5 からアップグレードされた場合、OAuth トークンのオブジェクト名にシークレット情報が含まれる可能性があるため、OAuth トークンはいっさいログに記録されません。
デフォルトで、OpenShift Container Platform は Default
監査ログプロファイルを使用します。要求の本文もログに記録する別の監査ポリシープロファイルを使用できますが、リソース使用の増加について把握するようにしてください (CPU、メモリー、および I/O)。
8.2. 監査ログポリシーの設定
API サーバーに送信される要求をログに記録する際に使用する監査ログポリシーを設定できます。
前提条件
-
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできる。
手順
APIServer
リソースを編集します。$ oc edit apiserver cluster
spec.audit.profile
フィールドを更新します。apiVersion: config.openshift.io/v1 kind: APIServer metadata: ... spec: audit: profile: WriteRequestBodies 1
- 1
Default
、WriteRequestBodies
、またはAllRequestBodies
に設定されます。デフォルトのプロファイルはDefault
です。
- 変更を適用するためにファイルを保存します。
Kubernetes API サーバー Pod の新規リビジョンがロールアウトされていることを確認します。これには数分の時間がかかります。
$ oc get kubeapiserver -o=jsonpath='{range .items[0].status.conditions[?(@.type=="NodeInstallerProgressing")]}{.reason}{"\n"}{.message}{"\n"}'
Kubernetes API サーバーの
NodeInstallerProgressing
状況条件を確認し、すべてのノードが最新のリビジョンであることを確認します。更新が正常に実行されると、この出力にはAllNodesAtLatestRevision
が表示されます。AllNodesAtLatestRevision 3 nodes are at revision 12 1
- 1
- この例では、最新のリビジョン番号は
12
です。
出力に以下のようなメッセージが表示されると、これは更新が進行中であることを意味します。数分待機した後に再試行します。
-
3 nodes are at revision 11; 0 nodes have achieved new revision 12
-
2 nodes are at revision 11; 1 nodes are at revision 12
第9章 TLS セキュリティープロファイルの設定
TLS セキュリティープロファイルは、サーバーへの接続時に、クライアントが使用できる暗号を規制する方法をサーバーに提供します。これにより、OpenShift Container Platform コンポーネントは暗号化ライブラリーを使用するようになり、既知の安全ではないプロトコル、暗号、またはアルゴリズムを拒否します。
クラスター管理者は、以下のコンポーネントごとに使用する TLS セキュリティープロファイルを選択できます。
- Ingress コントローラー
コントロールプレーン
これには、Kubernetes API サーバー、OpenShift API サーバー、OpenShift OAuth API サーバー、および OpenShift OAuth サーバーが含まれます。
9.1. TLS セキュリティープロファイルについて
TLS (Transport Layer Security) セキュリティープロファイルを使用して、さまざまな OpenShift Container Platform コンポーネントに必要な TLS 暗号を定義できます。OpenShift Container Platform の TLS セキュリティープロファイルは、Mozilla が推奨する設定 に基づいています。
コンポーネントごとに、以下の TLS セキュリティープロファイルのいずれかを指定できます。
プロファイル | 説明 |
---|---|
| このプロファイルは、レガシークライアントまたはライブラリーでの使用を目的としています。このプロファイルは、Old 後方互換性 の推奨設定に基づいています。
注記 Ingress コントローラーの場合、TLS の最小バージョンは 1.0 から 1.1 に変換されます。 |
| このプロファイルは、大多数のクライアントに推奨される設定です。これは、Ingress コントローラーおよびコントロールプレーンのデフォルトの TLS セキュリティープロファイルです。このプロファイルは、Intermediate 互換性 の推奨設定に基づいています。
|
| このプロファイルは、後方互換性を必要としない Modern のクライアントでの使用を目的としています。このプロファイルは、Modern 互換性 の推奨設定に基づいています。
注記
OpenShift Container Platform 4.6、4.7、および 4.8 では、 重要
|
| このプロファイルを使用すると、使用する TLS バージョンと暗号を定義できます。 警告
無効な設定により問題が発生する可能性があるため、 注記
OpenShift Container Platform ルーターは、Red Hat 分散の OpenSSL デフォルトセットの TLS |
事前定義されたプロファイルタイプのいずれかを使用する場合、有効なプロファイル設定はリリース間で変更される可能性があります。たとえば、リリース X.Y.Z にデプロイされた Intermediate プロファイルを使用する仕様がある場合、リリース X.Y.Z+1 へのアップグレードにより、新規のプロファイル設定が適用され、ロールアウトが生じる可能性があります。
9.2. TLS セキュリティープロファイルの詳細表示
Ingress コントローラーおよびコントロールプレーンコンポーネントごとに事前定義された TLS セキュリティープロファイルの最小 TLS バージョンおよび暗号を表示できます。
プロファイルの最小 TLS バージョンと暗号の一覧は、コンポーネントによって異なる場合があります。
手順
特定の TLS セキュリティープロファイルの詳細を表示します。
$ oc explain <component>.spec.tlsSecurityProfile.<profile> 1
- 1
<component>
には、ingresscontroller
またはapiserver
を指定します。<profile>
には、old
、intermediate
またはcustom
を指定します。
たとえば、コントロールプレーンの
intermediate
プロファイルに含まれる暗号を確認するには、以下を実行します。$ oc explain apiserver.spec.tlsSecurityProfile.intermediate
出力例
KIND: APIServer VERSION: config.openshift.io/v1 DESCRIPTION: intermediate is a TLS security profile based on: https://wiki.mozilla.org/Security/Server_Side_TLS#Intermediate_compatibility_.28recommended.29 and looks like this (yaml): ciphers: - TLS_AES_128_GCM_SHA256 - TLS_AES_256_GCM_SHA384 - TLS_CHACHA20_POLY1305_SHA256 - ECDHE-ECDSA-AES128-GCM-SHA256 - ECDHE-RSA-AES128-GCM-SHA256 - ECDHE-ECDSA-AES256-GCM-SHA384 - ECDHE-RSA-AES256-GCM-SHA384 - ECDHE-ECDSA-CHACHA20-POLY1305 - ECDHE-RSA-CHACHA20-POLY1305 - DHE-RSA-AES128-GCM-SHA256 - DHE-RSA-AES256-GCM-SHA384 minTLSVersion: TLSv1.2
コンポーネントの
tlsSecurityProfile
フィールドの詳細をすべて表示します。$ oc explain <component>.spec.tlsSecurityProfile 1
- 1
<component>
には、ingresscontroller
またはapiserver
を指定します。
たとえば、Ingress コントローラーの
tlsSecurityProfile
フィールドの詳細をすべて確認するには、以下を実行します。$ oc explain ingresscontroller.spec.tlsSecurityProfile
出力例
KIND: IngressController VERSION: operator.openshift.io/v1 RESOURCE: tlsSecurityProfile <Object> DESCRIPTION: ... FIELDS: custom <> custom is a user-defined TLS security profile. Be extremely careful using a custom profile as invalid configurations can be catastrophic. An example custom profile looks like this: ciphers: - ECDHE-ECDSA-CHACHA20-POLY1305 - ECDHE-RSA-CHACHA20-POLY1305 - ECDHE-RSA-AES128-GCM-SHA256 - ECDHE-ECDSA-AES128-GCM-SHA256 minTLSVersion: TLSv1.1 intermediate <> intermediate is a TLS security profile based on: https://wiki.mozilla.org/Security/Server_Side_TLS#Intermediate_compatibility_.28recommended.29 and looks like this (yaml): ... 1 modern <> modern is a TLS security profile based on: https://wiki.mozilla.org/Security/Server_Side_TLS#Modern_compatibility and looks like this (yaml): ... 2 NOTE: Currently unsupported. old <> old is a TLS security profile based on: https://wiki.mozilla.org/Security/Server_Side_TLS#Old_backward_compatibility and looks like this (yaml): ... 3 type <string> ...
9.3. Ingress コントローラーの TLS セキュリティープロファイルの設定
Ingress コントローラーの TLS セキュリティープロファイルを設定するには、IngressController
カスタムリソース (CR) を編集して、事前定義済みまたはカスタムの TLS セキュリティープロファイルを指定します。TLS セキュリティープロファイルが設定されていない場合、デフォルト値は API サーバーに設定された TLS セキュリティープロファイルに基づいています。
Old
TLS のセキュリティープロファイルを設定するサンプル IngressController
CR
apiVersion: operator.openshift.io/v1 kind: IngressController ... spec: tlsSecurityProfile: old: {} type: Old ...
TLS セキュリティープロファイルは、Ingress コントローラーの TLS 接続の最小 TLS バージョンと TLS 暗号を定義します。
設定された TLS セキュリティープロファイルの暗号と最小 TLS バージョンは、Status.Tls Profile
配下の IngressController
カスタムリソース (CR) と Spec.Tls Security Profile
配下の設定された TLS セキュリティープロファイルで確認できます。Custom
TLS セキュリティープロファイルの場合、特定の暗号と最小 TLS バージョンは両方のパラメーターの下に一覧表示されます。
HAProxy Ingress コントローラーイメージは TLS 1.3
をサポートしません。Modern
プロファイルには TLS 1.3
が必要であることから、これはサポートされません。Ingress Operator は Modern
プロファイルを Intermediate
に変換します。また、Ingress Operator は TLS 1.0
の Old
または Custom
プロファイルを 1.1
に変換し、TLS 1.3
の Custom
プロファイルを 1.2
に変換します。
前提条件
-
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできる。
手順
openshift-ingress-operator
プロジェクトのIngressController
CR を編集して、TLS セキュリティープロファイルを設定します。$ oc edit IngressController default -n openshift-ingress-operator
spec.tlsSecurityProfile
フィールドを追加します。Custom
プロファイルのサンプルIngressController
CRapiVersion: operator.openshift.io/v1 kind: IngressController ... spec: tlsSecurityProfile: type: Custom 1 custom: 2 ciphers: 3 - ECDHE-ECDSA-CHACHA20-POLY1305 - ECDHE-RSA-CHACHA20-POLY1305 - ECDHE-RSA-AES128-GCM-SHA256 - ECDHE-ECDSA-AES128-GCM-SHA256 minTLSVersion: VersionTLS11 ...
- 変更を適用するためにファイルを保存します。
検証
IngressController
CR にプロファイルが設定されていることを確認します。$ oc describe IngressController default -n openshift-ingress-operator
出力例
Name: default Namespace: openshift-ingress-operator Labels: <none> Annotations: <none> API Version: operator.openshift.io/v1 Kind: IngressController ... Spec: ... Tls Security Profile: Custom: Ciphers: ECDHE-ECDSA-CHACHA20-POLY1305 ECDHE-RSA-CHACHA20-POLY1305 ECDHE-RSA-AES128-GCM-SHA256 ECDHE-ECDSA-AES128-GCM-SHA256 Min TLS Version: VersionTLS11 Type: Custom ...
9.4. コントロールプレーンの TLS セキュリティープロファイルの設定
コントロールプレーンの TLS セキュリティープロファイルを設定するには、APIServer
カスタムリソース (CR) を編集して、事前定義済みまたはカスタムの TLS セキュリティープロファイルを指定します。APIServer
CR に TLS セキュリティープロファイルを設定すると、設定は以下のコントロールプレーンのコンポーネントに伝播されます。
- Kubernetes API サーバー
- OpenShift API サーバー
- OpenShift OAuth API サーバー
- OpenShift OAuth サーバー
TLS セキュリティープロファイルが設定されていない場合には、TLS セキュリティープロファイルは Intermediate
になります。
Ingress コントローラーのデフォルトの TLS セキュリティープロファイルは API サーバーの TLS セキュリティープロファイルに基づいています。
Old
TLS のセキュリティープロファイルを設定するサンプル APIServer
CR
apiVersion: config.openshift.io/v1 kind: APIServer ... spec: tlsSecurityProfile: old: {} type: Old ...
TLS セキュリティープロファイルは、コントロールプレーンのコンポーネントとの通信に必要な TLS の最小バージョンと TLS 暗号を定義します。
設定した TLS セキュリティープロファイルは、Spec.Tls Security Profile
の APIServer
カスタムリソース (CR) で確認できます。Custom
TLS セキュリティープロファイルの場合には、特定の暗号と最小 TLS バージョンが一覧表示されます。
コントロールプレーンは、最小 TLS バージョンとして TLS 1.3
をサポートしません。Modern
プロファイルは TLS 1.3
を必要とするため、サポート対象外です。
前提条件
-
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできる。
手順
デフォルトの
APIServer
CR を編集して TLS セキュリティープロファイルを設定します。$ oc edit APIServer cluster
spec.tlsSecurityProfile
フィールドを追加します。Custom
プロファイルのAPIServer
CR のサンプルapiVersion: config.openshift.io/v1 kind: APIServer metadata: name: cluster spec: tlsSecurityProfile: type: Custom 1 custom: 2 ciphers: 3 - ECDHE-ECDSA-CHACHA20-POLY1305 - ECDHE-RSA-CHACHA20-POLY1305 - ECDHE-RSA-AES128-GCM-SHA256 - ECDHE-ECDSA-AES128-GCM-SHA256 minTLSVersion: VersionTLS11
- 変更を適用するためにファイルを保存します。
検証
TLS セキュリティープロファイルが
APIServer
CR に設定されていることを確認します。$ oc describe apiserver cluster
出力例
Name: cluster Namespace: ... API Version: config.openshift.io/v1 Kind: APIServer ... Spec: Audit: Profile: Default Tls Security Profile: Custom: Ciphers: ECDHE-ECDSA-CHACHA20-POLY1305 ECDHE-RSA-CHACHA20-POLY1305 ECDHE-RSA-AES128-GCM-SHA256 ECDHE-ECDSA-AES128-GCM-SHA256 Min TLS Version: VersionTLS11 Type: Custom ...
第10章 seccomp プロファイルの設定
OpenShift Container Platform コンテナーまたは Pod は、1 つ以上の明確に定義されたタスクを実行するアプリケーションを 1 つ実行します。アプリケーションには通常、基礎となるオペレーティングシステムカーネル API の小規模なサブセットのみが必要です。seccomp のセキュアコンピューティングモードは Linux カーネル機能で、これを使用して、コンテナーで実行されているプロセスを制限して、利用可能なシステム呼び出しのサブセットだけが呼び出されるようにできます。これらのシステム呼び出しは、コンテナーまたは Pod に適用されるプロファイルを作成して設定できます。seccomp プロファイルは、ディスクに JSON ファイルとして保存されます。
seccomp プロファイルが適用されていない場合は、OpenShift ワークロードはデフォルトでは制限なしに実行されます。
seccomp プロファイルは特権付きコンテナーに適用できません。
10.1. すべての Pod のデフォルトの seccomp プロファイルを有効にする
OpenShift Container Platform には、デフォルトの seccomp プロファイルが同梱されており、runtime/default
として参照されます。カスタムセキュリティーコンテキスト制約 (SCC) を作成することで、Pod またはコンテナーワークロードのデフォルトの seccomp プロファイルを有効にすることができます。
カスタム SCC を作成する必要があります。デフォルトの SCC は編集しないでください。デフォルトの SCC を編集すると、プラットフォームの Pod をデプロイ時または OpenShift Container Platform のアップグレード時に問題が発生する可能性があります。詳細は、「デフォルトのセキュリティーコンテキストの制約」セクションを参照してください。
以下の手順に従って、すべての Pod に対してデフォルトの seccomp プロファイルを有効にします。
使用可能な
restricted
SCC を yaml ファイルにエクスポートします。$ oc get scc restricted -o yaml > restricted-seccomp.yaml
作成された
restricted
SCC yaml ファイルを編集します。$ vi restricted-seccomp.yaml
次の例に示すように更新します。
kind: SecurityContextConstraints metadata: name: restricted 1 <..snip..> seccompProfiles: 2 - runtime/default 3
カスタム SCC を作成します。
$ oc create -f restricted-seccomp.yaml
予想される出力
securitycontextconstraints.security.openshift.io/restricted-seccomp created
カスタム SCC を ServiceAccount に追加します。
$ oc adm policy add-scc-to-user restricted-seccomp -z default
注記デフォルトのサービスアカウントは、ユーザーが別のアカウントを設定しない限り適用される ServiceAccount です。OpenShift Container Platform は、SCC の情報に基づいて Pod の seccomp プロファイルを設定します。
予想される出力
clusterrole.rbac.authorization.k8s.io/system:openshift:scc:restricted-seccomp added: "default"
OpenShift Container Platform 4.6 では、Pod アノテーション seccomp.security.alpha.kubernetes.io/pod: runtime/default
および container.seccomp.security.alpha.kubernetes.io/<container_name>: runtime/default
を追加する機能は非推奨となりました。
10.2. カスタム seccomp プロファイルの設定
カスタム seccomp プロファイルを設定すると、アプリケーション要件に基づいてフィルターを更新できます。これにより、クラスター管理者は OpenShift Container Platform で実行されるワークロードのセキュリティーをより詳細に制御できます。
10.2.1. カスタム seccomp プロファイルのセットアップ
前提条件
- クラスター管理者パーミッションがある。
- カスタム SCC(Security Context Constraints) を作成している。詳細は、関連情報を参照してください。
- カスタム seccomp プロファイルを作成している。
手順
-
Machine Config を使用してカスタム seccomp プロファイルを
/var/lib/kubelet/seccomp/<custom-name>.json
にアップロードします。詳細な手順については、関連情報を参照してください。 作成されたカスタム seccomp プロファイルへの参照を指定してカスタム SCC を更新します。
seccompProfiles: - localhost/<custom-name>.json 1
- 1
- カスタム seccomp プロファイルの名前を入力します。
10.2.2. カスタム seccomp プロファイルのワークロードへの適用
前提条件
- クラスター管理者はカスタム seccomp プロファイルを設定している。詳細は、カスタム seccomp プロファイルの設定を参照してください。
手順
securityContext.seccompProfile.type
フィールドを次のように設定して、seccomp プロファイルをワークロードに適用します。例
spec: securityContext: seccompProfile: type: Localhost localhostProfile: <custom-name>.json 1
- 1
- カスタム seccomp プロファイルの名前を入力します。
または、Pod アノテーション
seccomp.security.alpha.kubernetes.io/pod: localhost/<custom-name>.json
を使用できます。ただし、この手法は OpenShift Container Platform 4.6 では非推奨です。
デプロイメント時に、受付コントローラーは以下を検証します。
- 現在の SCC に対するアノテーションがユーザーロールで許可されている。
- seccomp プロファイルを含む SCC が Pod で許可されている。
SCC が Pod で許可される場合には、kubelet は指定された seccomp プロファイルで Pod を実行します。
seccomp プロファイルがすべてのワーカーノードにデプロイされていることを確認します。
カスタム SCC は、Pod に適切な優先順位で自動的に割り当てられるか、または CAP_NET_ADMIN を許可するなど、Pod で必要な他の条件を満たす必要があります。
10.3. 関連情報
第11章 追加ホストから API サーバーへの JavaScript ベースのアクセスの許可
11.1. 追加ホストから API サーバーへの JavaScript ベースのアクセスの許可
デフォルトの OpenShift Container Platform 設定は、OpenShift Web コンソールが要求を API サーバーに送信することのみを許可します。
別の名前を使用して JavaScript アプリケーションから API サーバーまたは OAuth サーバーにアクセスする必要がある場合、許可する追加のホスト名を設定できます。
前提条件
-
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできる。
手順
APIServer
リソースを編集します。$ oc edit apiserver.config.openshift.io cluster
additionalCORSAllowedOrigins
フィールドをspec
セクションの下に追加し、1 つ以上の追加のホスト名を指定します。apiVersion: config.openshift.io/v1 kind: APIServer metadata: annotations: release.openshift.io/create-only: "true" creationTimestamp: "2019-07-11T17:35:37Z" generation: 1 name: cluster resourceVersion: "907" selfLink: /apis/config.openshift.io/v1/apiservers/cluster uid: 4b45a8dd-a402-11e9-91ec-0219944e0696 spec: additionalCORSAllowedOrigins: - (?i)//my\.subdomain\.domain\.com(:|\z) 1
- 1
- ホスト名は Golang 正規表現 として指定されます。これは、API サーバーおよび OAuth サーバーに対する HTTP 要求の CORS ヘッダーに対するマッチングを行うために使用されます。
注記この例では、以下の構文を使用します。
-
(?i)
は大文字/小文字を区別します。 -
//
はドメインの開始にピニングし、http:
またはhttps:
の後のダブルスラッシュに一致します。 -
\.
はドメイン名のドットをエスケープします。 -
(:|\z)
はドメイン名(\z)
またはポートセパレーター(:)
の終了部に一致します。
- 変更を適用するためにファイルを保存します。
第12章 etcd データの暗号化
12.1. etcd 暗号化について
デフォルトで、etcd データは OpenShift Container Platform で暗号化されません。クラスターの etcd 暗号化を有効にして、データセキュリティーのレイヤーを追加で提供することができます。たとえば、etcd バックアップが正しくない公開先に公開される場合に機密データが失われないように保護することができます。
etcd の暗号化を有効にすると、以下の OpenShift API サーバーおよび Kubernetes API サーバーリソースが暗号化されます。
- シークレット
- 設定マップ
- ルート
- OAuth アクセストークン
- OAuth 認証トークン
etcd 暗号を有効にすると、暗号化キーが作成されます。これらのキーは週ごとにローテーションされます。etcd バックアップから復元するには、これらのキーが必要です。
etcd 暗号化はキーではなく値のみを暗号化することに注意してください。つまり、リソースタイプ、namespace、およびオブジェクト名は暗号化されません。
12.2. etcd 暗号化の有効化
etcd 暗号化を有効にして、クラスターで機密性の高いリソースを暗号化できます。
初期の暗号化プロセスが完了するまでは、etcd のバックアップを取ることは推奨されません。暗号化プロセスが完了しない場合、バックアップは部分的にのみ暗号化される可能性があります。
前提条件
-
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできる。
手順
APIServer
オブジェクトを変更します。$ oc edit apiserver
encryption
フィールドタイプをaescbc
に設定します。spec: encryption: type: aescbc 1
- 1
aescbc
タイプは、暗号化を実行するために PKCS#7 パディングを実装している AES-CBC と 32 バイトのキーが使用されることを意味します。
変更を適用するためにファイルを保存します。
暗号化プロセスが開始されます。クラスターのサイズによっては、このプロセスが完了するまで 20 分以上かかる場合があります。
etcd 暗号化が正常に行われたことを確認します。
OpenShift API サーバーの
Encrypted
ステータスを確認し、そのリソースが正常に暗号化されたことを確認します。$ oc get openshiftapiserver -o=jsonpath='{range .items[0].status.conditions[?(@.type=="Encrypted")]}{.reason}{"\n"}{.message}{"\n"}'
この出力には、暗号化が正常に実行されると
EncryptionCompleted
が表示されます。EncryptionCompleted All resources encrypted: routes.route.openshift.io, oauthaccesstokens.oauth.openshift.io, oauthauthorizetokens.oauth.openshift.io
出力に
EncryptionInProgress
が表示される場合、これは暗号化が進行中であることを意味します。数分待機した後に再試行します。Kubernetes API サーバーの
Encrypted
ステータス状態を確認し、そのリソースが正常に暗号化されたことを確認します。$ oc get kubeapiserver -o=jsonpath='{range .items[0].status.conditions[?(@.type=="Encrypted")]}{.reason}{"\n"}{.message}{"\n"}'
この出力には、暗号化が正常に実行されると
EncryptionCompleted
が表示されます。EncryptionCompleted All resources encrypted: secrets, configmaps
出力に
EncryptionInProgress
が表示される場合、これは暗号化が進行中であることを意味します。数分待機した後に再試行します。
12.3. etcd 暗号化の無効化
クラスターで etcd データの暗号化を無効にできます。
前提条件
-
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできる。
手順
APIServer
オブジェクトを変更します。$ oc edit apiserver
encryption
フィールドタイプをidentity
に設定します。spec: encryption: type: identity 1
- 1
identity
タイプはデフォルト値であり、暗号化は実行されないことを意味します。
変更を適用するためにファイルを保存します。
復号化プロセスが開始されます。クラスターのサイズによっては、このプロセスが完了するまで 20 分以上かかる場合があります。
etcd の復号化が正常に行われたことを確認します。
OpenShift API サーバーの
Encrypted
ステータス条件を確認し、そのリソースが正常に暗号化されたことを確認します。$ oc get openshiftapiserver -o=jsonpath='{range .items[0].status.conditions[?(@.type=="Encrypted")]}{.reason}{"\n"}{.message}{"\n"}'
この出力には、復号化が正常に実行されると
DecryptionCompleted
が表示されます。DecryptionCompleted Encryption mode set to identity and everything is decrypted
出力に
DecryptionInProgress
が表示される場合、これは復号化が進行中であることを意味します。数分待機した後に再試行します。Kubernetes API サーバーの
Encrypted
ステータス状態を確認し、そのリソースが正常に復号化されたことを確認します。$ oc get kubeapiserver -o=jsonpath='{range .items[0].status.conditions[?(@.type=="Encrypted")]}{.reason}{"\n"}{.message}{"\n"}'
この出力には、復号化が正常に実行されると
DecryptionCompleted
が表示されます。DecryptionCompleted Encryption mode set to identity and everything is decrypted
出力に
DecryptionInProgress
が表示される場合、これは復号化が進行中であることを意味します。数分待機した後に再試行します。
第13章 Pod の脆弱性のスキャン
Red Hat Quay Container Security Operator を使用すると、OpenShift Container Platform Web コンソールから、クラスターのアクティブな Pod で使用されるコンテナーイメージについての脆弱性スキャンの結果にアクセスできます。The Red Hat Quay Container Security Operator:
- すべての namespace または指定された namespace の Pod に関連付けられたコンテナーを監視します。
- イメージのレジストリーがイメージスキャンを実行している場合 (例: Quay.io、Clair スキャンを含む Red Hat Quay レジストリーなど)、脆弱性の情報についてコンテナーの出所となったコンテナーレジストリーをクエリーします。
-
Kubernetes API の
ImageManifestVuln
オブジェクトを使用して脆弱性を公開します。
ここでの手順を使用すると、Red Hat Quay Container Security Operator は openshift-operators
namespace にインストールされるため、OpenShift Container Platform クラスター上のすべての namespace で使用できます。
13.1. Red Hat Quay Container Security Operator の実行
以下で説明されているように、Operator Hub から Operator を選択し、インストールして、OpenShift Container Platform Web コンソールから Red Hat Quay Container Security Operator を起動できます。
前提条件
- OpenShift Container Platform クラスターへの管理者権限がある
- クラスターで実行される Red Hat Quay または Quay.io レジストリーのコンテナーがある
手順
- Operators → OperatorHub に移動し、Security を選択します。
- Container Security Operator を選択し、Install を選択して Create Operator Subscription ページに移動します。
- 設定を確認します。すべての namespace および自動承認ストラテジーがデフォルトで選択されます。
- Install を選択します。Container Security Operator は、Installed Operators 画面に数分後に表示されます。
オプション: カスタム証明書を Red Hat Quay Container Security Operator に追加できます。以下の例では、現在のディレクトリーに
quay.crt
という名前の証明書を作成します。次に、次のコマンドを実行して、証明書を Red Hat Quay Container Security Operator に追加します。$ oc create secret generic container-security-operator-extra-certs --from-file=quay.crt -n openshift-operators
- カスタム証明書を追加した場合、新規証明書を有効にするために Operator Pod を再起動します。
OpenShift Dashboard を開きます (
Home
→Overview
)。Quay Image Security へのリンクが status セクションに表示され、これまでに見つかった脆弱性の数の一覧が表示されます。以下の図のように、リンクを選択して Quay Image Security breakdown を表示します。この時点で、検出された脆弱性をフォローするために以下の 2 つのいずれかの操作を実行できます。
脆弱性へのリンクを選択します。コンテナーを取得したコンテナーレジストリーにアクセスし、脆弱性についての情報を確認できます。以下の図は、Quay.io レジストリーから検出された脆弱性の例を示しています。
namespaces リンクを選択し、ImageManifestVuln 画面に移動します。ここでは、選択されたイメージの名前、およびイメージが実行されているすべての namespace を確認できます。以下の図は、特定の脆弱なイメージが
quay-enterprise
namespace で実行されていることを示しています。
この時点では、脆弱性のあるイメージや、イメージの脆弱性を解決するために必要なこと、およびイメージが実行されたすべての namespace を確認できます。以下を実行することができます。
- 脆弱性を修正する必要のあるイメージを実行しているユーザーに警告します。
- イメージが置かれている Pod を起動したデプロイメントまたは他のオブジェクトを削除して、イメージの実行を停止します。
Pod を削除すると、Dashboard で脆弱性のある状態がリセットされるまで数分かかる場合があります。
13.2. CLI でのイメージ脆弱性のクエリー
oc
コマンドを使用して、Red Hat Quay Container Security Operator によって検出される脆弱性についての情報を表示できます。
前提条件
- OpenShift Container Platform インスタンスで Red Hat QuayContainer Security Operator を実行している
手順
検出されたコンテナーイメージの脆弱性についてクエリーするには、以下を入力します。
$ oc get vuln --all-namespaces
出力例
NAMESPACE NAME AGE default sha256.ca90... 6m56s skynet sha256.ca90... 9m37s
特定の脆弱性の詳細を表示するには、脆弱性の名前およびその namespace を
oc describe
コマンドに指定します。以下の例は、イメージに脆弱性のある RPM パッケージが含まれるアクティブなコンテナーを示しています。$ oc describe vuln --namespace mynamespace sha256.ac50e3752...
出力例
Name: sha256.ac50e3752... Namespace: quay-enterprise ... Spec: Features: Name: nss-util Namespace Name: centos:7 Version: 3.44.0-3.el7 Versionformat: rpm Vulnerabilities: Description: Network Security Services (NSS) is a set of libraries...