2.3. hub 集群策略框架

2.3.1. 要求

每个策略都需要一个 Placement 资源来定义策略文档要应用到的集群，以及绑定 Red Hat Advanced Cluster Management for Kubernetes 策略的 PlacementBinding 资源。
策略资源根据关联的 放置 定义应用到集群，您可以在其中查看与特定条件匹配的受管集群列表。与带有 environment=dev 标签的所有集群匹配的 放置资源 示例类似以下 YAML：
```
apiVersion: cluster.open-cluster-management.io/v1beta1
kind: Placement
metadata:
  name: placement-policy-role
spec:
  predicates:
  - requiredClusterSelector:
    labelSelector:
    matchExpressions:
      - {key: environment, operator: In, values: ["dev"]}
```
要了解更多有关放置和支持的标准的信息，请参阅集群生命周期文档中的放置概述。
除了 Placement 资源外，还需要创建一个 PlacementBinding，将 放置资源 绑定到策略。与带有 environment=dev 标签的所有集群匹配的 放置资源 示例类似以下 YAML：
```
apiVersion: policy.open-cluster-management.io/v1
kind: PlacementBinding
metadata:
  name: binding-policy-role
placementRef:
  name: placement-policy-role 1
  kind: Placement
  apiGroup: cluster.open-cluster-management.io
subjects: 2
- name: policy-role
  kind: Policy
  apiGroup: policy.open-cluster-management.io
```
1
如果使用上例，请确保更新 placementRef 部分中的 Placement 资源的名称，以匹配您的放置名称。
2
您必须更新 subjects 部分中的策略名称，以匹配您的策略名称。使用 oc apply -f resource.yaml -n namespace 命令应用 Placement 和 Placementbinding 资源。确保策略、放置和放置绑定都在同一个命名空间中创建。
要使用 放置资源，您必须将 ManagedClusterSet 资源绑定到带有 ManagedClusterSetBinding 资源的 Placement 资源的命名空间。如需了解更多详细信息，请参阅创建 ManagedClusterSetBinding 资源。
从控制台创建策略的 放置资源 时，放置容限的状态会自动添加到 Placement 资源中。如需了解更多详细信息，请参阅向放置添加容限。

最佳实践 ：在使用 Placement 资源时，使用命令行界面(CLI) 来更新策略。

2.3.2. hub 集群策略组件

在以下部分了解更多有关策略组件的详细信息：

2.3.2.1. 策略 YAML 结构

创建策略时，必须包含所需的参数字段和值。根据您的策略控制器，您可能需要包含其他可选字段和值。查看策略的以下 YAML 结构：

apiVersion: policy.open-cluster-management.io/v1
kind: Policy
metadata:
  name:
  annotations:
    policy.open-cluster-management.io/standards:
    policy.open-cluster-management.io/categories:
    policy.open-cluster-management.io/controls:
    policy.open-cluster-management.io/description:
spec:
  disabled:
  remediationAction:
  dependencies:
  - apiVersion: policy.open-cluster-management.io/v1
    compliance:
    kind: Policy
    name:
    namespace:
  policy-templates:
    - objectDefinition:
        apiVersion:
        kind:
        metadata:
          name:
        spec:
---
apiVersion: policy.open-cluster-management.io/v1
kind: PlacementBinding
metadata:
bindingOverrides:
  remediationAction:
subFilter:
  name:
placementRef:
  name:
  kind: Placement
  apiGroup: cluster.open-cluster-management.io
subjects:
- name:
  kind:
  apiGroup:
---
apiVersion: cluster.open-cluster-management.io/v1beta1
kind: Placement
metadata:
  name:
spec:

2.3.2.2. 策略 YAML 表

查看下表以了解策略参数描述：

表 2.1. 参数表
字段	可选或必需的	描述
`apiVersion`	必填	将值设置为 `policy.open-cluster-management.io/v1`。
`kind`	必填	将值设为 `Policy` 以表示策略类型。
`metadata.name`	必填	用于标识策略资源的名称。
`metadata.annotations`	选填	用于指定一组描述策略试图验证的标准集合的安全详情。这里介绍的所有注解都以逗号分隔的字符串表示。注：您可以在控制台中根据您在策略页面上为策略定义的标准和类别查看策略违反。
`bindingOverrides.remediationAction`	选填	当此参数设置为 `enforce` 时，它为您提供了覆盖配置策略相关 `PlacementBinding` 资源的补救操作。默认值为 `null`。
`subFilter`	选填	将此参数设置为 `restriction`，以选择绑定策略的子集。默认值为 `null`。
`annotations.policy.open-cluster-management.io/standards`	选填	与策略相关的安全标准的名称。例如，美国国家标准与技术研究院 (NIST) 和支付卡行业 (PCI)。
`annotations.policy.open-cluster-management.io/categories`	选填	安全控制类别是针对一个或多个标准的具体要求。例如，系统和信息完整性类别可能表明您的策略包含一个数据传输协议来保护个人信息，符合 HIPAA 和 PCI 标准的要求。
`annotations.policy.open-cluster-management.io/controls`	选填	正在接受检查的安全控制名称。例如，访问控制或系统及信息完整性。
`spec.disabled`	必填	将值设为 `true` 或 `false`。`disabled` 参数提供启用和禁用策略的功能。
`spec.remediationAction`	选填	指定您的策略的修复。参数值是 `enforce` 和 `inform`。如果指定，定义的 `spec.remediationAction` 值会覆盖 `policy-templates` 部分的子策略中定义的 `remediationAction` 参数。例如，如果 `spec.remediationAction` 值被设置为 `enforce`，则 `policy-templates` 部分中的 `remediationAction` 会在运行时被设置为 `enforce`。
`spec.copyPolicyMetadata`	选填	指定在将策略应用到受管集群时是否应复制策略的标签和注解。如果设置为 `true`，则策略的所有标签和注解都会被复制到复制策略中。如果设置为 `false`，则只有策略框架特定的策略标签和注解才会复制到复制策略中。
`spec.dependencies`	选填	用于创建与满足合规性的额外注意事项相关的依赖关系对象列表。
`spec.policy-templates`	必填	用于创建一个或多个应用到受管集群的策略。
`spec.policy-templates.extraDependencies`	选填	对于策略模板，这用于创建依赖项对象列表，以及满足合规性的额外注意事项。
`spec.policy-templates.ignorePending`	选填	用于在验证依赖项条件前将策略模板标记为合规。重要：有些策略类型可能不支持 enforce 功能。

2.3.2.3. 策略示例文件

查看以下 YAML 文件，它是角色的配置策略：

apiVersion: policy.open-cluster-management.io/v1
kind: Policy
metadata:
  name: policy-role
  annotations:
    policy.open-cluster-management.io/standards: NIST SP 800-53
    policy.open-cluster-management.io/categories: AC Access Control
    policy.open-cluster-management.io/controls: AC-3 Access Enforcement
    policy.open-cluster-management.io/description:
spec:
  remediationAction: inform
  disabled: false
  policy-templates:
    - objectDefinition:
        apiVersion: policy.open-cluster-management.io/v1
        kind: ConfigurationPolicy
        metadata:
          name: policy-role-example
        spec:
          remediationAction: inform # the policy-template spec.remediationAction is overridden by the preceding parameter value for spec.remediationAction.
          severity: high
          namespaceSelector:
            include: ["default"]
          object-templates:
            - complianceType: mustonlyhave # role definition should exact match
              objectDefinition:
                apiVersion: rbac.authorization.k8s.io/v1
                kind: Role
                metadata:
                  name: sample-role
                rules:
                  - apiGroups: ["extensions", "apps"]
                    resources: ["deployments"]
                    verbs: ["get", "list", "watch", "delete","patch"]
---
apiVersion: policy.open-cluster-management.io/v1
kind: PlacementBinding
metadata:
  name: binding-policy-role
placementRef:
  name: placement-policy-role
  kind: Placement
  apiGroup: cluster.open-cluster-management.io
subjects:
- name: policy-role
  kind: Policy
  apiGroup: policy.open-cluster-management.io
---
apiVersion: cluster.open-cluster-management.io/v1beta1
kind: Placement
metadata:
  name: placement-policy-role
spec:
  predicates:
  - requiredClusterSelector:
      labelSelector:
        matchExpressions:
        - {key: environment, operator: In, values: ["dev"]}

2.3.3. 其他资源

继续阅读 Red Hat Advanced Cluster Management 监管框架的相关主题：

2.3.4. 策略依赖项

只有在集群中的其他策略处于特定状态时，才会使用依赖项来激活策略。当不满足依赖项条件时，策略被标记为 Pending，资源不会在受管集群上创建。有关策略状态中的条件状态的更多详细信息。

您可以使用策略依赖项来控制对象的应用方式的顺序。例如，如果您有一个 Operator 策略以及 Operator 所管理的资源的另一个策略，您可以设置第二个策略的依赖项，以便它不会尝试创建资源，直到安装 Operator 前不会尝试创建资源。这有助于在受管集群上的性能。

需要的访问权限：策略管理员

查看以下策略依赖项示例，只有 upstream-compliance-operator 策略已在受管集群中合规时才会创建 ScanSettingBinding ：

apiVersion: policy.open-cluster-management.io/v1
kind: Policy
metadata:
  annotations:
    policy.open-cluster-management.io/categories: CM Configuration Management
    policy.open-cluster-management.io/controls: CM-2 Baseline Configuration
    policy.open-cluster-management.io/standards: NIST SP 800-53
    policy.open-cluster-management.io/description:
  name: moderate-compliance-scan
  namespace: default
spec:
  dependencies: 1
  - apiVersion: policy.open-cluster-management.io/v1
    compliance: Compliant
    kind: Policy
    name: upstream-compliance-operator
    namespace: default
  disabled: false
  policy-templates:
  - extraDependencies: 2
    - apiVersion: policy.open-cluster-management.io/v1
      kind: ConfigurationPolicy
      name: scan-setting-prerequisite
      compliance: Compliant
    ignorePending: false 3
    objectDefinition:
      apiVersion: policy.open-cluster-management.io/v1
      kind: ConfigurationPolicy
      metadata:
        name: moderate-compliance-scan
      spec:
        object-templates:
        - complianceType: musthave
          objectDefinition:
            apiVersion: compliance.openshift.io/v1alpha1
            kind: ScanSettingBinding
            metadata:
              name: moderate
              namespace: openshift-compliance
            profiles:
            - apiGroup: compliance.openshift.io/v1alpha1
              kind: Profile
              name: ocp4-moderate
            - apiGroup: compliance.openshift.io/v1alpha1
              kind: Profile
              name: ocp4-moderate-node
            settingsRef:
              apiGroup: compliance.openshift.io/v1alpha1
              kind: ScanSetting
              name: default
        remediationAction: enforce
        severity: low

1: dependencies 字段在 Policy 对象中设置，要求适用于策略中的所有策略模板。
2: 可以在单独的策略模板上设置 extraDependencies 字段。例如，可以为配置策略设置参数，并且定义在策略中设置的任何 依赖项 之外必须满足的条件。
3: ignorePending 字段可以在每个单独的策略模板上设置，并在计算总体策略合规性时，配置该模板上的 Pending 状态是否被视为 Compliant 或 NonCompliant。默认情况下，此值设为 false，而 Pending 模板会导致策略变为 NonCompliant。当您将其设置为 true 时，当此模板为 Pending 时，策略仍然可以为 Compliant，这在模板的预期状态下非常有用。

注：您不能使用依赖项根据另一个集群中的策略状态对一个集群应用策略。

2.3.5. 配置策略合规历史记录 API （技术预览）（已弃用）

如果您希望长期存储 Red Hat Advanced Cluster Management for Kubernetes 策略合规事件，策略合规历史记录 API 是一个可选的技术预览功能。您可以使用 API 获取额外详情，如 spec 字段来审核和排除您的策略，并在策略被禁用或从集群中删除时获取合规性事件。

策略合规历史记录 API 也可以生成以逗号分隔的值(CSV)电子策略合规事件表，以帮助您进行审核和故障排除。

2.3.5.1. 先决条件

策略合规历史记录 API 需要版本 13 或更新版本上的 PostgreSQL 服务器。
一些红帽支持的选项包括使用 registry.redhat.io/rhel9/postgresql-15 容器镜像、registry.redhat.io/rhel8/postgresql-13 容器镜像、postgresql-server RPM 或 postgresql/server 模块。查看适用于您选择的路径的有关设置和配置适用的官方红帽文档。策略合规历史记录 API 与任何标准 PostgreSQL 兼容，不受官方红帽支持的产品的限制。
此 PostgreSQL 服务器必须可从 Red Hat Advanced Cluster Management hub 集群访问。如果 PostgreSQL 服务器在 hub 集群外部运行，请确保路由和防火墙配置允许 hub 集群连接到 PostgreSQL 服务器的端口 5432。如果在 PostgreSQL 配置中被覆盖，这个端口可能是不同的值。

2.3.5.2. 启用合规性历史记录 API

配置受管集群，将策略合规事件记录到 API。您可以在所有集群或集群子集中启用它。完成以下步骤：

将 PostgreSQL 服务器配置为集群管理员。如果您在 Red Hat Advanced Cluster Management hub 集群中部署了 PostgreSQL，请临时端口转发 PostgreSQL 端口以使用 psql 命令。运行以下命令:
```
oc -n <PostgreSQL namespace> port-forward <PostgreSQL pod name> 5432:5432
```
在不同的终端中，连接到本地的 PostgreSQL 服务器，使用以下命令：
```
psql 'postgres://postgres:@127.0.0.1:5432/postgres'
```

使用以下 SQL 语句为您的 Red Hat Advanced Cluster Management hub 集群创建一个用户和数据库：

CREATE USER "rhacm-policy-compliance-history" WITH PASSWORD '<replace with password>';
CREATE DATABASE "rhacm-policy-compliance-history" WITH OWNER="rhacm-policy-compliance-history";

