2.5. セキュリティーポリシーの管理
セキュリティーポリシーおよびポリシー違反の作成、表示、および管理には、ガバナンスおよびリスクのダッシュボードを使用します。CLI およびコンソールからポリシーの YAML ファイルを作成できます。
ガバナンスおよびリスク ページでは、カテゴリーや基準で違反をフィルタリングして概要ビューをカスタマイズしたり、概要ビューを折りたたみ表示数を減らしたりだけでなく、ポリシーの検索も可能です。ポリシーまたはクラスターの違反別に、違反の表のビューもフィルタリングできます。
ポリシーの表では、Policy name、Namespace、Remediation、Cluster violation、Standards、Categories および Controls のポリシーの情報を表示します。Actions アイコンを選択すると、ポリシーの編集、無効化、通知、または削除が可能です。
表一覧でポリシーを選択すると、コンソールで、以下の情報タブが表示されます。
- Details: Details タブを選択して、ポリシーの情報、配置の情報、ポリシーテンプレート の表一覧を表示します。
- Status: Status タブを選択して、違反の表一覧を表示します。Clusters または Templates 別にビューをフィルタリングできます。ポリシーのコンプライアンスステータスを表示するには、Status タブを選択します。View history リンクをクリックして、違反メッセージの一覧を表示します。
- YAML: YAML タブを選択して、ポリシーを表示するか、エディターでポリシーを編集します。YAML の切り替えを選択してエディターを表示または非表示にします。
セキュリティーポリシーの作成および更新の詳細は、以下のトピックを参照してください。
他のトピックについては、「ガバナンスおよびリスク」を参照してください。
2.5.1. GitOps を使用したポリシーのデプロイ
ガバナンスフレームワークを使用して、マネージドクラスター全体にポリシーセットをデプロイできます。リポジトリーに ポリシーを提供して使用することで、オープンソースのコミュニティー(policy-collection )に追加できます。詳細は、「 カスタムポリシーの取得 」を参照してください。オープンソースコミュニティーの各 stable および community フォルダーのポリシーは、NIST Special Publication 800-53 に従ってさらに整理されています。
GitOps を使用して Git リポジトリー経由でポリシーの更新や作成を自動化して追跡する時のベストプラクティスを理解するにはこれ以降のセクションを確認してください。
前提条件: 開始する前に、policy-collection リポジトリーをフォークしてください。
2.5.1.1. ローカルリポジトリーのカスタマイズ
stable および community ポリシーを 1 つのフォルダーにまとめて、ローカルリポジトリーをカスタマイズします。使用しないポリシーを削除します。ローカルリポジトリーをカスタマイズするには、以下の手順を実行します。
リポジトリーに新しいディレクトリーを作成し、デプロイするポリシーを保存します。GitOps のメインのデフォルトブランチに、ローカルの
policy-collectionリポジトリーにあることを確認します。以下のコマンドを実行します。mkdir my-policies
stableおよびcommunityポリシーのすべてをmy-policiesディレクトリーにコピーします。stableフォルダーにコミュニティーで利用可能なものが重複している場合があるので、communityポリシーから始めます。以下のコマンドを実行します。cp -R community/* my-policies/ cp -R stable/* my-policies/
すべてのポリシーの構造は単一の親ディレクトリーとなっているので、フォークでポリシーを編集できます。
ヒント:
- 使用の予定がないポリシーを削除するのがベストプラクティスです。
以下の一覧でポリシーおよびポリシーの定義について確認してください。
- 目的: ポリシーの役割を理解する。
修復アクション: ポリシーで、コンプライアンスの通知だけを行うのか、ポリシーを強制して、変更を加えるのか?
spec.remediationActionパラメーターを参照してください。変更が適用される場合は、想定されている機能を理解するようにしてください。強制のサポートがあるポリシーを確認してください。詳細は、Validate セクションを参照してください。注記: ポリシーに設定された
spec.remediationActionは、個別のspec.policy-templatesで設定される修復アクションを上書きします。-
配備: ポリシーのデプロイ先のクラスターは?デフォルトでは、ほとんどのポリシーは、
environment: devラベルの付いたクラスターを対象にしています。ポリシーによっては、OpenShift Container Platform クラスターまたは別のラベルをターゲットにできます。追加のラベルを更新または追加して、他のクラスターを組み込むことができます。特定の値がない場合には、ポリシーはすべてのクラスターに適用されます。また、ポリシーのコピーを複数作成し、クラスターセットごとに各ポリシーをカスタマイズして、別のクラスターセットには別の方法で設定することができます。
2.5.1.2. ローカルリポジトリーへのコミット
ディレクトリーに行った変更に問題がなければ、変更を Git にコミットしてプッシュし、クラスターによるアクセスを可能にします。
注記: この例は、GitOps でポリシーを使用する基本的な方法を示しており、ブランチの変更を取得する場合には別のワークフローを使用する場合があります。
以下の手順を実行します。
ターミナルから、
git statusを実行して、以前に作成したディレクトリーに最新の変更を確認します。以下のコマンドを使用して、コミットする変更一覧に新しいディレクトリーを追加します。git add my-policies/
変更をコミットし、メッセージをカスタマイズします。以下のコマンドを実行します。
git commit -m “Policies to deploy to the hub cluster”
GitOps に使用するフォークしたリポジトリーのブランチに、変更をプッシュします。以下のコマンドを実行します。
git push origin <your_default_branch>master
変更がコミットされます。
2.5.1.3. クラスターへのポリシーのデプロイ
変更をプッシュしたら、ポリシーを Red Hat Advanced Cluster Management for Kubernetes インストールにデプロイできます。デプロイメント後、ハブクラスターは Git リポジトリーに通知されます。Git リポジトリーの選択したブランチに追加された変更がクラスターに反映されます。
deploy.sh スクリプトは、ハブクラスターに Channel および Subscription リソースを作成します。チャネルは Git リポジトリーに接続し、サブスクリプションは、チャネルを介してクラスターに配置するデータを指定します。その結果、指定のサブディレクトリーで定義された全ポリシーがハブに作成されます。
サブスクリプションによりポリシーが作成されると、Red Hat Advanced Cluster Management はポリシーを分析し、定義した配置ルールに基づいて、ポリシーが適用される各マネージドクラスターに関連付けられた namespace に追加のポリシーリソースを作成します。
その後、ポリシーはハブクラスター上にある該当するマネージドクラスターの namespace からマネージドクラスターにコピーされます。そのため、Git リポジトリーのポリシーは、ポリシーの配置ルールで定義される clusterSelector に一致するラベルが付いた全マネージドクラスターにプッシュされます。
以下の手順を実行します。
policy-collectionフォルダーから、以下のコマンドを実行してディレクトリーを変更します。cd deploy
以下のコマンドで、コマンドラインインターフェース (CLI) が正しいクラスターでリソースを作成するように設定されていることを確認します。
oc cluster-info
コマンドの出力には、Red Hat Advanced Cluster Management がインストールされているクラスターの API サーバーの詳細が表示されます。正しい URL が表示されない場合は、CLI を正しいクラスターを参照するように設定します。詳細情報は、「Using the OpenShift CLI」のセクションを参照してください。
アクセス制御およびポリシー整理を行うポリシーの作成先の namespace を作成します。以下のコマンドを実行します。
oc create namespace policy-namespace
以下のコマンドを実行してクラスターにポリシーをデプロイします。
./deploy.sh -u https://github.com/<your-repository>/policy-collection -p my-policies -n policy-namespace
your-repositoryは、Git ユーザー名またはリポジトリー名に置き換えます。注記: 参考までに、
deploy.shスクリプトの引数の全一覧では、以下の構文を使用します。./deploy.sh [-u <url>] [-b <branch>] [-p <path/to/dir>] [-n <namespace>] [-a|--name <resource-name>]
引数については、以下のドキュメントを参照してください。
-
URL: メインの
policy-collectionリポジトリーからフォークしたリポジトリーへの URL。デフォルトの URL はhttps://github.com/stolostron/policy-collection.gitです。 -
ブランチ: 参照する Git リポジトリーのブランチ。デフォルトのブランチは
mainです。 -
サブディレクトリーパス: 使用するポリシーを含めるために作成したサブディレクトリーパス。上記のサンプルでは
my-policiesサブディレクトリーを使用しましたが、開始するフォルダーを指定することもできます。たとえば、my-policies/AC-Access-Controlを使用できます。デフォルトのフォルダーはstableです。 -
Namespace: リソースおよびポリシー作成先のハブクラスター上の namespace。これらの手順では
policy-namespace名前空間を使用します。デフォルトの namespace はpoliciesです。 -
名前のプレプレフィックス:
ChannelおよびSubscriptionリソースのプレフィックス。デフォルトはdemo-stable-policiesです。deploy.shスクリプトの実行後に、リポジトリーへのアクセス権があるユーザーはブランチに変更をコミットでき、コミットすることでクラスター上の既存のポリシーに対して変更がプッシュされます。
-
URL: メインの
2.5.1.4. コンソールからの GitOps ポリシーデプロイメントの確認
変更がコンソールからポリシーに適用されていることを確認します。コンソールからポリシーを変更することもできます。以下の手順を実行します。
- Red Hat Advanced Cluster Management クラスターにログインします。
- ナビゲーションメニューから Govern risk を選択します。
以下のポリシーの詳細を確認してください。
- 配信先のクラスターで特定のポリシーが準拠している/準拠していないのはなぜか?
- ポリシーが正しいクラスターに適用されているか？
- このポリシーがクラスターに配布されていない場合は、なぜか？
作成または変更した GitOps のデプロイポリシーを特定します。GitOps のデプロイポリシーは、自動適用されるアノテーションで特定できます。GitOps のデプロイポリシーのアノテーションは、以下のパスのようになります。
apps.open-cluster-management.io/hosting-deployable: policies/deploy-stable-policies-Policy-policy-role9 apps.open-cluster-management.io/hosting-subscription: policies/demo-policies apps.open-cluster-management.io/sync-source: subgbk8s-policies/demo-policies
GitOps アノテーションは、ポリシーが作成されたサブスクリプションを確認するのに役立ちます。独自のラベルをポリシーに追加して、ラベルに基づいてポリシーを選択するランタイムクエリーを作成することもできます。
たとえば、次のコマンドを使用してポリシーにラベルを追加できます。
oc label policy <policy-name> -n <policy-namespace> <key>=<value>
続いて、以下のコマンドでラベルのあるポリシーをクエリーします。
oc get policies -n <policy-namespace> -l <key>=<value>
ポリシーは GitOps を使用してデプロイされます。
