マルチクラスタ OpenShift 環境における NIST 800-53 コントロールの管理 - パート 2

この 3 部構成のブログシリーズのパート 1 では、マルチクラスター OpenShift のデプロイメントにおけるコンプライアンスをサポートする OpenShift Platform Plus の主な考え方とツールについて説明しました。マルチクラスター OpenShift の実装におけるセキュリティ上の課題を説明し、そのような環境で特定の NIST SP 800-53 技術的コントロールへのコンプライアンスを達成するためのツールを紹介しました。

このパートでは、マルチクラスター環境で特定の NIST SP800-53 セキュリティコントロールへの準拠を実現するのに役立つ、OpenShiftPlus ツールとポリシーの実際の実装について説明します。

NIST 800-53 とは

忘れてはならないのは、NIST 800-53 は米国政府の連邦情報システムのためのリスク管理フレームワークであるということです。ソフトウェアだけで NIST 800-53 の統制に完全に対応することはできませんが、ソフトウェアを使用することで、特定の技術的統制への準拠を自動化し、監視することができます。NIST 800-53 のコントロールは、以下の表のようにファミリーに分けられています。

出典： NIST 800-53 Rev5

デモ環境の説明

このセクションでは、Red Hat Advanced Cluster Management for Kubernetes（RHACM） を使用して、組織がポリシーベースのガバナンスフレームワークを実装し、環境を NIST 800-53 標準に準拠させるのに役立つ方法を学びます。

ガバナンスポリシーフレームワークを実際にデモンストレーションするには、このデモ環境に次のコンポーネントが必要です。

• ハブクラスター - RHACM が展開されている OpenShift クラスターです。ハブクラスターは、OpenShift クラスターを管理するために使用されます。クラスタのプロビジョニング、アプリケーションの展開、ガバナンスポリシーの伝達のための管理ポータルとして使用されます。このデモ環境では、RHACM のバージョン 2.3.1 がハブ・クラスターに配備されています。

• マネージドクラスター - RHACM のハブクラスタには 2 つの OpenShift クラスタが接続されており、RHACM はこれらのクラスタを管理しています。クラスタは、RHACM の管理ポータルで定義されたポリシーの影響を受けます。このデモでは、クラスター名を cluster-a と cluster-b としています。

• アプリケーション - 管理されたクラスター上に簡単なアプリケーションがプロビジョニングされます。このアプリケーションは、RHACM のアプリケーション・セキュリティ機能を実証するために使用されます。さらに、このアプリケーションを使用して、RHACM が組織内のソフトウェア・エンジニ アリング・プラクティスをどのように改善できるかを理解します。アプリケーションの名前は mariadb-app で、両方の管理対象クラスターの mariadb ネームスペースに配置されます。
  アプリケーションのリソースは、私がフォークした GitLab の rhacm-demo リポジトリにあり、ハブクラスタ上で以下のコマンドを実行することでデプロイできます。

$ oc apply -f https://gitlab.com/michael.kot/rhacm-demo/-/raw/master/rhacm-resources/application.yml

アプリケーションのトポロジーを以下の図で表示します。

ガバナンスの基本

NIST 800-53 のセキュリティ対策を行う前に、RHACM のガバナンス機構の基本を理解することが重要です。以下のセクションでは、機能するガバナンス機構を展開するために作成する必要のあるリソースについて学びます。

ネームスペース

目的のコンプライアンスポリシーを展開するためには、ハブクラスタ上にネームスペースを作成する必要があります。コンプライアンス・ポリシーのネームスペースには、ポリシーの設定に関連する OpenShift カスタム・リソース（CR）が投入されます。このシナリオでは、ネームスペースの名前を rhacm-policies とします。次のコマンドを実行します。

$ oc apply -f https://raw.githubusercontent.com/michaelkotelnikov/rhacm-blog/master/namespace.yml

ポリシー