创建 governance-policy-database Secret 资源，将此数据库用于策略合规历史记录 API。运行以下命令:
```
oc -n open-cluster-management create secret generic governance-policy-database \ 1
    --from-literal="user=rhacm-policy-compliance-history" \
    --from-literal="password=rhacm-policy-compliance-history" \
    --from-literal="host=<replace with host name of the Postgres server>" \ 2
    --from-literal="dbname=ocm-compliance-history" \
  --from-literal="sslmode=verify-full" \
    --from-file="ca=<replace>" 3
```
1
添加安装 Red Hat Advanced Cluster Management 的命名空间。默认情况下，Red Hat Advanced Cluster Management 安装在 open-cluster-management 命名空间中。
2
添加 PostgresQL 服务器的主机名。如果您在 Red Hat Advanced Cluster Management hub 集群中部署了 PostgreSQL 服务器，且没有在集群外公开，您可以使用 Service 对象作为主机值。格式为 < service name>.<namespace>.svc。请注意，此方法取决于 Red Hat Advanced Cluster Management hub 集群的网络策略。
3
您必须在为 PostgreSQL 服务器的 TLS 证书签名的 ca data 字段中指定证书颁发机构证书文件。如果没有提供这个值，您必须相应地更改 sslmode 值，但不建议这样做，因为它减少了数据库连接的安全性。
添加 cluster.open-cluster-management.io/backup 标签，以备份 Red Hat Advanced Cluster Management hub 集群恢复操作的 Secret 资源。运行以下命令:
```
oc -n open-cluster-management label secret governance-policy-database cluster.open-cluster-management.io/backup=""
```
要对 PostgreSQL 连接进行更多自定义，请直接使用 connectionURL data 字段，并以 PostgreSQL 连接 URI 格式提供值。密码中的特殊字符必须采用 URL 编码。种选择是使用 Python 生成密码编码的 URL 格式。例如，如果密码是 $uper<Secr&t% >，请运行以下 Python 命令以获取输出 %24uper%3CSecr%26t%25%3E ：
```
python -c 'import urllib.parse; import sys; print(urllib.parse.quote(sys.argv[1]))' '$uper<Secr&t%>'
```
在创建 governance-policy-database Secret 后，运行命令以测试策略合规历史记录 API。在同一命名空间中自动创建 OpenShift Route 对象。如果 Red Hat Advanced Cluster Management hub 集群上的路由没有使用可信证书，您可以选择在 curl 命令中提供 a -k 标志来跳过 TLS 验证，但不建议这样做：
```
curl -H "Authorization: Bearer $(oc whoami --show-token)" \
    "https://$(oc -n open-cluster-management get route governance-history-api -o jsonpath='{.spec.host}')/api/v1/compliance-events"
```
- 如果成功，curl 命令会返回类似如下的值：
```
{"data":[],"metadata":{"page":1,"pages":0,"per_page":20,"total":0}}
```
- 如果没有成功，curl 命令可能会返回两个信息之一：
```
{"message":"The database is unavailable"}
```
```
{"message":"Internal Error"}
```
- 如果您收到信息，使用以下命令查看 open-cluster-management 命名空间中的 Kubernetes 事件：
```
oc -n open-cluster-management get events --field-selector reason=OCMComplianceEventsDBError
```
  1. 如果您收到来自事件的说明来查看 governance-policy-propagator 日志，请运行以下命令：
    oc -n open-cluster-management logs -l name=governance-policy-propagator -f
  您可能会收到一条错误消息，指出用户、密码或数据库被错误指定。请参见以下消息示例：
```
2024-03-05T12:17:14.500-0500	info	compliance-events-api	complianceeventsapi/complianceeventsapi_controller.go:261	The database connection failed: pq: password authentication failed for user "rhacm-policy-compliance-history"
```
使用以下命令，使用正确的 PostgreSQL 连接设置来更新 governance-policy-database Secret 资源：
```
oc -n open-cluster-management edit secret governance-policy-database
```

2.3.5.3. 设置合规性历史记录 API URL

设置策略合规历史记录 API URL，以在受管集群中启用该功能。完成以下步骤：

使用以下命令检索策略合规历史记录 API 的外部 URL：

echo "https://$(oc -n open-cluster-management get route governance-history-api -o=jsonpath='{.spec.host}')"

输出可能类似以下信息，以及 Red Hat Advanced Cluster Management hub 集群的域名：

https://governance-history-api-open-cluster-management.apps.openshift.redhat.com

创建一个类似以下示例的 AddOnDeploymentConfig 对象：

apiVersion: addon.open-cluster-management.io/v1alpha1
kind: AddOnDeploymentConfig
metadata:
  name: governance-policy-framework
  namespace: open-cluster-management
spec:
  customizedVariables:
    - name: complianceHistoryAPIURL
      value: <replace with URL from previous command>

将 value 参数值替换为您的合规性历史记录外部 URL。

2.3.5.3.1. 在所有受管集群中启用

在所有受管集群上启用合规历史记录 API，以记录来自受管集群的合规性事件。完成以下步骤：

使用以下命令将 governance-policy-framework ClusterManagementAddOn 对象配置为使用 AddOnDeploymentConfig ：
```
oc edit ClusterManagementAddOn governance-policy-framework
```

添加或更新 spec.supportedConfigs 数组。您的资源可能有以下配置：

  - group: addon.open-cluster-management.io
    resource: addondeploymentconfigs
    defaultConfig:
      name: governance-policy-framework
      namespace: open-cluster-management

2.3.5.3.2. 在单个受管集群中启用合规性历史记录

在单个受管集群上启用合规性历史记录 API，以记录来自受管集群的合规性事件。完成以下步骤：

在受管集群命名空间中配置 governance-policy-framework ManagedClusterAddOn 资源。使用以下命令，从 Red Hat Advanced Cluster Management hub 集群中运行以下命令：
```
oc -n <manage-cluster-namespace> edit ManagedClusterAddOn governance-policy-framework
```
- 将 & lt;manage-cluster-namespace > 占位符替换为您要启用的受管集群名称。

添加或更新 spec.configs 数组，使其包含类似以下示例的条目：

- group: addon.open-cluster-management.io
  resource: addondeploymentconfigs
  name: governance-policy-framework
  namespace: open-cluster-management

要验证配置，请确认受管集群上的部署是否使用 --compliance-api-url 容器参数。运行以下命令:

oc -n open-cluster-management-agent-addon get deployment governance-policy-framework -o jsonpath='{.spec.template.spec.containers[1].args}'

输出可能类似以下：

["--enable-lease=true","--hub-cluster-configfile=/var/run/klusterlet/kubeconfig","--leader-elect=false","--log-encoder=console","--log-level=0","--v=-1","--evaluation-concurrency=2","--client-max-qps=30","--client-burst=45","--disable-spec-sync=true","--cluster-namespace=local-cluster","--compliance-api-url=https://governance-history-api-open-cluster-management.apps.openshift.redhat.com"]

任何新的策略合规事件都会记录在策略合规历史记录 API 中。

如果没有记录特定受管集群的策略合规事件，请查看受影响受管集群的 governance-policy-framework 日志：
```
oc -n open-cluster-management-agent-addon logs deployment/governance-policy-framework -f
```

