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

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

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

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

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

コンテナー化されたアプリケーションがデプロイされ、実行され、管理される方法を自動化することは、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 に効率的に統合し、各種テクノロジーをお客様の個々のニーズに適応させる点においても多くの経験があります。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

コンテナーの署名の検証を有効にするには、レジストリー URL を sigstore にリンクし、次にイメージを検証するキーを指定するためのファイルが必要です。

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

FIPS コンプライアンスは、安全な環境で必要とされる最も重要なコンポーネントの 1 つであり、サポートされている暗号化技術のみがノード上で許可されるようにします。

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

アプリケーションとインフラストラクチャーは、すぐに利用できるコンポーネントで設定されています。その多くは、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 で使用されるコンテナーイメージをチェックするために追加できます。

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

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

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

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

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

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

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

quality.images.openshift.io/<qualityType>.<providerId>: {}

quality.images.openshift.io/vulnerability.blackduck: {}
quality.images.openshift.io/vulnerability.jfrog: {}
quality.images.openshift.io/license.blackduck: {}
quality.images.openshift.io/vulnerability.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 }
  ]
}

{
  "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 }
  ]
}

$ 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 } ]" }'

annotations:
  images.openshift.io/deny-execution: true

$ 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> }'

{
"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}] }"
    }
  }
}

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

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

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

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

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 を検索できます。

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

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

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

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 で実行されているイメージの脆弱性を確認できます。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

{
    "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 オブジェクトを使用して実行するのが最適な方法です。この例では、以下のルールを実施しています。

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

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 とも呼ばれます。

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 ファイルはコンテナーのランタイムで動的に読み込まれるため、サービスを再起動する必要はありません。

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

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

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

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

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

マルチテナンシーは、複数のユーザーによって所有され、複数のホストおよび 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 アクセスを提供するために割り当てることのできるデフォルトのクラスターロールがあります。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

クラスター管理者は、関連するイベントを判別できるように イベント のリソースタイプについて理解し、システムイベントの一覧を確認することをお勧めします。イベントは、関連するリソースの 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

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

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

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

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

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

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

関連情報

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

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

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

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

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

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

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

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

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

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

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

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

必要に応じて、以下の手順でサービス 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-----

関連情報

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

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

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

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

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

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

関連情報

プロキシー証明書により、ユーザーは 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-----

関連情報

インストーラー設定の 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-----
...

ユーザーによって提供される信頼バンドルは、設定マップとして表現されます。設定マップは、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 ドキュメントの 共有システム証明書の使用 を参照してください。

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

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

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

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

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

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

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

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

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

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

カスタムの有効期限はサポートされません。自己署名 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) からの証明書です。クラスターがインストールされると、ノード証明書は自動的にローテーションされます。

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

関連情報

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

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

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

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

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

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

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

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

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

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

関連情報

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 の証明書を更新しません。これらの証明書は、ユーザーがサブスクリプション設定で管理する必要があります。

アプリケーションは通常 <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 証明書をクライアントに分散せずに、クライアントにアプリケーションにアクセスさせる必要がある場合があります。管理者は、アプリケーションコンテンツを提供する際にカスタムのデフォルト証明書を設定する必要があります。

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

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

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

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

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

関連情報

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

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 コントローラーの名前です)。

空の 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 を使用します。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

コンプライアンス Operator は、次のコンプライアンスプロファイルを提供します。

Operator が正常にインストールされていない場合、以下を実行します。

Center for Internet Security (CIS) プロファイルを使用してスキャンを実行できます。便宜上、コンプライアンス Operator は起動時に適切なデフォルト値を持つ ScanSetting オブジェクトを作成します。この ScanSetting オブジェクトの名前は default です。

結果サーバー Pod は、生の Asset Reporting Format (ARF) スキャン結果を格納する永続ボリューム (PV) をマウントします。nodeSelector 属性および tolerations 属性を使用すると、結果サーバー Pod の場所を設定できます。

これは、コントロールプレーンノードが永続ボリュームをマウントすることを許可されていない環境で役立ちます。

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

セキュリティーコンテンツは、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