RHACM でクラスター間のガバナンスと一貫性を確保するためには、ポリシーを設定する必要があります。ポリシーは、Kubernetes リソースに対して一定のルールセットを実施します。ポリシーは、管理対象クラスタ上で監視するリソースを宣言します。例えば、ポリシーは、Kubernetes ConfigMapリソースの内容を監視することができます。ConfigMapリソースのコンテンツが変更された場合、ポリシーコントローラは2つの方法のいずれかで違反を修復します。

• ポリシーコントローラーが inform に設定されている場合、コントローラーは違反を登録して、RHACM ハブクラスターに渡します。ハブクラスターは、ガバナンスダッシュボードから組織内のセキュリティ管理者に違反を通知します。

• ポリシーコントローラが enforce に設定されている場合、コントローラは違反している Kubernetes リソースに望ましい状態を適用することで（ポリシーで定義されている内容に従って）違反の修正を試みます。

この記事で扱っている各セキュリティコントロールは、それぞれのポリシーリソースに関連付けられています。

プレースメントルール

プレースメントルールは、ラベルによってクラスターのグループを集約します。この例では、environment=dev のラベルを含むすべてのクラスタを集約します。この例では、cluster-a と cluster-b の両方が Environment=devラベルを持っています。以下のコマンドを実行して、ハブ・クラスター上の rhacm-policies ネームスペースに定義されたPlacementRuleリソースを作成します。

$ oc apply -f https://raw.githubusercontent.com/michaelkotelnikov/rhacm-blog/master/placementrule.yml

プレースメントバインディング

この記事で作成された各ポリシーに対して、PlacementBinding リソースも作成されます。PlacementBinding リソースは、PlacementRule リソースと Policy リソースの間を結合します。つまり、あるポリシーは、PlacementRule リソースのルールにマッチするすべてのクラスターに適用されます。このシナリオでは、作成されたすべてのポリシーが、管理されているすべてのクラスターに適用されます。

ガバナンスフレームワークによる NIST 800-53 規格への準拠

始める前に：次のデモで使用するすべてのファイルとリソースは、私がフォークしたGitHubリポジトリに存在します。記事中のデモを行うには、このリポジトリをフォークすることをお勧めします。

AC-3（アクセス・エンフォースメント）セキュリティ・コントロールへの準拠

AC-3 セキュリティコントロールでは、"適切なアクセス制御ポリシーに従って、情報およびシステムリソースへの論理アクセス に対して承認された認可を実施する"としています。大規模な環境では、特定の役割を持つユーザーが、すべての OpenShift 環境で限られたリソースにしかアクセスできないようにする必要があります。環境内のすべてのクラスターにわたって特定の RBAC ルールを定義することで、組織が AC-3 セキュリティ・コントロールへの準拠を達成できるようにします。

例えば、user1 という名前のユーザーを作成します。このユーザーは、グループ「mariadb-operators」のメンバーです。このグループのユーザーの目的は、アプリケーションポッドが失敗した場合にデプロイメントをロールアウトすることです。そのため、user1 は管理対象クラスタ上のアプリケーション・ネームスペースのリソースへのアクセスが制限されています。これにより、AC-3セキュリティ・コントロールに準拠した環境になります。

このシナリオの目的は、複数の OpenShift クラスターで user1（ mariadb-operators グループの一員として）に RBAC ルールを適用する方法を示すことです。これにより、環境を AC-3 セキュリティ・コントロールに準拠させます。

例えば、ハブクラスタ上の rhacm-policies ネームスペースに3つのPolicyリソースが作成されます。Policy リソースは、ポリシーコントローラが監視する Kubernetes リソースを定義します。作成された以下のリソースの説明を読み、リソース図を表示します。

• すべての管理対象クラスターで mariadb-operators グループを定義するために、group-policy が作成されます。配置されたポリシーには enforce remediation action が設定されています。これは、定義されたリソースがマネージドクラスター上で利用できない場合に、ポリシーコントローラがそのリソースを作成することを意味します。ポリシーでは、mariadb-operators という名前のグループリソースを定義しています。このグループリソースには、user1 が割り当てられています。
  

