2.6. セキュリティーポリシーの管理


セキュリティーポリシーおよびポリシー違反の作成、表示、および管理には、ガバナンス ダッシュボードを使用します。CLI およびコンソールからポリシーの YAML ファイルを作成できます。

2.6.1. ガバナンスページ

以下のタブが Governance ページに表示されます。

  • 概要

    Overview タブで、Policy set violationsPolicy violationsClustersCategoriesControls、および Standards タブから概要カードを表示します。

  • ポリシーセット

    ハブクラスターポリシーセットを作成および管理します。

  • ポリシー

    セキュリティーポリシーを作成および管理します。ポリシーの表では、NameNamespaceStatusRemediationPolicy setCluster violationsSourceAutomation および Created のポリシーの詳細を表示します。ポリシー行を展開すると、DescriptionStandardsControls、および Categories が表示されます。

    Actions アイコンを選択すると、修復を編集、有効化、無効化の設定をして、ポリシーの通知、有効化、または削除ができます。特定のポリシーのカテゴリーおよび標準を表示するには、ドロップダウン矢印を選択して行を展開します。

    複数のポリシーを選択して Actions ボタンをクリックして、完全な一括処理を行います。Filter ボタンをクリックしてポリシーテーブルをカスタマイズすることもできます。

表一覧でポリシーを選択すると、コンソールで、以下の情報タブが表示されます。

  • Details: Details タブを選択して、ポリシーの情報、配置の情報を表示します。Placement の表の コンプライアンス 列には、表示されるクラスターのコンプライアンスを確認するためのリンクがあります。
  • Results: Results タブを選択して、ポリシーに関連付けられた全クラスターの表リストを表示します。

    Message 列から View details リンクをクリックして、テンプレートの詳細、テンプレート YAML、および関連リソースを表示します。関連リソースを表示することもできます。View history リンクをクリックして、違反メッセージと最後のレポートの時間を表示します。

2.6.2. ガバナンスの自動化設定

特定のポリシーに設定済みの自動化がある場合は、自動化を選択して詳細を表示できます。自動化のスケジュール頻度オプションに関する以下の説明を参照してください。

  • Manual run: この自動化を手動で設定して 1 回実行します。自動化の実行後に、disabled に設定されます。注記: スケジュール頻度が無効になっている場合のみ Manual run モードを選択できます。
  • Run once mode: ポリシーに違反すると、自動化が 1 回実行されます。自動化の実行後に、disabled に設定されます。自動化が disabled に設定された後は、引き続き自動化を手動で実行する必要があります。once mode を実行すると、target_clusters の追加変数にはポリシーに違反するクラスターのリストが自動的に指定されます。Ansible Automation Platform Job テンプレートでは、EXTRA VARIABLES セクション (extra_vars とも呼ばれる) に対して PROMPT ON LAUNCH が有効になっている必要があります。
  • Run everyEvent モード: ポリシーに違反すると、自動化はマネージドクラスターごとに固有のポリシー違反が発生するたびに毎回実行します。DelayAfterRunSeconds パラメーターを使用して、同じクラスターで自動化を再開できるようになるまでの最小秒数を設定します。ポリシーが遅延期間中に複数回違反され、違反状態のままであると、自動化は遅延期間後に 1 回実行されます。デフォルトは 0 秒で、everyEvent モードにのみ適用されます。everyEvent モードを実行すると、target_clusters と Ansible Automation Platform Job テンプレートの追加変数は once モード と同じになります。
  • Disable automation: スケジュールされた自動化を disabled に設定すると、設定が更新されるまで自動化は実行されません。

以下の変数は、Ansible Automation Platform ジョブの extra_vars で自動的に提供されます。

  • policy_name: ハブクラスターで Ansible Automation Platform ジョブを開始する非準拠のルートポリシーの名前。
  • policy_namespace: ルートポリシーの namespace。
  • hub_cluster: clusters DNS オブジェクトの値によって決定されるハブクラスターの名前。
  • policy_sets: このパラメーターには、ルートポリシーに関連付けられたすべてのポリシーセット名が含まれます。ポリシーがポリシーセット内にないと、policy_set パラメーターは空になります。
  • policy_violations: このパラメーターには、非準拠のクラスター名のリストが含まれており、値は非準拠の各クラスターのポリシー status フィールドです。