それぞれの ProfileBundle はデプロイメントでサポートされます。コンプライアンス Operator がコンテナーイメージダイジェストが変更されたことを検知すると、デプロイメントは変更を反映し、コンテンツを再び解析するように更新されます。タグの代わりにダイジェストを使用すると、安定した予測可能なプロファイルセットを使用できます。

contentImage 参照は有効な ImageStreamTag を参照し、コンプライアンス Operator はコンテンツを自動的に最新の状態に維持します。

$ 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

この ProfileBundle はイメージを追跡し、これに適用される変更 (異なるハッシュを参照するようにタグを更新するなど) は ProfileBundle にただちに反映されます。

バンドルオブジェクトには、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

TailoredProfile CR は最も一般的なテーラリング操作を有効にする一方で、XCCDF 標準は OpenSCAP プロファイルの調整におけるより多くの柔軟性を提供します。さらに、組織が以前に OpenScap を使用していた場合、既存の XCCDF テーラリングファイルが存在し、これを再利用できる可能性があります。

ComplianceSuite オブジェクトには、カスタムのテーラリングファイルにポイントできるオプションの TailoringConfigMap 属性が含まれます。TailoringConfigMap 属性の値は設定マップの名前です。これには、tailoring.xml というキーが含まれる必要があり、このキーの値はテーラリングのコンテンツです。

デフォルトで、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 属性に保存されます。

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 属性はそのファイルの内容を指定します。

以下の 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

カスタム MachineConfigPool を作成するときは、MachineConfigPool にラベルを追加して、KubeletConfig に存在する machineConfigPoolSelector がそのラベルを MachineConfigPool と一致させることができるようにします。

ブール値の属性 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 を設定します。

通常、プラットフォームスキャンをチェックする場合、以下の 2 つの理由のために管理者が手動で修復する必要があります。

新しいバージョンのコンプライアンスコンテンツが使用されると、以前のバージョンとは異なる新しいバージョンの修復が提供される可能性があります。コンプライアンス Operator は、適用される修復の以前のバージョンを保持します。OpenShift Container Platform の管理者は、確認し、適用する新規バージョンについても通知されます。以前に適用されたものの、更新された ComplianceRemediation オブジェクトはそのステータスを Outdated に変更します。古いオブジェクトには簡単に検索できるようにラベルが付けられます。

以前に適用された修復内容は ComplianceRemediation オブジェクトの spec.outdated 属性に保存され、新規に更新された内容は spec.current 属性に保存されます。コンテンツを新しいバージョンに更新した後に、管理者は修復を確認する必要があります。spec.outdated 属性が存在する限り、これは結果として作成される MachineConfig オブジェクトをレンダリングするために使用されます。spec.outdated 属性が削除された後に、コンプライアンス Operator は結果として生成される MachineConfig オブジェクトを再度レンダリングし、これにより Operator は設定をノードにプッシュします。

以前に適用された修復を適用解除することが必要になる場合があります。

KubeletConfig の修正は、ノードレベルのプロファイルに含まれています。KubeletConfig 修復を削除するには、KubeletConfig オブジェクトから手動で削除する必要があります。この例は、one-rule-tp-node-master-kubelet-eviction-thresholds-set-hard-imagefs-available 修正のコンプライアンスチェックを削除する方法を示しています。

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=

ユーザーは ScanSetting および ScanSettingBinding オブジェクトを利用してスイートおよびスキャンを定義することが推奨されますが、 ComplianceSuite オブジェクトを直接定義する有効なユースケースもあります。

以下の例は、単一のルールのみでワーカーマシンをスキャンする 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 識別子が含まれます。

TailoredProfile CR は最も一般的なテーラリング操作を有効にする一方で、XCCDF 標準は OpenSCAP プロファイルの調整におけるより多くの柔軟性を提供します。さらに、組織が以前に OpenScap を使用していた場合、既存の XCCDF テーラリングファイルが存在し、これを再利用できる可能性があります。

ComplianceSuite オブジェクトには、カスタムのテーラリングファイルにポイントできるオプションの TailoringConfigMap 属性が含まれます。TailoringConfigMap 属性の値は設定マップの名前です。これには、tailoring.xml というキーが含まれる必要があり、このキーの値はテーラリングのコンテンツです。