• mariadb-operators グループに割り当てられた Role リソースを定義するために、role-policyが作成されます。配置されたポリシーには、enforce レメディエーションアクションが設定されています。このポリシーは、アプリケーションがデプロイされているネームスペースである mariadb ネームスペースでのみ有効です。ポリシーでは、dc-rollout-role という名前の Roleリソースを定義しています。ロールポリシーでは、デプロイメントコンフィグ、レプリケーションコントローラ、ポッドといった異なるリソースへのアクセスが許可されます。
  

• role-binding-policyが作成され、管理対象クラスタ上に RoleBinding リソースが定義されます。RoleBinding リソースは、作成された dc-rollout-role ロールと mariadb-operators グループの間で結合します。ポリシーのレメディエーションアクションは、管理対象クラスター上の mariadb ネームスペースで強制するように設定されています。
  

Contributing and deploying community policies with Red Hat Advanced Cluster Management and GitOps で説明したように、GitOps アプローチを使用してポリシーをデプロイしてみましょう。GitOps アプローチを使用すると、ユーザーはポリシーをソースコードのように扱うことができます。Git リポジトリでポリシーを更新すると、RHACM ハブクラスタでもポリシーが更新されます。

1. GitOps の機能を利用するには、policy-collectionのリポジトリをクローンします。その後、リポジトリのdeploy/deploy.shスクリプトを使って、先ほどのPolicyとPlacementBindingのリソースをすべてデプロイします。deploy.shスクリプトの引数に、フォークしたリポジトリと自分のユーザー名を指定してリソースをデプロイします。以下のコマンドを実行します。
   
   $ git clone https://github.com/open-cluster-management/policy-collection.git
$ cd policy-collection/deploy/
$ ./deploy.sh --url https://github.com//rhacm-blog.git --path policies/AC-3 --branch master --name ac-3 --namespace rhacm-policies
   
   リソースを作成した後、RHACM Governance ダッシュボードを表示します。すべてのクラスターは、ポリシーでレメディエーションアクションが強制に設定されているため、違反がなく、コンプライアンス状態になっているはずです。
   

2. 管理対象クラスターに mariadb-operators グループが作成されていることを確認し、admin ユーザーとしてcluster-b にログインし、利用可能なグループをリストアップします。以下のコマンドを実行します。
   
   $ oc whoami
admin

$ oc get group
NAME            USERS
mariadb-operators   user1
   
   ポリシーコントローラーが管理下のクラスター上に mariadb-operators Groupリソースを正常に作成したことに注意してください。

3. Role と RoleBinding リソースが作成されたことを確認し、cluster-b に user1 でログインし、mariadb ネームスペースのポッドをリストアップしてみます。その後、ポッドを削除して結果を表示します。
   
   $ oc whoami
user1

$ oc get pods -n mariadb
NAME           READY   STATUS  RESTARTS   AGE
mariadb-1-deploy   0/1 Completed   0      18m
mariadb-1-s9zrl 1/1 Running 0      18m

$ oc delete pod mariadb-1-s9zrl -n mariadb
Error from server (Forbidden): pods "mariadb-1-s9zrl" is forbidden: User "user1" cannot delete resource "pods" in API group "" in the namespace "mariadb"
   
   User1 は、dc-rollout-role ロールで宣言されているように、ポッドの削除を許可されていません。
   ポリシーが enforce に設定されている場合、管理対象クラスタのローカル admin ユーザーであっても、ポリシーで定義されているリソースの状態を変更することはできません。ポリシーを強制するということは、クラスター間で整合性が適用され、常にセキュリティ管理に準拠した状態になるということです。

4. cluster-b のローカル admin ユーザーとして、dc-rollout-role ネームスペースの編集を試みます。podリソースに delete 動詞を追加し、user1 がpodを削除するアクセス権を持つようにします。
   
   $ oc whoami