此时会显示类似以下消息的日志消息。如果 消息 值为空，策略合规历史记录 API URL 不正确，或者存在网络通信问题：

024-03-05T19:28:38.063Z        info    policy-status-sync      statussync/policy_status_sync.go:750    Failed to record the compliance event with the compliance API. Will requeue.       {"statusCode": 503, "message": ""}

如果策略合规历史记录 API URL 不正确，使用以下命令编辑 hub 集群上的 URL：

oc -n open-cluster-management edit AddOnDeploymentConfig governance-policy-framework

+ 注意： 如果您遇到网络通信问题，您必须根据网络基础架构诊断问题。

2.3.5.4. 其他资源

2.3.6. 集成策略生成器

通过集成策略生成器，您可以使用它来自动构建 Red Hat Advanced Cluster Management for Kubernetes 策略。要集成策略生成器，请参阅策略生成器。

有关您可以使用 Policy Generator 执行的操作示例，请参阅生成安装 Compliance Operator 的策略。

2.3.7. 策略生成器

Policy Generator 是 Red Hat Advanced Cluster Management for Kubernetes 应用程序生命周期订阅 Red Hat OpenShift GitOps 工作流的一部分，该工作流使用 Kustomize 生成 Red Hat Advanced Cluster Management 策略。策略生成器从 Kubernetes 清单 YAML 文件构建 Red Hat Advanced Cluster Management 策略，该文件通过用于配置它的 PolicyGenerator 清单 YAML 文件提供。策略生成器作为 Kustomize 生成器插件实施。有关 Kustomize 的更多信息，请阅读 Kustomize 文档。

查看以下部分以了解有关 Policy Generator 的更多信息：

2.3.7.1. 策略生成器功能

Policy Generator 与 Red Hat Advanced Cluster Management 应用程序生命周期订阅 OpenShift GitOps 工作流集成简化了 Kubernetes 资源对象分发到受管 OpenShift Container Platform 集群，以及通过 Red Hat Advanced Cluster Management 策略的 Kubernetes 集群分布。

使用 Policy Generator 完成以下操作：

将任何 Kubernetes 清单文件转换为 Red Hat Advanced Cluster Management 配置策略，包括从 Kustomize 目录创建的清单。
在将输入 Kubernetes 清单插入到生成的 Red Hat Advanced Cluster Management 策略前对其进行补丁。
生成额外的配置策略，以便您可以通过 Red Hat Advanced Cluster Management for Kubernetes 报告 Gatekeeper 策略违反情况。
在 hub 集群上生成策略集。

2.3.7.2. 策略生成器配置结构

策略生成器是一个 Kustomize 生成器插件，它配置了一个 PolicyGenerator kind 和 policy.open-cluster-management.io/v1 API 版本的清单。继续阅读以了解配置结构：

要使用插件，请在 kustomization.yaml 文件中添加一个 generators 部分。查看以下示例：
```
generators:
  - policy-generator-config.yaml 1
```
1
上例中引用的 policy-generator-config.yaml 文件是一个 YAML 文件，其中包含要生成的策略的说明。

简单的 PolicyGenerator 配置文件可能类似以下示例，带有 policyDefaults 和 policies ：

apiVersion: policy.open-cluster-management.io/v1
kind: PolicyGenerator
metadata:
  name: config-data-policies
policyDefaults:
  namespace: policies
  policySets: []
policies:
  - name: config-data
    manifests:
      - path: configmap.yaml 1

1: configmap.yaml 文件代表要包含在策略中的 Kubernetes 清单 YAML 文件。另外，您可以设置 Kustomize 目录的路径，或者设置具有多个 Kubernetes 清单 YAML 文件的目录。查看以下 ConfigMap 示例：

apiVersion: v1
kind: ConfigMap
metadata:
  name: my-config
  namespace: default
data:
  key1: value1
  key2: value2

您可以使用 object-templates-raw 清单自动生成带有您添加的内容的 ConfigurationPolicy 资源。例如，您可以使用以下语法创建清单文件：

object-templates-raw: |
  {{- range (lookup "v1" "ConfigMap" "my-namespace" "").items }}
  - complianceType: musthave
    objectDefinition:
      kind: ConfigMap
      apiVersion: v1
      metadata:
        name: {{ .metadata.name }}
        namespace: {{ .metadata.namespace }}
        labels:
          i-am-from: template
  {{- end }}

创建清单文件后，您可以创建一个 PolicyGenerator 配置文件。请参阅以下 YAML 示例以及 路径，请输入 manifest.yaml 文件的路径：

apiVersion: policy.open-cluster-management.io/v1
kind: PolicyGenerator
metadata:
  name: config-data-policies
policyDefaults:
  namespace: policies
  policySets: []
policies:
  - name: config-data
    manifests:
      - path: manifest.yaml

生成的 Policy 资源以及生成的 放置资源 和 PlacementBinding 资源可能类似以下示例。注：资源规格在 Policy Generator 配置参考表中 进行了描述。

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: Placement
metadata:
  name: placement-config-data
  namespace: policies
spec:
  predicates:
  - requiredClusterSelector:
      labelSelector:
        matchExpressions: []
---
apiVersion: policy.open-cluster-management.io/v1
kind: PlacementBinding
metadata:
  name: binding-config-data
  namespace: policies
placementRef:
  apiGroup: cluster.open-cluster-management.io
  kind: Placement
  name: placement-config-data
subjects:
- apiGroup: policy.open-cluster-management.io
  kind: Policy
  name: config-data
---
apiVersion: policy.open-cluster-management.io/v1
kind: Policy
metadata:
  annotations:
    policy.open-cluster-management.io/categories: CM Configuration Management
    policy.open-cluster-management.io/controls: CM-2 Baseline Configuration
    policy.open-cluster-management.io/standards: NIST SP 800-53
    policy.open-cluster-management.io/description:
  name: config-data
  namespace: policies
spec:
  disabled: false
  policy-templates:
  - objectDefinition:
      apiVersion: policy.open-cluster-management.io/v1
      kind: ConfigurationPolicy
      metadata:
        name: config-data
      spec:
        object-templates:
        - complianceType: musthave
          objectDefinition:
            apiVersion: v1
            data:
              key1: value1
              key2: value2
            kind: ConfigMap
            metadata:
              name: my-config
              namespace: default
        remediationAction: inform
        severity: low

2.3.7.3. 策略生成器配置参考表

policyDefaults 部分的所有字段( 命名空间 除外)可以被为每个策略覆盖，并且 policySetDefaults 部分中的所有字段都可以覆盖每个策略集。