セキュリティーポリシーの作成および更新の詳細は、以下のトピックを参照してください。

2.6.3. ガバナンスのための Ansible Automation Platform の設定

Red Hat Advanced Cluster Management for Kubernetes ガバナンスを Red Hat Ansible Automation Platform と統合して、ポリシー違反の自動化を作成できます。Red Hat Advanced Cluster Management コンソールで、自動化を設定できます。

2.6.3.1. 前提条件

  • Red Hat OpenShift Container Platform 4.5 以降
  • Ansible Automation Platform バージョン 3.7.3 以降のバージョンがインストールされている必要があります。サポートされている最新バージョンの Ansible Automation Platform をインストールすることを推奨します。詳細は、Red Hat Ansible Automation Platform ドキュメント を参照してください。
  • Operator Lifecycle Manager から Ansible Automation Platform Resource Operator がインストールされている。Update Channel セクションで、stable-2.x-cluster-scoped を選択します。All namespaces on the cluster (default) インストールモードを選択します。

    注記: Ansible Automation Platform ジョブテンプレートを実行する際は、べき等であることを確認してください。Ansible Automation Platform Resource Operator がない場合は、Red Hat OpenShift Container Platform OperatorHub ページから確認することができる。

Red Hat Ansible Automation Platform のインストールと設定の詳細は、Ansible タスクの設定 を参照してください。

2.6.3.2. コンソールからのポリシー違反自動化の作成

Red Hat Advanced Cluster Management ハブクラスターにログインし、ナビゲーションメニューから Governance を選択し、Policies タブをクリックしてポリシーテーブルを表示します。

Automation 列の Configure をクリックして、特定のポリシーの自動化を設定します。ポリシー自動化パネルが表示されたら、自動化を作成できます。Ansible credential セクションから、ドロップダウンメニューをクリックして Ansible 認証情報を選択します。認証情報を追加する必要がある場合は、認証情報の管理 を参照してください。

注記: この認証情報は、ポリシーと同じ namespace にコピーされます。自動化の開始用に作成された AnsibleJob リソースで、この認証情報を使用します。コンソールの Credentials セクションで Ansible 認証情報に加えられた変更は、自動的に更新されます。

認証情報を選択したら、Ansible ジョブドロップダウンリストをクリックしてジョブテンプレートを選択します。Extra variables セクションで、PolicyAutomationextra_vars セクションからパラメーター値を追加します。自動化の頻度を選択します。Run once modeRun everyEvent mode、または Disable automation を選択できます。

Submit を選択して、ポリシー違反の自動化を保存します。Ansible ジョブの詳細パネルから View Job リンクを選択すると、このリンクから Search ページのジョブテンプレートが表示されます。自動化が正常に作成されると、Automation 列に表示されます。

注意: ポリシー自動化が関連付けられているポリシーを削除すると、ポリシー自動化はクリーンアップの一部として自動的に削除されます。

コンソールからポリシー違反の自動化が作成されました。

2.6.3.3. CLI からのポリシー違反自動化の作成

CLI からポリシー違反の自動化を設定するには、以下の手順を実行します。

  1. ターミナルから、oc login コマンドを使用して Red Hat Advanced Cluster Management ハブクラスターに再度ログインします。
  2. 自動化を追加するポリシーを検索するか、作成します。ポリシー名と namespace をメモします。
  3. 以下のサンプルをガイドとして使用して、PolicyAutomation リソースを作成します。

    apiVersion: policy.open-cluster-management.io/v1beta1
    kind: PolicyAutomation
    metadata:
      name: policyname-policy-automation
    spec:
      automationDef:
        extra_vars:
          your_var: your_value
        name: Policy Compliance Template
        secret: ansible-tower
        type: AnsibleJob
      mode: disabled
      policyRef: policyname
  4. 前のサンプルの Automation テンプレート名は Policy Compliance Template です。この値は、ジョブテンプレート名と一致するように変更してください。
  5. extra_vars セクションで、Automation テンプレートに渡す必要があるパラメーターを追加します。
  6. モードを onceeveryEvent、または disabled に設定します。
  7. policyRef は、ポリシーの名前に設定します。
  8. Ansible Automation Platform 認証情報を含むこの PolicyAutomation リソースと同じ namespace にシークレットを作成します。上記の例では、シークレット名は ansible-tower です。アプリケーションライフサイクルからののサンプル を使用して、シークレットの作成方法を確認します。
  9. PolicyAutomation リソースを作成します。

    注記:

    • 以下のアノテーションを PolicyAutomation リソースに追加することで、ポリシー自動化の即時実行を開始できます。

      metadata:
        annotations:
          policy.open-cluster-management.io/rerun: "true"
    • ポリシーが once モードの場合は、ポリシーがコンプライアンス違反があると自動化が実行されます。target_clusters という名前の extra_vars 変数が追加され、値はコンプライアンス違反のポリシーが含まれる、各マネージドクラスター名の配列です。
    • ポリシーが everyEvent モードであり、DelayAfterRunSeconds が定義された時間値を超えると、ポリシーは非準拠となり、ポリシー違反ごとに自動化が実行されます。