admin
$ oc edit role dc-rollout-role -n mariadb
…
- apiGroups:
  - ""
  resources:
  - pods
  verbs:
  - get
  - list
  - watch
  - delete
…
role.rbac.authorization.k8s.io/dc-rollout-role edited
   
   コンソールではロールが編集されたことになっていますが、ポリシーコントローラではリソースの元の状態（ポリシーに記載されている状態）が適用されます。管理対象クラスター上でロールを変更するには、ハブ・クラスター上でroleリソースを定義するポリシーを変更する必要があります。ロールをリストアップして、delete 動詞が保存されていないことを確認することができます。次のコマンドを実行します。
   
   $ oc get role dc-rollout-role -o yaml -n mariadb
…
- apiGroups:
  - ""
  resources:
  - pods
  verbs:
  - get
  - list  - watch

クラスタは、組織で定義されたセキュリティコントロールに準拠したままです。

組織のセキュリティ管理者が policy-role-mariadb-rollout ポリシーのレメディエーションアクションを enforce から inform に変更すると、ポリシーコントローラは管理対象クラスタの Role リソースに特定の値を強制しなくなります。前述の内容を検証するために、レメディエーションアクションを inform に変更してみましょう。

レメディエーションアクションを変更するには、最初にフォークした GitHub リポジトリに移動して、policy/AC-3/role-policy.yml の内容をこのポリシーで上書きします。変更内容は必ず GitHub にコミットしてください。

これで、ローカル管理者が mariadb ネームスペースに定義された dc-rollout-role リソースの値を変更すると、以下の変更が反映されます。

$ oc whoami

admin

$ oc edit role dc-rollout-role -n mariadb

…

- apiGroups:

 - ""

 resources:

 - pods

 verbs:

 - get

 - list

 - watch

 - delete

…

role.rbac.authorization.k8s.io/dc-rollout-role edited

$ oc get role dc-rollout-role -o yaml -n mariadb

…

- apiGroups:

 - ""

 resources:

 - pods

 verbs:

 - get

 - list

 - watch

 - delete

今のところ、クラスタ-bは定義されている RBAC ポリシーに準拠していません。cluster-b のポリシーコントローラは違反を登録し、ハブクラスタに送信します。違反は Governance ダッシュボードに表示され、AC-3 NIST 800-53 セキュリティコントロールに準拠していないクラスタ（  cluster-b ）が1つあることが記載されています。コンソールの次の画像を表示します。

SI-4(A.1)  (情報システム監視) セキュリティ・コントロールへの準拠

SI-4(a.1)のセキュリティ管理では、「組織は、組織が定義した監視目的に従って、攻撃および潜在的な攻撃の指標を検出するために情報システムを監視する」としています。SI-4(a.1) のセキュリティ・コントロールに準拠するためには、組織はすべてのクラスター上で実行されるワークロードを等しく監視する必要があります。

ここでは、RHACM を使って、すべての OpenShift クラスターのアプリケーションの脆弱性を監視する方法を紹介します。

分散したアプリケーション監視を可能にする一つの方法は、管理されているすべてのクラスターで container-security-operator を有効にすることです。オペレーターは、Quay で管理され、Clair でスキャンされたイメージを可視化します。イメージに脆弱性が存在する場合、オペレーターはそれらを集約し、ImageManifestVuln オブジェクトを作成します。ガバナンスポリシーフレームワークを使用することで、ImageManifestVuln オブジェクトを監視し、脆弱性が存在する場合はガバナンスダッシュボードでアラートを開始することができます。

したがって、クラスターが脆弱性を含むイメージを持つアプリケーションを実行している場合、そのクラスターは組織のセキュリティ基準に準拠していないとみなされます。このような場合、セキュリティ管理者は、組織が定めた規定に従って行動する必要があります。以下の手順を完了します。