表 2.2. 参数表
字段	可选或必需的	描述
`apiVersion`	必填	将值设置为 `policy.open-cluster-management.io/v1`。
`kind`	必填	将值设为 `PolicyGenerator` 以表示策略类型。
`metadata.name`	必填	用于标识策略资源的名称。
`placementBindingDefaults.name`	选填	如果多个策略使用相同的放置，则使用此名称为生成的 `PlacementBinding` 生成唯一名称，将放置与引用它的策略数组绑定。
`policyDefaults`	必填	对于 policies 数组中的条目，这里列出的任何默认值都会被覆盖，但 `namespace` 除外。
`policyDefaults.namespace`	必填	所有策略的命名空间。
`policyDefaults.complianceType`	选填	决定在将清单与集群上对象进行比较时的策略控制器行为。您可以使用的值是 `musthave`、`musthave` 或 `mustnothave`。默认值为 `musthave`。
`policyDefaults.metadataComplianceType`	选填	在将清单元数据部分与集群中的对象进行比较时，会覆盖 `complianceType`。您可以使用的值是 `musthave` 和 `mustonlyhave`。默认值为空 (`{}`)，以避免覆盖元数据的 `complianceType`。
`policyDefaults.categories`	选填	`policy.open-cluster-management.io/categories` 注解中使用的类别数组。默认值为 `CM 配置管理`。
`policyDefaults.controls`	选填	`policy.open-cluster-management.io/controls` 注解中使用的控制数组。默认值为 `CM-2 Baseline Configuration`。
`policyDefaults.standards`	选填	`policy.open-cluster-management.io/standards` 注解中使用的一组标准。默认值为 `NIST SP 800-53`。
`policyDefaults.policyAnnotations`	选填	策略在 `metadata.annotations` 部分中包含的注解。除非在策略中指定的，否则会适用于所有策略。默认值为空 (`{}`)。
`policyDefaults.configurationPolicyAnnotations`	选填	用于对生成的配置策略设置的注解的键值对。例如，您可以通过定义以下参数来禁用策略模板： `{"policy.open-cluster-management.io/disable-templates": "true"}`。默认值为空 (`{}`)。
`policyDefaults.copyPolicyMetadata`	选填	复制所有策略的标签和注解，并将它们添加到副本策略中。默认设置为 `true`。如果设置为 `false`，则只有策略框架特定的策略标签和注解复制到复制策略中。
`policyDefaults.customMessage`	选填	配置策略发送的合规性消息，使其根据当前的合规性使用指定的 Go 模板之一。
`policyDefaults.severity`	选填	策略违反的严重性。默认值为 `low`。
`policyDefaults.disabled`	选填	策略是否被禁用，代表不会传播它，因此结果为没有状态。默认值为 `false`，这会启用策略。
`policyDefaults.remediationAction`	选填	策略的补救机制。参数值是 `enforce` 和 `inform`。默认值是 `inform`。
`policyDefaults.namespaceSelector`	没有指定命名空间的命名空间对象是必需的	决定对象要应用到的受管集群中的命名空间。`include` 和 `exclude` 参数接受根据名称包含和排除命名空间的文件路径表达式。`matchExpressions` 和 `matchLabels` 参数指定要包含的命名空间。请参阅 Kubernetes 标签和选择器文档。生成的列表通过使用来自所有参数的结果的交集进行编译。
`policyDefaults.evaluationInterval`	选填	指定处于特定合规状态时要评估的策略的频率。使用 `合规` 和 `不合规的` 参数。`合规和非合规参数的默认值` 是 `监视` 使用 Kubernetes API 监视而不是轮询 Kubernetes API 服务器。当受管集群具有较低资源时，可以将评估间隔设置为长时间轮询间隔，以减少 Kubernetes API 和策略控制器上的 CPU 和内存使用情况。这是持续时间的格式。例如，`1h25m3s` 代表 1 小时、25 分钟和 3 秒。它们也可以设置为 `never` 以避免在策略处于特定合规状态后评估策略。
`policyDefaults.evaluationInterval.compliant`	选填	指定合规策略的评估频率。如果要启用以前的轮询行为，请将此参数设置为 `10s`。
`policyDefaults.evaluationInterval.noncompliant`	选填	指定不合规策略的评估频率。如果要启用以前的轮询行为，请将此参数设置为 `10s`。
`policyDefaults.pruneObjectBehavior`	选填	决定在策略被删除时是否应删除由策略创建或修改的对象。只有在策略补救操作被设置为 `enforce` 时才会进行修剪。示例值为 `DeleteIfCreated`、`DeleteAll` 或 `None`。默认值为 `None`。
`policyDefaults.recreateOption`	选填	描述在需要更新时是否删除并重新创建对象。当您更新 immutable 字段时，`IfRequired` 值会重新创建对象。如果没有空运行更新支持，`IfRequired` 对集群没有影响。如果检测到不匹配，则 `Always` 值始终重新创建对象。当将 `remediationAction` 参数设置为 `inform` the `RecreateOption` 值没有作用。默认值为 `None`。
`policyDefaults.recordDiff`	选填	指定是否记录集群中对象与策略中的 `objectDefinition` 之间的区别。设置为 `Log` 以记录控制器日志或 `None` 的不同，而不是记录区别。默认情况下，此参数为空，不记录区别。
`policyDefaults.dependencies`	选填	应用此策略前必须处于特定合规性状态的对象列表。当 `policyDefaults.orderPolicies` 设置为 `true` 时，无法指定。
`policyDefaults.dependencies[].name`	必填	要依赖的对象名称。
`policyDefaults.dependencies[].namespace`	选填	要依赖的对象的命名空间。默认为 Policy Generator 设置的策略命名空间。
`policyDefaults.dependencies[].compliance`	选填	对象需要处于的合规性状态。默认值为 `Compliant`。
`policyDefaults.dependencies[].kind`	选填	对象的种类。默认情况下，kind 设置为 `Policy`，但也可以是具有合规状态的其他类型，如 `ConfigurationPolicy`。
`policyDefaults.dependencies[].apiVersion`	选填	对象的 API 版本。默认值为 `policy.open-cluster-management.io/v1`。
`policyDefaults.description`	选填	您要创建的策略的描述。
`policyDefaults.extraDependencies`	选填	应用此策略前必须处于特定合规性状态的对象列表。您定义的依赖项会独立于 `dependencies` 列表添加到每个策略模板中（如 `ConfigurationPolicy`）。当 `policyDefaults.orderManifests` 被设置为 `true` 时，无法指定。
`policyDefaults.extraDependencies[].name`	必填	要依赖的对象名称。
`policyDefaults.extraDependencies[].namespace`	选填	要依赖的对象的命名空间。默认情况下，值设为为 Policy Generator 设置的策略命名空间。
`policyDefaults.extraDependencies[].compliance`	选填	对象需要处于的合规性状态。默认值为 `Compliant`。
`policyDefaults.extraDependencies[].kind`	选填	对象的种类。默认值为 `Policy`，但也可以是具有合规状态的其他类型，如 `ConfigurationPolicy`。
`policyDefaults.extraDependencies[].apiVersion`	选填	对象的 API 版本。默认值为 `policy.open-cluster-management.io/v1`。
`policyDefaults.ignorePending`	选填	当 Policy Generator 等待其依赖项达到其所需状态时，绕过合规性状态检查。默认值为 `false`。
`policyDefaults.orderPolicies`	选填	自动生成有关策略的`依赖项`，以便它们按照您在策略列表中定义的顺序应用。默认情况下，值设为 `false`。无法与 `policyDefaults.dependencies` 同时指定。
`policyDefaults.orderManifests`	选填	在策略模板上自动生成 `extraDependencies`，以便它们按照您在该策略的清单列表中定义的顺序应用。当 `policyDefaults.consolidateManifests` 被设置为 `true` 时，无法指定。无法与 `policyDefaults.extraDependencies` 同时指定。
`policyDefaults.consolidateManifests`	选填	这决定了是否为策略中包含的所有清单生成单一配置策略。如果设置为 `false`，则为每个清单生成配置策略。默认值为 `true`。
`policyDefaults.informGatekeeperPolicies` （已弃用）	选填	将 `informGatekeeperPolicies` 设置为 false 以直接使用 Gatekeeper 清单，而无需在配置策略中定义。当策略引用违反 gatekeeper 策略清单时，这决定了是否应生成额外的配置策略以便在 Red Hat Advanced Cluster Management 中接收策略违反情况。默认值为 `true`。
`policyDefaults.informKyvernoPolicies`	选填	当策略引用 Kyverno 策略清单时，这决定了在 Kyverno 策略违反时，是否生成额外的配置策略来接收 Red Hat Advanced Cluster Management 中的策略违反情况。默认值为 `true`。
`policyDefaults.policyLabels`	选填	策略在其 `metadata.labels` 部分中包含的标签。`policyLabels` 参数适用于所有策略，除非在策略中指定。
`policyDefaults.gatekeeperEnforcementAction`	选填	覆盖 Gatekeeper 约束的 `spec.enforcementAction` 字段。这只适用于 Gatekeeper 约束，并被其他清单忽略。如果没有设置，`spec.enforcementAction` 字段不会改变。
`policyDefaults.policySets`	选填	策略加入的策略集合的数组。策略设置详情可在 `policySets` 部分中定义。当一个策略是策略集的一部分时，对这个策略的放置绑定没有保证，因为会为集合生成一个。设置 `policies[].generatePlacementWhenInSet` 或 `policyDefaults.generatePlacementWhenInSet` 来覆盖 `policyDefaults.policySets`。
`policyDefaults.generatePolicyPlacement`	选填	为策略生成放置清单。默认设置为 `true`。当设置为 `false` 时，会跳过放置清单生成，即使指定了放置也是如此。
`policyDefaults.generatePlacementWhenInSet`	选填	当一个策略是策略集的一部分时，默认情况下，生成器不会为这个策略生成放置，因为会为策略集生成一个。将 `generatePlacementWhenInSet` 设置为 `true`，以使用策略放置和策略设置放置部署策略。默认值为 `false`。
`policyDefaults.placement`	选填	策略的放置配置。这默认为与所有集群匹配的放置配置。
`policyDefaults.placement.name`	选填	指定一个名称来整合包含相同集群标签选择器的放置。
`policyDefaults.placement.labelSelector`	选填	使用 `key:value` 定义集群标签选择器，或使用适当的值提供 `matchExpressions`、`matchLabels` 或两者都指定放置。请参阅 `placementPath` 指定现有文件。
`policyDefaults.placement.placementName`	选填	定义此参数以使用集群中已存在的放置。没有创建 `Placement`，而是一个 `PlacementBinding` 将策略绑定到这个 `Placement`。
`policyDefaults.placement.placementPath`	选填	要重复使用现有放置，请指定相对于 `kustomization.yaml` 文件的位置的路径。如果提供，则默认所有策略都会使用此放置。请参阅 `labelSelector` 以生成新的 `Placement`。
`policyDefaults.placement.clusterSelector` (Deprecated)	选填	`PlacementRule` 已被弃用。使用 `labelSelector` 来生成放置。使用 `key:value` 或提供 `matchExpressions`、`matchLabels` 或使用适当的值来定义集群选择器来指定放置规则。请参阅 `placementRulePath` 以指定现有文件。
`policyDefaults.placement.placementRuleName` (Deprecated)	选填	`PlacementRule` 已被弃用。或者，使用 `placementName` 指定放置。要使用集群中的现有放置规则，请指定此参数的名称。`PlacementRule` 不会被创建，但 `PlacementBinding` 将策略绑定到现有的 `PlacementRule`。
`policyDefaults.placement.placementRulePath` (Deprecated)	选填	`PlacementRule` 已被弃用。或者，使用 `placementPath` 指定放置。要重复使用现有放置规则，请指定相对于 `kustomization.yaml` 文件的位置的路径。如果提供，则默认所有策略都使用此放置规则。请参阅 `clusterSelector` 以生成新的 `PlacementRule`。
`policySetDefaults`	选填	策略设置的默认值。为此参数列出的任何默认值都会被 `policySets` 数组中的条目覆盖。
`policySetDefaults.placement`	选填	策略的放置配置。这默认为与所有集群匹配的放置配置。有关此字段的描述，请参阅 `policyDefaults.placement`。
`policySetDefaults.generatePolicySetPlacement`	选填	为策略集合生成放置清单。默认设置为 `true`。当设置为 `false` 时，会跳过放置清单生成，即使指定了放置也是如此。
`policies`	必填	要创建的策略列表以及覆盖默认值或 `policyDefaults` 中设置的值。如需了解更多字段和描述，请参阅 `policyDefaults`。
`policies.description`	选填	您要创建的策略的描述。
`policies[].name`	必填	要创建的策略的名称。
`policies[].manifests`	必填	策略中包含的 Kubernetes 对象清单列表，以及覆盖默认值、此`策略`项中设置的值或 `policyDefaults` 中设置的值。如需了解更多字段和描述，请参阅 `policyDefaults`。当 `consolidateManifests` 设为 `true` 时，只有 `complianceType`、`metadataComplianceType` 和 `recordDiff` 可以在 `policies[].manifests` 级别被覆盖。
`policies[].manifests[].path`	必填	相对于 `kustomization.yaml` 文件，到单个文件的路径、平面文件目录或 Kustomize 目录。如果该目录是一个 Kustomize 目录，则生成器会在生成策略前针对目录运行 Kustomize。如果需要处理 Kustomize 目录的 Helm chart，请在运行策略生成器的环境中将 `POLICY_GEN_ENABLE_HELM` 设置为 `true`，以便为 Policy Generator 启用 Helm。支持以下清单：非根策略类型清单，如 `CertificatePolicy`、`ConfigurationPolicy`、`OperatorPolicy` 具有 `Policy` 后缀。除了补丁外，前面的清单不会被修改，并直接添加为 `Policy` 资源的 `policy-templates` 条目。如果 `informGatekeeperPolicies` 设为 `false`，则也会直接包含 gatekeeper 约束。仅包含 `object-templates-raw` 键的清单。对应的值直接在不修改的情况下在生成的 `ConfigurationPolicy` 资源中使用，它作为 `Policy` 条目的 `policy-templates` 条目添加。对于其他内容，会生成 `ConfigurationPolicy` 对象来包装前面提到的清单。生成的 `ConfigurationPolicy` 清单将添加为 `Policy` 资源的 `policy-templates` 条目。
`policies[].manifests[].name`	选填	当 `ConsolidateManifests` 设为 `false` 时，充当 `ConfigurationPolicy` 资源名称。如果路径中存在多个清单，则会附加一个索引号。如果提供了多个清单并且提供了它们的名称，并将 `consolidateManifests` 设置为 `true`，则第一个清单的名称将用于所有清单路径。
`policies[].manifests[].patches`	选填	应用到路径上清单的 Kustomize 补丁列表。如果有多个清单，补丁需要设置 `apiVersion`、`kind`、`metadata.name` 和 `metadata.namespace` （如果适用）字段，以便 Kustomize 可以识别补丁应用到的清单。如果只有一个清单，则可以修补 `metadata.name` 和 `metadata.namespace` 字段。
`policies.policyLabels`	选填	策略在其 `metadata.labels` 部分中包含的标签。`policyLabels` 参数适用于所有策略，除非在策略中指定。
`policySets`	选填	要创建的策略集合列表，以及覆盖默认值或 `policySetDefaults` 中设置的值。要在策略集中包含策略，请使用 `policyDefaults.policySets`, `policies[].policySets`, 或 `policySets.policies`。如需了解更多字段和描述，请参阅 `policySetDefaults`。
`policySets[].name`	必填	要创建的策略的名称。
`policySets[].description`	选填	要创建的策略集的描述。
`policySets[].policies`	选填	包括在策略集中的策略列表。如果还指定了 `policyDefaults.policySets` 或 `policies[].policySets`，则列表会被合并。