通常、毎週月曜日または日次など、定義されたスケジュールでスキャンを再実行する必要がある場合があります。また、ノードの問題を修正した後にスキャンを 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

ComplianceCheckResult などのカスタムリソースは、スキャンされたすべてのノード間での単一チェックの集計された結果を表しますが、スキャナーによって生成される未加工の結果を確認することが役に立つ場合もあります。未加工の結果は ARF 形式で生成され、サイズが大きくなる可能性がありますが (ノードあたり数十メガバイト)、それらを etcd のキーと値のストアでサポートされる Kubernetes リソースに保存することは実際的ではありません。すべてのスキャンは、1GB のサイズにデフォルト設定される永続ボリューム (PV) を作成します。環境によっては、PV サイズを適宜増やす必要がある場合があります。これは、ScanSetting および ComplianceScan リソースの両方に公開される rawResultStorage.size 属性を使用して実行されます。

関連するパラメーターは rawResultStorage.rotation であり、これは古いスキャンのローテーションが行われる前に保持されるスキャンの数を制御します。デフォルト値は 3 です。ローテーションポリシーを 0 に設定するとローテーションは無効になります。デフォルトのローテーションポリシーと、未加工の ARF スキャンレポートにつき 100 MB を見積もり、お使いの環境に適した PV サイズを計算できます。

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 * * *'

ComplianceSuite オブジェクトで autoApplyRemediations ブール値パラメーターを使用することもできますが、オブジェクトに compliance.openshift.io/apply-remediations のアノテーションを付けることもできます。これにより、Operator は作成されるすべての修復を適用できます。

$ oc annotate compliancesuites/<suite-_name> compliance.openshift.io/apply-remediations=

新しいコンテンツを含むスキャンは、修復に OUTDATED というマークを付ける可能性があります。管理者は、compliance.openshift.io/remove-outdated アノテーションを適用して新規の修復を適用し、古い修復を削除できます。

$ oc annotate compliancesuites/<suite_name> compliance.openshift.io/remove-outdated=

または、ScanSetting または ComplianceSuite オブジェクトに autoUpdateRemediations フラグを設定し、修復を自動的に更新します。

以下のセクションでは、コンプライアンス Operator スキャンのコンポーネントおよびステージについて説明します。

$ oc get profilebundle.compliance

$ oc get profile.compliance

$ 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

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

Events:
  Type     Reason        Age    From                    Message
  ----     ------        ----   ----                    -------
  Normal   SuiteCreated  9m52s  scansettingbindingctrl  ComplianceSuite openshift-compliance/my-companys-compliance-requirements created

$ oc get cronjobs

NAME                                           SCHEDULE    SUSPEND   ACTIVE   LAST SCHEDULE   AGE
<cron_name>                                    0 1 * * *   False     0        <none>          151m

$ oc get cm -lcompliance.openshift.io/scan-name=rhcos4-e8-worker,complianceoperator.openshift.io/scan-script=

$ oc get pvc -lcompliance.openshift.io/scan-name=<scan_name>

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

$ 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

$ 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

$ oc annotate compliancescans/<scan_name> compliance.openshift.io/rescan=

$ oc patch complianceremediations/rhcos4-e8-worker-audit-rules-dac-modification-chmod --patch '{"spec":{"apply":true}}' --type=merge

$ oc get mc | grep 75-

75-rhcos4-e8-worker-my-companys-compliance-requirements                                                2.2.0             2m46s

$ 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:

$ 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

$ oc logs -l workload=<workload_name> -c <container_name>

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

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

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

コンプライアンス Operator を削除するには、最初に コンプライアンス Operator のカスタムリソース定義 (CRD) を削除する必要があります。CRD が削除された後、openshift-compliance プロジェクトを削除することにより、Operator とその namespace を削除できます。

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

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

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

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>

    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>

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

コンプライアンススキャンの要件を定義した後、スキャンのタイプ、スキャンの発生、およびスキャンの場所を指定することにより、コンプライアンススキャンを設定できます。そのために、コンプライアンス Operator は 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