1. イメージスキャンポリシーを作成するために、現在の設定に以下のリソースを追加します。

   • ハブ・クラスター上の rhacm-policies ネームスペースにある policy-imagemanifestvuln ポリシーです。このポリシーは、2つのオブジェクト定義を監視します。

     • ポリシーでは、クラスターは container-security-operator の導入が musthave と定義されています。このケースのレメディエーションアクションはenforceに設定されているため、オペレーターがクラスターに存在しない場合、ポリシーコントローラはインストールを試みます。

     • このポリシーは、環境内のクラスターが  kind: mageManifestVuln  リソースを mustnothave として定義します。このポリシーは、デフォルトの openshift-\* プロジェクト以外のすべてのプロジェクトを監視するために使用されます。レメディエーションアクションが Inform に設定されているため、管理対象クラスターのアプリケーションのネームスペースに ImageManifestVuln オブジェクトがある場合、RHACM コンソールはポリシーコントローラーによって通知されます。次のコマンドを実行して、ポリシーをデプロイします。
       
       $ ./deploy.sh --url https://github.com//rhacm-blog.git --path policies/SI-4 --branch master --name si-4 --namespace rhacm-policies
        

2. リソースの作成後、Governance ダッシュボードを表示します。両方のクラスターが、定義されたポリシーに準拠していないことに注意してください。
   
3. policy-imagemanifestvuln のステータスに移動し、Governance ダッシュボードで詳細を表示すると、違反しているネームスペースが mariadb であることがわかります。これは、シナリオのためにデプロイされたデモアプリケーションに脆弱性があることを意味します。ポリシーでmustnothave コンプライアンス タイプが定義されているにもかかわらず、ネームスペースに ImageManifestVuln オブジェクトが含まれていることに注意してください。
   
   違反している ImageManifestVuln 名の横にある View yaml ボタンをクリックすると、画像の脆弱性に関する詳細な情報を得ることができます。
   
   
4. 脆弱性をさらに分析するために、cluster-a のローカル OpenShift コンソールにログインします。メインダッシュボードでは、Quay イメージスキャンツールが、クラスタ内のコンテナで使用されているイメージに脆弱性を発見したことに注目してください。
   
   
   次の画像では、Clair が mariadb のネームスペースに脆弱性を発見したことに注目してください。
   
5. マニフェスト名を選択することで、ポリシーコントローラが監視するイメージのマニフェスト脆弱性へのリファレンスを参照します。マニフェスト名を選択すると、Quay.io にリダイレクトされ、Clair からのフルスキャンレポートが表示されます。ここでは、脆弱性の背後にあるCVEと、その修正プログラムがあるかどうかを確認できます。
   

現時点では、 cluster-a と cluster-b の両方とも、組織が定義した監視目的に従って監視ツールを実装しているため、SI-4(a.1) のセキュリティ・コントロールに準拠しています。しかし、どちらのクラスターも高レベルの脆弱性に関連したイメージを実行しているため、リスクがあることに注意しておく必要があります。

あとは、組織のセキュリティ管理者やアプリケーション開発チームが、Governance ダッシュボードに表示された違反事項を修正するだけです。

アプリケーションイメージを Quay に保存していない場合は、Red Hat Advanced Cluster Security を使用して、既知の脆弱性について Kubernetes クラスタにデプロイされたイメージを監視することができます。詳細は、What's New in Red Hat Advanced Cluster Securityブログからご覧いただけます。

SC-6 (リソースアベイラビリティ) セキュリティコントロールへの準拠

SC-6 セキュリティコントロールでは「情報システムは、組織で定義されたリソースを優先的に割り当てることでリソースの可用性を保護する」とされています。SC-6 セキュリティコントロールに準拠するために、組織はすべての OpenShift クラスターに等しいクォータを設定する必要があります。

クオータの設定は、OpenShift クラスター内の優先度の低いプロジェクトが、優先度の高いプロジェクトの作業を妨害しないようにするために必要です。制御されていないリソース割り当てポリシーを持つ環境では、リソース枯渇攻撃やサービス拒否が発生する可能性があります。

このセクションでは、RHACM を使用して、複数の OpenShift クラスターに等しいプロジェクトクォータを分配する方法を紹介します。それにより、SC-6 のセキュリティコントロールに準拠した環境を実現します。

