2.6. 管理安全策略
使用监管仪表板创建、查看和管理安全策略和策略违反情况。您可以通过 CLI 和控制台为您的策略创建 YAML 文件。
2.6.1. 监管页面
Governance 页面中显示以下标签页:
概述
在 Overview 选项卡中查看以下概述卡: Policy set violations,Policy violations,Clusters,Categories, Controls, 和 Standards。
策略集合
创建和管理 hub 集群策略集。
策略(policy)
创建和管理安全策略。策略列表列出了以下策略详情:Name, Namespace, Status, Remediation, Policy set, Cluster violations, Source, Automation 和 Created。当您展开策略行时,会显示 Description, Standards, Controls, 和 Categories。
您可以编辑、启用或禁用,将补救设置为 inform 或 enforce,或通过选择 Actions 图标来删除策略。您可以通过选择要展开行的下拉箭头来查看特定策略的类别和标准。
选择多个策略并点击 Actions 按钮来完成批量操作。您还可以点 Filter 按钮自定义您的策略表。
当您在表列表中选择一个策略时,控制台中会显示以下信息标签页:
- Details :选择 Details 选项卡来查看策略详情和放置详情。在 Placement 表中,Compliance 列提供了查看所显示集群的合规性的链接。
Results :选择 Results 选项卡来查看与放置关联的所有集群的表列表。
从 Message 列中,点 View details 链接来查看模板详情、模板 YAML 和相关资源。您还可以查看相关的资源。点 View history 链接查看违反消息以及最后一次报告的时间。
2.6.2. 监管自动化配置
如果为特定策略配置了自动化,您可以选择自动化来查看更多详情。查看以下自动化调度频率选项的描述:
-
Manual run:手动将此自动化设置为运行一次。在自动化运行后,它将设置为
disabled
。注:您只能在禁用调度频率时选择 Manual run 模式。 -
Run once mode:违反策略时,自动化将运行一次。在自动化运行后,它将设置为
disabled
。在将自动化设置为禁用
后,您必须继续手动运行自动化。当使用 once mode 时,target_clusters
的额外变量会自动提供违反策略的集群列表。Ansible Automation Platform Job 模板需要为EXTRA VARIABLES
段(也称为extra_vars
)启用PROMPT ON LAUNCH
。 -
运行 everyEvent 模式 :违反策略时,每个受管集群的唯一策略都会运行自动化。使用
DelayAfterRunSeconds
参数在同一集群中重启自动化前设置最小秒数。如果策略在延迟期内违反多次,并保持在违反的状态,则自动化会在延迟期后运行一次。默认值为 0 秒,它仅适用于everyEvent
模式。当您运行everyEvent
模式时,target_clusters
和 Ansible Automation Platform 作业模板的额外变量与 once mode 相同。 -
Disable automation:当调度的自动化被设置为
禁用
时,在更新设置前不会运行自动化。
Ansible Automation Platform 作业的 extra_vars
中会自动提供以下变量:
-
policy_name
:在 hub 集群上启动 Ansible Automation Platform 作业的不合规根策略的名称。 -
policy_namespace
: root 策略的命名空间。 -
hub_cluster
:hub 集群的名称,它由集群
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 作业模板是幂等的。如果没有 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 hub 集群后,从导航菜单中选择 Governance,然后点 Policies 选项卡来查看策略表。
单击 Automation 列中的 Configure,为特定策略配置自动化。当策略自动化面板出现时,您可以创建自动化。在 Ansible credential 部分中,单击下拉菜单来选择 Ansible 凭据。如果您需要添加凭证,请参阅管理凭证概述。
注:此凭证复制到与策略相同的命名空间中。该凭据供创建用于启动自动化的 AnsibleJob
资源使用。控制台的 Credentials 部分中的 Ansible 凭据更改会被自动更新。
选择了凭据后,单击 Ansible 作业下拉列表来选择作业模板。在 Extra variables 部分,添加来自 PolicyAutomation
的 extra_vars
部分中的参数值。选择自动化的频率。您可以选择 Run once mode、Run everyEvent mode 或 Disable automation。
选择 Submit 保存您的策略违反自动化。当您从 Ansible 作业详情侧面板选择 View Job 链接时,链接会将您定向到 Search 页面上的作业模板。成功创建自动化后,它会显示在 Automation 列中。
注: 当您删除具有关联策略自动化的策略时,策略自动化会在清理过程中自动删除。
您的策略违反自动化是从控制台创建的。
2.6.3.3. 通过 CLI 创建策略违反自动化
完成以下步骤,通过 CLI 配置策略违反自动化:
-
在终端中,使用
oc login
命令登录到 Red Hat Advanced Cluster Management hub 集群。 - 查找或创建您要向其添加自动化的策略。请注意策略名称和命名空间。
使用以下示例创建
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
-
上例中的 Automation 模板名称是
Policy Compliance Template
。更改该值,使其与您的任务模板名称匹配。 -
在
extra_vars
部分中,添加您需要传递给 Automation 模板的任何参数。 -
将模式设置为
once
、everyEvent
或disabled
。 -
将
policyRef
设置为您的策略的名称。 -
在与包含 Ansible Automation Platform 凭据的
PolicyAutomation
资源相同的命名空间中创建一个 secret。在上例中,secret 名称为ansible-tower
。使用应用程序生命周期中的示例来查看如何创建 secret。 创建
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 存储库自动化和跟踪策略更新和创建的最佳做法。
先决条件:开始之前,请务必 fork policy-collection
存储库。
2.6.4.1. 自定义本地存储库
通过将 stable
和 community
策略整合到单个文件夹中,自定义您的本地存储库。删除您不想使用的策略。完成以下步骤以自定义您的本地存储库:
在存储库中创建一个新目录,以存放您要部署的策略。确保您位于 GitOps 的主要默认分支的本地
policy-collection
存储库中。运行以下命令:mkdir my-policies
将所有
stable
和community
策略复制到您的my-policies
目录中。首先,如果stable
文件夹包含community
中可用内容的副本,则首先从社区策略开始。运行以下命令:cp -R community/* my-policies/ cp -R stable/* my-policies/
现在,您在一个父目录结构中已有所有策略,您可以在 fork 中编辑策略。
提示:
- 最佳做法是删除您不打算使用的策略。
从以下列表中了解策略和策略定义:
- 用途:了解策略的作用。
补救操作:该策略是否仅告知您合规,还是强制执行策略并进行更改?请参阅
spec.remediationAction
参数。如果强制进行更改,请确保您了解功能预期。记得检查哪些策略支持执行。如需更多信息,请参阅 Validate 部分。注:策略的
spec.remediationAction
设置覆盖单个spec.policy-templates
中设置的任何补救操作。-
placement:策略部署到哪些群集?默认情况下,大多数策略都以带有
environment: dev
标签的集群为目标。有些策略可能针对 OpenShift Container Platform 集群或其他标签。您可以更新或添加附加标签来包括其他集群。如果没有特定值,策略会应用到所有集群。您还可以创建策略的多个副本并为每个副本自定义,如果您想要使用一组集群配置的一种策略,并为另一组集群配置另一种方式。
2.6.4.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.6.4.3. 在集群中部署策略
在推送更改后,您可以将策略部署到 Red Hat Advanced Cluster Management for Kubernetes 安装中。在部署后,您的 hub 集群连接到 Git 存储库。对 Git 存储库所选分支的任何其他更改都会反映在集群中。
注: 默认情况下,通过 GitOps 部署的策略使用 merge
reconcile 选项。如果要使用 replace
协调选项,将 apps.open-cluster-management.io/reconcile-option: replace
注解添加到 Subscription
资源,并删除 apps.open-cluster-management.io/reconcile-option: merge
。您的订阅
可能类似以下文件:
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
脚本在 hub 集群中创建 Channel
和 Subscription
资源。频道连接到 Git 仓库,订阅指定要通过频道传递给集群的数据。因此,在您的 hub 上会创建指定子目录中定义的所有策略。在订阅创建策略后,Red Hat Advanced Cluster Management 会根据定义的放置规则分析策略,并在与策略应用到的每个受管集群关联的命名空间中创建额外的策略资源。
该策略随后从 hub 集群上对应的受管集群命名空间中复制到受管集群。因此,Git 仓库中的策略推送到具有与策略放置规则中定义的 clusterSelector
匹配的所有受管集群。
完成以下步骤:
在
policy-collection
文件夹中运行以下命令来更改目录:cd deploy
请确定将命令行界面(CLI)配置为使用以下命令在正确的集群中创建资源:
oc cluster-info
命令的输出显示集群的 API 服务器详情,其中安装了 Red Hat Advanced Cluster Management。如果没有显示正确的 URL,请将 CLI 配置为指向正确的集群。如需更多信息,请参阅附加资源部分中的使用 OpenShift CLI。
创建一个命名空间,创建您的策略以控制访问和组织策略。运行以下命令:
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:在 hub 集群中创建资源和策略的命名空间。这些说明使用
policy-namespace
命名空间。默认命名空间是policies
。 -
名称前缀:
Channel
和Subscription
资源的前缀。默认为demo-stable-policies
。
-
URL:从主
运行 deploy.sh
脚本后,有权访问存储库的任何用户都可以提交更改到分支,该分支会将更改推送到集群上执行策略。
注:要使用订阅部署策略,请完成以下步骤:
-
将
open-cluster-management:subscription-admin
ClusterRole 绑定到创建订阅的用户。 如果您在订阅中使用允许列表,请包含以下 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 策略部署
从控制台验证您的更改是否已应用于您的策略。您还可以从控制台对策略进行更多更改,但当 订阅
与 Git 存储库协调时,会恢复更改。完成以下步骤:
- 登录您的 Red Hat Advanced Cluster Management 集群。
- 在导航菜单中选择 Governance。
- 查找您在表中部署的策略。使用 GitOps 部署的策略在 Source 列中具有 Git 标签。单击该标签,以查看 Git 存储库的详细信息。
2.6.4.4.1. 通过 CLI 验证 GitOps 策略部署
完成以下步骤:
检查以下策略详情:
- 为什么一个特定的策论在所分发的集群中合规或不合规?
- 策略是否应用到正确的集群?
- 如果此策略没有分发到任何集群,为什么?
识别您创建或修改的 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. 其他资源
-
请参阅开源社区
policy-collection
。 - 有关标准,请参阅 NIST 特殊发布 800-53。
- 如需更多信息,请参阅使用 OpenShift CLI。
- 有关如何贡献开源社区的更多信息,请参阅贡献自定义策略。
- 有关资源覆盖示例的详情,请参阅应用程序生命周期。
- 返回到此主题的开头,使用 GitOps 部署策略。