コンプライアンススキャン要件を定義し、スキャンを実行するように設定すると、コンプライアンスオペレーターは 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

$ oc get compliancesuites

コンプライアンススイートの作成後、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

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

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

oc get events --field-selector involvedObject.kind=ComplianceScan,involvedObject.name=<name of the suite>

コンプライアンススイートが DONE フェーズに達すると、スキャン結果と可能な修正を表示できます。

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>

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'

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

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

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

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

Operator が正常にインストールされていない場合、以下を実行します。

FileIntegrity カスタムリソース (CR) のインスタンスは、1 つ以上のノードの継続的なファイル整合性スキャンのセットを表します。

それぞれの FileIntegrity CR は、 FileIntegrity CR 仕様に一致するノード上で AIDE を実行するデーモンセットによってサポートされます。

FileIntegrity カスタムリソース (CR) は、.status.phase サブリソースでそのステータスを報告します。

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

ノードごとに 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

これらの条件は、対応する FileIntegrityNodeStatus CR ステータスの results 配列で報告されます。

[
  {
    "condition": "Succeeded",
    "lastProbeTime": "2020-09-15T12:45:57Z"
  }
]
[
  {
    "condition": "Succeeded",
    "lastProbeTime": "2020-09-15T12:46:03Z"
  }
]
[
  {
    "condition": "Succeeded",
    "lastProbeTime": "2020-09-15T12:45:48Z"
  }
]

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

$ 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"
  }
]

$ 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>

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

Kubernetes カスタムリソース (CR) の場合と同様に、oc explain fileintegrity を実行してから、以下を使用して個別の属性を参照できます。

$ oc explain fileintegrity.spec

$ oc explain fileintegrity.spec.config

デフォルトの File Integrity Operator 設定は、 FileIntegrity CR と同じ名前で設定マップに保存されます。

以下は、設定マップの 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 インスタンスのデフォルト設定は、以下のディレクトリー下にあるファイルの範囲を指定します。

以下のディレクトリーは対象外です。

DBDIR、LOGDIR、database、および database_out などの AIDE 内部動作を設定するエントリーは Operator によって上書きされます。Operator は、整合性に関する変更の有無についてすべてのパスを監視できるよう接頭辞を /hostroot/ に追加します。これにより、コンテナー化された環境用にカスタマイズされない既存の AIDE 設定を再使用や、ルートディレクトリーからの開始がより容易になります。

この例では、worker-fileintegrity CR に提供されるデフォルト設定に基づいてコントロールプレーンノード (別名マスターノード) で実行されるスキャナーのカスタム設定を定義することに重点を置いています。このワークフローは、デーモンセットとして実行されているカスタムソフトウェアをデプロイし、そのデータをコントロールプレーンノードの /opt/mydaemon の下に保存する場合に役立ちます。

ファイル整合性の設定を変更するには、生成される設定マップを変更しないでください。その代わりに、spec.name、namespace、および key 属性を使用して FileIntegrity オブジェクトにリンクされる設定マップを変更します。

File Integrity Operator が予定される変更を検知する場合、データベースの再初期化が必要になることがあります。

OpenShift Container Platform 4 では、クラスターノード設定は MachineConfig オブジェクトで提供されます。MachineConfig オブジェクトによって生じるファイルへの変更が予想されますが、ファイルの整合性スキャンは失敗しないことを前提にすることができます。MachineConfig オブジェクトの更新によって生じるファイルの変更を抑制するために、File Integrity Operator はノードオブジェクトを監視します。ノードが更新されると、AIDE スキャンは更新の期間一時停止します。更新が完了すると、データベースが再初期化され、スキャンが再開されます。

この一時停止および再開ロジックは、ノードオブジェクトのアノテーションに反映されるため、MachineConfig API での更新にのみ適用されます。

それぞれの 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 オブジェクトが参照する設定マップにコピーされます。

デプロイメント時に、受付コントローラーは以下を検証します。

SCC が Pod で許可される場合には、kubelet は指定された seccomp プロファイルで Pod を実行します。