管理対象クラスタ上の Kubernetes LimitRange リソースを監視・維持するために、policy-limitrangeポリシーが作成されます。このポリシーは、ハブクラスタ上の rhacm-policies ネームスペースに展開されます。LimitRange リソースの名前を mariadb-limit-range とし、レメディエーションアクションをenforceに設定し、管理対象クラスタ上の mariadb ネームスペースに基本クォータを作成します。次のコマンドを実行して、ポリシーを展開します。

$ ./deploy.sh --url https://github.com//rhacm-blog.git --path policies/SC-6 --branch master --name sc-6 --namespace rhacm-policies

これで LimitRange ポリシーが cluster-a と cluster-b の両方に適用されます。次の画像では、Governance ダッシュボードで両方のクラスターがポリシーに準拠していることに注目してください。

cluster-a にログインすると、mariadb ネームスペースで LimitRange クォータリソースが有効になっていることがわかります。

$ oc get limitrange -n mariadb

NAME              CREATED AT

mariadb-limit-range   2021-01-31T13:57:03Z

$ oc get limitrange mariadb-limit-range -o yaml -n mariadb

apiVersion: v1

kind: LimitRange

metadata:

 creationTimestamp: "2021-01-31T13:57:03Z"

 name: mariadb-limit-range

 namespace: mariadb

 resourceVersion: "82916"

 selfLink: /api/v1/namespaces/mariadb/limitranges/mariadb-limit-range

 uid: d9440c57-7ca3-4c6d-8c83-dfd49a0e652a

spec:

 limits:

 - default:

    cpu: 500m

    memory: 512Mi

     defaultRequest:

    cpu: 50m

    memory: 256Mi

     type: Container

前述の出力に基づいて、cluster-a のポリシーコントローラは定義された limitrange リソースを作成しました。クオータは両クラスタに分配されて整列し、これにより環境はSC-6 セキュリティコントロールに準拠するようになりました。

sc-28 (1)  (暗号保護) セキュリティ・コントロールに準拠

SC-28 (1)  のセキュリティ管理は、「情報システムは、組織が定義した情報システムコンポーネント上の組織が定義した情報の不正な開示および変更を防止するために、暗号化メカニズムを実装する」としています。このセキュリティ コントロールは、組織の OpenShift クラスタ群のさまざまな側面に適用できます。これらの側面の中には、データトランスポートのように、OpenShift プラットフォームに組み込まれているものがあります（OpenShift は暗号アルゴリズムと暗号を使用して、トランスポート中のデータの機密性と完全性を保護します）。また、組織内のすべての OpenShift クラスタにおける etcd の暗号化のように、ユーザー自身が設定可能なものもあります。

このセクションでは、組織内のすべての OpenShift クラスタ全体で etcd データベースを暗号化する方法について説明します。クラスタ全体で etd データベースを暗号化することで、環境を SC-28 (1) のセキュリティコントロールへの準拠に近づけることができます。

1. すべての OpenShift クラスタで etcd データベースを暗号化するには、暗号化ポリシーを作成する必要があります。policy-etcdencryption という名前のetdencryption-policyリソースを作成し、rhacm-policies ネームスペースにデプロイしてみましょう。ポリシーは2つのオブジェクトを定義し、監視します。

   • APIServer リソースでは、aescbc の暗号化タイプが定義されています。remediation action に enforce を設定すると、etcd の暗号化が強制されます。

   • KubeAPIServerリソースでは、リソースステータスに All resources encrypted: secrets, configmaps メッセージが存在することを監視することで、etcdが暗号化されていることを確認してください。このケースで以下のコマンドを実行すると、レメディエーションアクションが inform に設定されます。

   $ ./deploy.sh --url https://github.com//rhacm-blog.git --path policies/SC-28 --branch master --name sc-28 --namespace rhacm-policies
    