2.3.7.4. 其他资源

阅读生成策略来安装 GitOps Operator。
如需了解更多详细信息，请参阅策略设置控制器。
如需更多信息，请参阅应用 Kustomize。
如需了解更多主题，请参阅监管文档。
请参阅 kustomization.yaml 文件示例。
请参阅 Kubernetes 标签和选择器文档。
如需更多详细信息，请参阅 Gatekeeper。
请参阅 Kustomize 文档。

2.3.8. 生成安装 Compliance Operator 的策略

生成将 Compliance Operator 安装到集群中的策略。对于使用 namespaced 安装模式的 Operator，如 Compliance Operator，还需要 OperatorGroup 清单。

完成以下步骤：

创建一个 YAML 文件，其中包含 Namespace、Subscription 和名为 compliance-operator.yaml 的 OperatorGroup 清单。以下示例将这些清单安装到 compliance-operator 命名空间中：

apiVersion: v1
kind: Namespace
metadata:
  name: openshift-compliance
---
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: compliance-operator
  namespace: openshift-compliance
spec:
  targetNamespaces:
    - openshift-compliance
---
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: compliance-operator
  namespace: openshift-compliance
spec:
  channel: release-0.1
  name: compliance-operator
  source: redhat-operators
  sourceNamespace: openshift-marketplace