2.6.4. GitOps を使用したポリシーのデプロイ

ガバナンスフレームワークを使用して、マネージドクラスター全体にポリシーセットをデプロイできます。リポジトリーにポリシーを提供して使用することで、オープンソースコミュニティー (policy-collection) に追加できます。オープンソースコミュニティーの stable フォルダーと community フォルダーのそれぞれにあるポリシーは、NIST Special Publication 800-53 に従ってさらに整理されています。

GitOps を使用して Git リポジトリー経由でポリシーの更新や作成を自動化して追跡する時のベストプラクティスを理解するにはこれ以降のセクションを確認してください。

前提条件: 開始する前に、policy-collection リポジトリーをフォークしてください。

2.6.4.1. ローカルリポジトリーのカスタマイズ

stable および community ポリシーを 1 つのフォルダーにまとめて、ローカルリポジトリーをカスタマイズします。使用しないポリシーを削除します。ローカルリポジトリーをカスタマイズするには、以下の手順を実行します。

  1. リポジトリーに新しいディレクトリーを作成し、デプロイするポリシーを保存します。GitOps のメインのデフォルトブランチに、ローカルの policy-collection リポジトリーにあることを確認します。以下のコマンドを実行します。

    mkdir my-policies
  2. 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.6.4.2. ローカルリポジトリーへのコミット

ディレクトリーに行った変更に問題がなければ、変更を Git にコミットしてプッシュし、クラスターによるアクセスを可能にします。

注記: この例は、GitOps でポリシーを使用する基本的な方法を示しており、ブランチの変更を取得する場合には別のワークフローを使用する場合があります。

以下の手順を実行します。

  1. ターミナルから git status を実行して、以前に作成したディレクトリーに最新の変更を確認します。以下のコマンドを使用して、コミットする変更リストに新しいディレクトリーを追加します。

    git add my-policies/
  2. 変更をコミットし、メッセージをカスタマイズします。以下のコマンドを実行します。

    git commit -m “Policies to deploy to the hub cluster”
  3. GitOps に使用するフォークしたリポジトリーのブランチに、変更をプッシュします。以下のコマンドを実行します。

    git push origin <your_default_branch>master

変更がコミットされます。

2.6.4.3. クラスターへのポリシーのデプロイ

変更をプッシュしたら、ポリシーを Red Hat Advanced Cluster Management for Kubernetes インストールにデプロイできます。デプロイメント後、ハブクラスターは Git リポジトリーに通知されます。Git リポジトリーの選択したブランチに追加された変更がクラスターに反映されます。

注記: デフォルトでは、GitOps でデプロイされるポリシーは マージ の調整オプションを使用します。代わりに replace reconcile オプションを使用する場合は、apps.open-cluster-management.io/reconcile-option: replace アノテーションを Subscription リソースに追加し、apps.open-cluster-management.io/reconcile-option: merge を削除します。Subscription は次のファイルのようになります。

apiVersion: apps.open-cluster-management.io/v1
kind: Subscription
metadata:
  name: subscription-example
  namespace: sub-ns
  annotations:
    apps.open-cluster-management.io/git-path: sample-resources
    apps.open-cluster-management.io/reconcile-option: replace
spec:
...