2. リソースを適用した後、暗号化が完了するまでに数分かかることがあります。cluster-a にログインして、暗号化が進行していることを確認します。
   
   $ oc get  KubeAPIServer -o yaml
...
      - lastTransitionTime: "2021-01-31T11:57:51Z"
        message: Resource secrets is being encrypted
        reason: EncryptionInProgress
        status: "False"
        type: Encrypted
...
    

3. 暗号化が完了すると、メッセージが変更され、すべてのリソースが暗号化されたことが通知されます。次のような出力になります。
   
   $ oc get  KubeAPIServer -o yaml
...
      - lastTransitionTime: "2021-01-31T16:40:40Z"
        message: 'All resources encrypted: secrets, configmaps'
        reason: EncryptionCompleted
        status: "True"
        type: Encrypted...

次の画像では、Governance ダッシュボードに、cluster-a と cluster-b の両方が etcd 暗号化ポリシーに準拠していると表示されています。etcd データベースの暗号化は、環境を SC-28 (1) セキュリティ コントロールに準拠させるための大きなステップです。

sc-8 (送信の機密性と完全性) セキュリティ・コントロールへの準拠

SC-8 コントロールでは、「情報システムは、送信された情報の機密性；完全性を保護する」とされています。この記事ですでに述べたように、OpenShift の通信は証明書に基づいています。証明書は、認証メカニズムとして使用され、送信されるデータの機密性を保護します。そのため、証明書の有効期限が切れてしまうと、OpenShift のデータ送信の仕組みに誤作動が生じてしまいます。

OpenShift クラスターを SC-8 セキュリティコントロールに準拠させるためには、OpenShift クラスター全体の証明書を監視する必要があります。RHACM は、証明書の監視に使用され、システム内の証明書が期限切れに近づくとすぐに警告を開始します。

SC-8 セキュリティコントロールに準拠するためには、証明書ポリシーを作成する必要があります。policy-cert という名前の cert-policy リソースを作成し、rhacm-policies ネームスペースにデプロイしてみましょう。このポリシーは、管理対象クラスタ上の証明書を監視するために、CertificatePolicy として定義されています。証明書の有効期限が切れたときに RHACM クラスタに通知するために、レメディエーションアクションは inform に設定されています。

デモはシンプルに、1つの証明書（ openshift-ingress ネームスペースの証明書）を監視することにしましょう。証明書の有効期限が3000時間未満になると、アラートが開始されます。すべてのシステム証明書を監視するポリシーは、コミュニティリポジトリの policy-collection に policy-ocp4-certs.yaml という名前で用意されています。次のコマンドを実行します。

$ ./deploy.sh --url https://github.com//rhacm-blog.git --path policies/SC-8 --branch master --name sc-8 --namespace rhacm-policies

Governance ダッシュボードを見ると、1つのクラスターが定義されたポリシーに準拠していないことがわかります。

ポリシーを掘り下げると、cluster-a はポリシーに準拠しておらず、その ingress 証明書は 3000 時間以内に期限切れとなることがわかります。

さて、cluster-a を組織内のセキュリティ標準に準拠させるために、作業を行う環境内のセキュリティ管理者の手に委ねられました。証明書の有効期限が切れてしまうと、クラスタは SC-8 のセキュリティ・コントロールに準拠しなくなります。

終わりに

このブログシリーズでは、RHACM のガバナンスフレームワークの基本的な構成要素を説明しました。また、AC-3、SI-4(a.1)、SC-6、SC-28(1)、SC-8 のセキュリティ管理に準拠するためのポリシーを作成する方法を紹介しました。この複数ブログシリーズの次の章では、OpenShift Platform Plus に付属するツールを使って、マルチクラスターの OpenShift 環境で特定の NIST SP 800-53 セキュリティコントロールへの準拠を実現するための、より実践的なデモンストレーションを行います。

• マルチクラスタ OpenShift 環境における NIST 800-53 コントロールの管理 - パート１
• マルチクラスタ OpenShift 環境における NIST 800-53 コントロールの管理 - パート３