创建 PolicyGenerator 配置文件。查看以下 PolicyGenerator 策略示例，该示例在所有 OpenShift Container Platform 受管集群上安装 Compliance Operator：

apiVersion: policy.open-cluster-management.io/v1
kind: PolicyGenerator
metadata:
  name: install-compliance-operator
policyDefaults:
  namespace: policies
  placement:
    labelSelector:
      matchExpressions:
        - key: vendor
          operator: In
          values:
            - "OpenShift"
policies:
  - name: install-compliance-operator
    manifests:
      - path: compliance-operator.yaml

将策略生成器添加到 kustomization.yaml 文件中。generators 部分可能类似以下配置：

generators:
  - policy-generator-config.yaml

因此，生成的策略类似于以下文件：

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: Placement
metadata:
  name: placement-install-compliance-operator
  namespace: policies
spec:
  predicates:
  - requiredClusterSelector:
      labelSelector:
        matchExpressions:
        - key: vendor
          operator: In
          values:
          - OpenShift
---
apiVersion: policy.open-cluster-management.io/v1
kind: PlacementBinding
metadata:
  name: binding-install-compliance-operator
  namespace: policies
placementRef:
  apiGroup: cluster.open-cluster-management.io
  kind: Placement
  name: placement-install-compliance-operator
subjects:
  - apiGroup: policy.open-cluster-management.io
    kind: Policy
    name: install-compliance-operator
---
apiVersion: policy.open-cluster-management.io/v1
kind: Policy
metadata:
  annotations:
    policy.open-cluster-management.io/categories: CM Configuration Management
    policy.open-cluster-management.io/controls: CM-2 Baseline Configuration
    policy.open-cluster-management.io/standards: NIST SP 800-53
    policy.open-cluster-management.io/description:
  name: install-compliance-operator
  namespace: policies
spec:
  disabled: false
  policy-templates:
    - objectDefinition:
        apiVersion: policy.open-cluster-management.io/v1
        kind: ConfigurationPolicy
        metadata:
          name: install-compliance-operator
        spec:
          object-templates:
            - complianceType: musthave
              objectDefinition:
                apiVersion: v1
                kind: Namespace
                metadata:
                  name: openshift-compliance
            - complianceType: musthave
              objectDefinition:
                apiVersion: operators.coreos.com/v1alpha1
                kind: Subscription
                metadata:
                  name: compliance-operator
                  namespace: openshift-compliance
                spec:
                  channel: release-0.1
                  name: compliance-operator
                  source: redhat-operators
                  sourceNamespace: openshift-marketplace
            - complianceType: musthave
              objectDefinition:
                apiVersion: operators.coreos.com/v1
                kind: OperatorGroup
                metadata:
                  name: compliance-operator
                  namespace: openshift-compliance
                spec:
                  targetNamespaces:
                    - compliance-operator
          remediationAction: enforce
          severity: low

因此，会显示生成的策略。

2.3.9. 监管策略框架架构

使用 Red Hat Advanced Cluster Management for Kubernetes 监管声明周期来增强集群的安全性。产品监管生命周期基于使用支持的策略、流程和程序来管理中央接口页面中的安全性和合规性。参阅以下监管架构图：

Governance architecture diagram

查看监管架构图的以下组件描述：

监管策略框架： 前面的镜像表示作为受管集群上的 governance-policy-framework pod 运行并包含以下控制器的框架：
- spec sync controller： 将 hub 集群上的受管集群命名空间中的复制策略同步到受管集群上的受管集群命名空间。
- 状态同步控制器： 在 hub 和受管集群的复制策略中记录来自策略控制器的合规性事件。状态仅包含与当前策略相关的更新，如果策略被删除并重新创建，则不会考虑过去的状态。
- 模板同步控制器： 根据复制策略 spec.policy-templates 条目的定义，在受管集群中创建、更新和删除受管集群命名空间中的对象。
- Gatekeeper 同步控制器： 在对应的 Red Hat Advanced Cluster Management 策略中记录 Gatekeeper 约束审计结果作为合规事件。
策略传播器控制器： 在 Red Hat Advanced Cluster Management hub 集群上运行，并根据绑定到 root 策略的放置在 hub 上的受管集群命名空间中生成复制策略。它还将合规状态从复制策略聚合到根策略状态，并根据绑定到 root 策略的策略自动化启动自动化。
监管策略附加控制器： 在 Red Hat Advanced Cluster Management hub 集群上运行，并管理受管集群中策略控制器的安装。