deploy.sh スクリプトは、ハブクラスターに Channel および Subscription リソースを作成します。チャネルは Git リポジトリーに接続し、サブスクリプションは、チャネルを介してクラスターに配置するデータを指定します。その結果、指定のサブディレクトリーで定義された全ポリシーがハブに作成されます。サブスクリプションによりポリシーが作成されると、Red Hat Advanced Cluster Management はポリシーを分析し、定義した配置ルールに基づいて、ポリシーが適用される各マネージドクラスターに関連付けられた namespace に追加のポリシーリソースを作成します。

その後、ポリシーはハブクラスター上にある該当するマネージドクラスターの namespace からマネージドクラスターにコピーされます。そのため、Git リポジトリーのポリシーは、ポリシーの配置ルールで定義される clusterSelector に一致するラベルが付いた全マネージドクラスターにプッシュされます。

以下の手順を実行します。

  1. policy-collection フォルダーから、以下のコマンドを実行してディレクトリーを変更します。

    cd deploy
  2. 以下のコマンドで、コマンドラインインターフェイス (CLI) が正しいクラスターでリソースを作成するように設定されていることを確認します。

    oc cluster-info

    コマンドの出力には、Red Hat Advanced Cluster Management がインストールされているクラスターの API サーバーの詳細が表示されます。正しい URL が表示されない場合は、CLI を正しいクラスターを参照するように設定します。詳細は、Additional resources セクションの Using the OpenShift CLI を参照してください。

  3. アクセス制御およびポリシー整理を行うポリシーの作成先の namespace を作成します。以下のコマンドを実行します。

    oc create namespace policy-namespace
  4. 以下のコマンドを実行してクラスターにポリシーをデプロイします。

    ./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。これらの手順では、namespace policy-namespace を使用します。デフォルトの namespace は policies です。
    • 名前のプレ接頭辞: Channel および Subscription リソースの接頭辞。デフォルトは demo-stable-policies です。

deploy.sh スクリプトの実行後に、リポジトリーにアクセスできるユーザーはブランチに変更をコミットできます。これにより、クラスターの既存のポリシーに変更がプッシュされます。

注意: サブスクリプションを使用してポリシーをデプロイするには、次の手順を実行します。

  1. open-cluster-management:subscription-admin ClusterRole をサブスクリプションを作成するユーザーにバインドします。
  2. サブスクリプションで許可リストを使用している場合は、次の API エントリーを含めます。

        - apiVersion: policy.open-cluster-management.io/v1
          kinds:
            - "*"
        - apiVersion: policy.open-cluster-management.io/v1beta1
          kinds:
            - "*"
        - apiVersion: apps.open-cluster-management.io/v1
          kinds:
            - PlacementRule # deprecated
        - apiVersion: cluster.open-cluster-management.io/v1beta1
          kinds:
            - Placement

2.6.4.4. コンソールからの GitOps ポリシーデプロイメントの確認

変更がコンソールからポリシーに適用されていることを確認します。コンソールからポリシーをさらに変更することもできますが、Subscription と Git リポジトリーと調整すると、これらの変更は元に戻されます。以下の手順を実行します。

  1. Red Hat Advanced Cluster Management クラスターにログインします。
  2. ナビゲーションメニューから Govern を選択します。
  3. 表にデプロイされたポリシーを見つけます。GitOps を使用してデプロイしたポリシーには、Source 列に Git ラベルが付いています。ラベルをクリックして、Git リポジトリーの詳細を表示します。
2.6.4.4.1. CLI からの GitOps ポリシーデプロイメントの確認

以下の手順を実行します。

  1. 以下のポリシーの詳細を確認してください。

    • 配信先のクラスターで特定のポリシーが準拠している/準拠していないのはなぜか ?
    • ポリシーが正しいクラスターに適用されているか ?
    • このポリシーがクラスターに配布されていない場合は、なぜか ?
  2. 作成または変更した 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 policies.policy.open-cluster-management.io <policy-name> -n <policy-namespace> <key>=<value>

    続いて、以下のコマンドでラベルのあるポリシーをクエリーします。

    oc get policies.policy.open-cluster-management.io -n <policy-namespace> -l <key>=<value>

ポリシーは GitOps を使用してデプロイされます。

2.6.4.5. 関連情報

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.