2.3.9.1. 监管架构组件

监管架构还包括以下组件：

监管仪表板：提供云监管和风险详情的概述信息，其中包括策略和集群违反情况。请参阅 Manage Governance dashboard 部分，以了解 Red Hat Advanced Cluster Management for Kubernetes 策略的结构，以及如何使用 Red Hat Advanced Cluster Management for Kubernetes 监管仪表板。
备注：
- 当策略传播到受管集群时，首先会复制到 hub 集群上的集群命名空间中，并使用 namespaceName.policyName 命名并标记。在创建策略时，请确保 namespaceName.policyName 的长度不超过 63 个字符，因为 Kubernetes 对标签值有限制。
- 当您在 hub 集群中搜索策略时，您可能还会在受管集群命名空间中收到复制策略的名称。例如，如果您在 default 命名空间中搜索 policy-dhaz-cert，hub 集群中的以下策略名称可能也会出现在受管集群命名空间中： default.policy-dhaz-cert。
基于策略的监管框架： 支持根据与集群关联的属性（如一个地区）支持策略创建和部署到各种受管集群。以下是在开源社区中向集群部署策略的预定义策略和说明的示例。另外，当出现违反策略的情况时，可以将自动化配置为运行并采取用户选择的任何操作。
开源社区：在 Red Hat Advanced Cluster Management 策略框架的基础上支持社区贡献。策略控制器和第三方策略也是 open-cluster-management/policy-collection 存储库的一部分。您可以使用 GitOps 贡献和部署策略。

2.3.9.2. 其他资源

2.3.10. 监管仪表板

使用监管( Governance )仪表板创建、查看和编辑您的资源，来管理您的安全策略和策略违反情况。您可以使用命令行和控制台为您的策略创建 YAML 文件。从控制台继续读取监管仪表板的详情。

2.3.10.1. 监管页面

Governance 页中显示以下标签页，Policy set, 和 Policies。阅读以下描述以了解显示哪些信息：

概述
在 Overview 选项卡中显示以下摘要卡： Policy set violations,Policy violations,Clusters,Categories, Controls, 和 Standards。
策略集合
创建和管理 hub 集群策略集。
策略（policy）
- 创建和管理安全策略。策略列表列出了以下策略详情： Name、Namespace 和 Cluster violations。
- 您可以编辑、启用或禁用，将补救设置为 inform 或 enforce，或通过选择 Actions 图标来删除策略。您可以通过选择要展开行的下拉箭头来查看特定策略的类别和标准。
- 在 Manage 列对话框中重新排序您的表列。选中要显示的对话框的 Manage 列 图标。要重新排序您的列，请选择 Reorder 图标并移动列名称。对于您想要显示在表中列，点击特定列名称的复选框，然后选择 Save 按钮。
- 选择多个策略并点击 Actions 按钮来完成批量操作。您还可以点 Filter 按钮自定义您的策略表。
  当您在表列表中选择一个策略时，控制台中会显示以下信息标签页：
  - Details ：选择 Details 选项卡来查看策略详情和放置详情。在 Placement 表中，Compliance 列提供了查看所显示集群的合规性的链接。
  - Results ：选择 Results 选项卡来查看与放置关联的所有集群的表列表。
从 Message 列中，点 View details 链接来查看模板详情、模板 YAML 和相关资源。您还可以查看相关的资源。点 View history 链接查看违反消息以及最后一次报告的时间。

2.3.10.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.3.10.3. 其他资源

查看以下主题以了解更多有关创建和更新您的安全策略的信息。

2.3.11. 创建配置策略

您可以使用命令行界面 (CLI) 或者从控制台为配置策略创建 YAML 文件。从控制台创建配置策略时，YAML 编辑器会显示 YAML 文件。

2.3.11.1. 先决条件

需要的访问权限 ：管理员或集群管理员
如果您有一个现有的 Kubernetes 清单，请考虑使用 Policy Generator 在策略中自动包含清单。请参阅策略生成器文档。

2.3.11.2. 通过 CLI 创建配置策略

完成以下步骤，通过 CLI 创建配置策略：

为您的配置策略创建一个 YAML 文件。运行以下命令:

oc create -f configpolicy-1.yaml

您的配置策略可能类似以下策略：

apiVersion: policy.open-cluster-management.io/v1
kind: Policy
metadata:
  name: policy-1
  namespace: my-policies
policy-templates:
- apiVersion: policy.open-cluster-management.io/v1
  kind: ConfigurationPolicy
  metadata:
    name: mustonlyhave-configuration
  spec:
    namespaceSelector:
      include: ["default"]
      exclude: ["kube-system"]
    remediationAction: inform
    disabled: false
    complianceType: mustonlyhave
    object-templates:

运行以下命令来应用策略：

oc apply -f <policy-file-name>  --namespace=<namespace>

运行以下命令，验证并列出策略：

oc get policies.policy.open-cluster-management.io --namespace=<namespace>

您的配置策略已创建。

2.3.11.2.1. 通过 CLI 查看您的配置策略

完成以下步骤，通过 CLI 查看您的配置策略：

运行以下命令，查看具体配置策略的详情：

oc get policies.policy.open-cluster-management.io <policy-name> -n <namespace> -o yaml

运行以下命令，查看您的配置策略的描述：

oc describe policies.policy.open-cluster-management.io <name> -n <namespace>

2.3.11.2.2. 从控制台查看您的配置策略

在控制台中查看任何配置策略及其状态。

从控制台登录到集群后，选择 Governance 来查看您的策略的表列表。注：您可以选择 All policies 选项卡或者 Cluster violations 选项卡来过滤您的策略表列表。

选择一个策略来查看更多详情。此时会显示 Details、Clusters 和 Templates 标签页。

2.3.11.3. 禁用配置策略

要禁用您的配置策略，请从策略的 Actions 菜单中选择 Disable policy。策略被禁用，但不被删除。

2.3.11.4. 删除配置策略

通过 CLI 或控制台删除配置策略。完成以下步骤：

要从目标集群或集群中删除策略，请运行以下命令：

oc delete policies.policy.open-cluster-management.io <policy-name> -n <namespace>

运行以下命令验证您的策略是否已移除：

oc get policies.policy.open-cluster-management.io <policy-name> -n <namespace>

要从控制台删除配置策略，点您要在策略违反表中删除的策略的 Actions 图标，然后点 Delete。

您的策略已删除。

2.3.11.5. 其他资源

如需被 Red Hat Advanced Cluster Management 支持的配置策略示例，查看 CM-Configuration-Management 文件夹。
或者，请参阅示例配置策略表，以查看控制器监控的其他配置策略。

2.3.12. 为监管配置 Ansible Automation Platform

Red Hat Advanced Cluster Management for Kubernetes 监管可与 Red Hat Ansible Automation Platform 集成，以创建策略违反自动化。您可以从 Red Hat Advanced Cluster Management 控制台配置自动化。

2.3.12.1. 先决条件

支持的 OpenShift Container Platform 版本
已安装 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.3.12.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.3.12.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 超过定义的时间值时，策略不合规，且自动化会针对每个策略违反。