安全性

Red Hat Advanced Cluster Management for Kubernetes 2.1

安全性

摘要

Red Hat Advanced Cluster Management for Kubernetes 中的安全性和监管

第 1 章 安全性

管理 Red Hat Advanced Cluster Management for Kubernetes 的安全性和基于角色的访问控制 (RBAC)。使用定义的策略和流程监管集群,以识别并最大程度降低风险。使用策略来定义规则和设置控制。

先决条件 :您必须配置 Red Hat Advanced Cluster Management for Kubernetes 的身份验证服务要求,以便将工作负载加载到 Identity and Access Management(IAM)。如需更多信息,请参阅 OpenShift Container Platform 文档 中的了解身份验证

查看以下主题以了解有关保护集群的更多信息:

1.1. 基于角色的访问控制

Red Hat Advanced Cluster Management for Kubernetes 支持的基于角色的控制访问(RBAC)。您的角色决定了您可以执行的操作。RBAC 基于 Kubernetes 中的授权机制,类似于 Red Hat OpenShift Container Platform。有关 RBAC 的更多信息,请参阅 OpenShift Container Platform 文档中的 RBAC 概述。

:如果用户角色无法访问,则控制台中禁用操作按钮。

如需组件支持的 RBAC 的详细信息,参阅以下小节。

1.1.1. 角色概述

有些产品资源是基于集群范围的,有些则是命名空间范围。您必须将集群 rolebindings 和命名空间 rolebindings 应用到用户,以使访问控制具有一致性。查看 Red Hat Advanced Cluster Management for Kubernetes 支持的以下角色定义表列表:

表 1.1. 角色定义表

角色定义

cluster-admin

具有集群范围内的绑定到 cluster-admin 角色的用户,是一个 OpenShift Container Platform 超级用户,其具有所有访问权限。

open-cluster-management:cluster-manager-admin

具有集群范围绑定到 cluster-manager-admin 角色的用户,是一个 Red Hat Advanced Cluster Management for Kubernetes 超级用户,其具有所有访问权限。

open-cluster-management:managed-cluster-x (admin)

具有集群范围绑定到 managed-cluster-x 角色的用户,具有对受管集群 "X" 资源的管理员访问权限。

open-cluster-management:managed-cluster-x (viewer)

具有集群范围绑定到 managed-cluster-x 角色的用户,具有对 managedcluster “X” 资源的查看(view)权限。

open-cluster-management:subscription-admin

具有 subscription-admin 角色的用户,可以创建 Git 订阅来将资源部署到多个命名空间中。资源在订阅的 Git 仓库中的 Kubernetes 资源 YAML 文件中指定。:当一个非 subscription-admin 用户创建订阅时,无论资源中的指定命名空间是什么,所有资源都会部署到订阅命名空间中。如需更多信息,请参阅应用程序生命周期 RBAC 部分。

admin, edit, view

admin、edit 和 view 是 OpenShift Container Platform 的默认角色。具有命名空间范围绑定的用户可以访问特定命名空间中的 open-cluster-management 资源,而集群范围的绑定到同一角色可以访问整个集群范围的 open-cluster-management 资源。

重要

  • 任何用户都可以从 OpenShift Container Platform 创建项目,这为命名空间授予管理员角色权限。
  • 如果用户无法访问集群的角色,则无法看到集群名称。集群名称显示有以下符号: -

1.1.2. RBAC 的实施

RBAC 在控制台和 API 一级进行验证。控制台中的操作可根据用户访问角色权限启用或禁用。查看以下章节以了解有关该产品中特定生命周期的 RBAC 的更多信息。

1.1.2.1. 集群生命周期 RBAC

查看以下集群生命周期 RBAC 操作。

创建和管理所有受管集群:

  • 输入以下命令,创建到集群角色 open-cluster-management:cluster-manager-admin 的集群角色绑定:

    oc create clusterrolebinding <role-binding-name> --clusterrole=open-cluster-management:cluster-manager-admin

    这个角色是一个超级用户,可访问所有资源和操作。此角色允许您创建集群范围的 managedcluster 资源、用于管理受管集群的资源的命名空间,以及命名空间中的资源。此角色还支持访问供应商连接以及用于创建受管集群的裸机资产。

管理名为 cluster-name 的受管集群:

  • 输入以下命令,创建到集群角色 open-cluster-management:admin:<cluster-name> 的集群角色绑定:

    oc create clusterrolebinding (role-binding-name) --clusterrole=open-cluster-management:admin:<cluster-name>

    此角色允许对集群范围的 managedcluster 资源进行读写访问。这是必要的,因为 managedcluster 是一个集群范围的资源,而不是命名空间范围的资源。

  • 输入以下命令,创建到集群角色 admin 的命名空间角色绑定:

    oc create rolebinding <role-binding-name> -n <cluster-name> --clusterrole=admin

    此角色允许对受管集群命名空间中的资源进行读写访问。

查看名为 cluster-name 的受管集群:

  • 输入以下命令,创建到集群角色 open-cluster-management:view:<cluster-name> 的集群角色绑定:

    oc create clusterrolebinding <role-binding-name> --clusterrole=open-cluster-management:view:<cluster-name>

    此角色允许对集群范围的 managedcluster 资源的读取访问权限。这是必要的,因为 managedcluster 是一个集群范围的资源,而不是命名空间范围的资源。

  • 输入以下命令,创建到集群角色 view 的命名空间角色绑定:

    oc create rolebinding <role-binding-name> -n <cluster-name> --clusterrole=view

    此角色允许只读访问受管集群命名空间中的资源。

请参阅 ManagedClusterSets 以了解有关管理 ManagedClusterSet 资源的信息。

查看以下集群生命周期控制台和 API RBAC 表:

表 1.2. 集群生命周期的控制台 RBAC 表

操作AdminEditView

Clusters

read、update、delete

读取、更新

读取

AWS 供应商连接。

create、read、update 和 delete

create、read、update 和 delete

读取

裸机资产

创建、读取、更新、删除

读取、更新

读取

表 1.3. 集群生命周期的 API RBAC 表

APIAdminEditView

manageclusters.cluster.open-cluster-management.io

创建、读取、更新、删除

读取、更新

读取

baremetalassets.inventory.open-cluster-management.io

创建、读取、更新、删除

读取、更新

读取

klusterletaddonconfigs.agent.open-cluster-management.io

创建、读取、更新、删除

读取、更新

读取

managedclusteractions.action.open-cluster-management.io

创建、读取、更新、删除

读取、更新

读取

managedclusterviews.view.open-cluster-management.io

创建、读取、更新、删除

读取、更新

读取

managedclusterinfos.internal.open-cluster-management.io

创建、读取、更新、删除

读取、更新

读取

manifestworks.work.open-cluster-management.io

创建、读取、更新、删除

读取、更新

读取

1.1.2.2. 应用程序生命周期 RBAC

在创建一个应用程序时,subscription 命名空间会被创建,配置映射会在 subscription 命名空间中创建。如果需要应用订阅,则必须是订阅管理员。有关管理应用程序的更多信息,请参阅创建和管理订阅

要执行应用程序生命周期任务,具有 admin 角色的用户必须有权访问创建的应用程序所在的命名空间,以及 managedcluster 命名空间。例如,在命名空间 "N" 中创建应用程序所需的访问权限是命名空间范围的绑定到命名空间 "N" 的 admin 角色。

查看以下应用程序生命周期控制台和 API RBAC 表:

表 1.4. 应用程序生命周期的控制台 RBAC 表

操作AdminEditView

Application

创建、读取、更新、删除

创建、读取、更新、删除

读取

Channel

创建、读取、更新、删除

创建、读取、更新、删除

读取

Subscription

创建、读取、更新、删除

创建、读取、更新、删除

读取

放置规则(Placement rule)

创建、读取、更新、删除

创建、读取、更新、删除

读取

表 1.5. 应用程序生命周期的 API RBAC 表

APIAdminEditView

applications.app.k8s.io

创建、读取、更新、删除

创建、读取、更新、删除

读取

channels.apps.open-cluster-management.io

创建、读取、更新、删除

创建、读取、更新、删除

读取

deployables.apps.open-cluster-management.io

创建、读取、更新、删除

创建、读取、更新、删除

读取

helmreleases.apps.open-cluster-management.io

创建、读取、更新、删除

创建、读取、更新、删除

读取

placementrules.apps.open-cluster-management.io

创建、读取、更新、删除

创建、读取、更新、删除

读取

subscriptions.apps.open-cluster-management.io

创建、读取、更新、删除

创建、读取、更新、删除

读取

configmaps

创建、读取、更新、删除

创建、读取、更新、删除

读取

secrets

创建、读取、更新、删除

创建、读取、更新、删除

读取

命名空间

创建、读取、更新、删除

创建、读取、更新、删除

读取

1.1.2.3. 监管生命周期 RBAC

要执行监管生命周期操作,用户必须有权访问创建策略的命名空间,以及访问应用策略的 managedcluster 命名空间。

请参见以下示例:

  • 要查看命名空间 "N" 中的策略,需要以下角色:

    • 命名空间范围的绑定到命名空间 "N" 的 view 角色。
  • 要在命名空间 "N" 中创建策略,并将其应用到 managedcluster "X",需要以下角色:

    • 命名空间范围的绑定到命名空间 "N" 的 admin 角色。
    • 命名空间范围的绑定到命名空间 "X" 的 admin 角色。

查看以下监管生命周期控制台和 API RBAC 表:

表 1.6. 监管生命周期的控制台 RBAC 表

操作AdminEditView

策略(policy)

创建、读取、更新、删除

读取、更新

读取

PlacementBindings

创建、读取、更新、删除

读取、更新

读取

PlacementRules

创建、读取、更新、删除

读取、更新

读取

表 1.7. 用于监管生命周期的 API RBAC 表

APIAdminEditView

policies.policy.open-cluster-management.io

创建、读取、更新、删除

读取、更新

读取

placementbindings.policy.open-cluster-management.io

创建、读取、更新、删除

读取、更新

读取

1.1.2.4. Observability RBAC

要使用可观察功能,您必须分配 cluster-adminopen-cluster-management:cluster-manager-admin 角色。查看以下可观察功能列表:

  • 访问受管集群指标。
  • 搜索资源。
  • 如果您有权限可以访问受管集群,请使用 Visual Web Terminal。

创建、更新和删除 MultiClusterObservability 自定义资源。查看以下 RBAC 表:

表 1.8. 用于 observability 的 API RBAC 表

API

Admin

Edit

View

multiclusterobservabilities.observability.open-cluster-management.io

create、read、update 和 delete

-

-

如需了解更多与集群安全相关的信息,请参阅安全部分。

1.2. 证书

在整个 Red Hat Advanced Cluster Management for Kubernetes 范围内会创建和使用各种证书。

您可以自带证书。为您的证书创建 Kubernetes TLS Secret。创建证书后,您可以替换由 Red Hat Advanced Cluster Management 安装程序创建的某些证书。

需要的访问权限 :集群管理员或团队管理员.

备注:只有在 Red Hat Advanced Cluster Management 原生安装中才支持替换证书。

在 Red Hat Advanced Cluster Management 中运行的服务所需的所有证书都是在 Red Hat Advanced Cluster Management 安装过程中创建的。证书由 Red Hat Advanced Cluster Management 证书管理器(cert-manager)服务创建和管理。Red Hat Advanced Cluster Management Root 证书颁发机构(CA)证书存储在 hub 集群命名空间中的 Kubernetes Secret multicloud-ca-cert 中。证书可导入到您的客户端信任存储中,用于访问 Red Hat Advanced Cluster Management Platform API。

请参阅以下主题来替换证书:

1.2.1. 列出证书

您可以通过运行以下命令,查看内部使用 cert-manager 的证书列表:

oc get certificates.certmanager.k8s.io -n open-cluster-management

:如果启用了可观察性,则还需要额外命名空间来创建证书。

1.2.2. 刷新证书

您可以在 第 1.2.1 节 “列出证书” 部分运行命令来刷新证书。当您标识需要刷新的证书时,删除与该证书关联的 secret。例如,您可以运行以下命令删除 secret:

oc delete secret grc-0c925-grc-secrets -n open-cluster-management

1.2.3. 为 Red Hat Advanced Cluster Management for Kubernetes 刷新证书

您可以刷新 Red Hat Advanced Cluster Management CA 发布的所有证书。在刷新过程中,删除了与每个 cert-manager 证书关联的 Kubernetes secret。该服务会自动重启来使用证书。运行以下命令:

oc delete secret -n open-cluster-management $(oc get certificates.certmanager.k8s.io -n open-cluster-management -o wide | grep multicloud-ca-issuer | awk '{print $3}')

Red Hat OpenShift Container Platform 证书没有包括在 Red Hat Advanced Cluster Management for Kubernetes 管理入口中。如需更多信息,请参阅已知安全问题。在受管集群中使用证书策略控制器来创建和管理证书策略。请参阅策略控制器以了解更多有关控制器的信息。返回到 Security 页面以了解更多信息。

1.2.4. 替换 root CA 证书

您可以替换 root CA 证书。

1.2.4.1. Root CA 证书的先决条件

确认您的 Red Hat Advanced Cluster Management for Kubernetes 集群正在运行。

运行以下命令,备份现有 Red Hat Advanced Cluster Management for Kubernetes 证书资源:

oc get cert multicloud-ca-cert -n open-cluster-management -o yaml > multicloud-ca-cert-backup.yaml

1.2.4.2. 使用 OpenSSL 创建 root CA 证书

完成以下步骤,使用 OpenSSL 创建 root CA 证书:

  1. 运行以下命令生成您的证书颁发机构 (CA) RSA 私钥:

    openssl genrsa -out ca.key 4096
  2. 使用您的 CA 密钥生成自签名 CA 证书。运行以下命令:

    openssl req -x509 -new -nodes -key ca.key -days 400 -out ca.crt -config req.cnf

    您的 req.cnf 文件可能类似以下文件:

    [ req ]               # Main settings
    default_bits = 4096       # Default key size in bits.
    prompt = no               # Disables prompting for certificate values so the configuration file values are used.
    default_md = sha256       # Specifies the digest algorithm.
    distinguished_name = dn   # Specifies the section that includes the distinguished name information.
    x509_extensions = v3_ca   # The extentions to add to the self signed cert
    
    [ dn ]               # Distinguished name settings
    C = US                    # Country
    ST = North Carolina             # State or province
    L = Raleigh                # Locality
    O = Red Hat Open Shift     # Organization
    OU = Red Hat Advanced Container Management        # Organizational unit
    CN = www.redhat.com  # Common name.
    
    [ v3_ca ]          # x509v3 extensions
    basicConstraints=critical,CA:TRUE # Indicates whether the certificate is a CA certificate during the certificate chain verification process.

1.2.4.3. 替换 root CA 证书

  1. 运行以下命令,使用 CA 证书创建新 secret:

    kubectl -n open-cluster-management create secret tls byo-ca-cert --cert ./ca.crt --key ./ca.key
  2. 编辑 CA 签发者以指向 BYO 证书。运行以下命令:

    oc edit issuer -n open-cluster-management multicloud-ca-issuer
  3. 将字符串 mulicloud-ca-cert 替换为 byo-ca-cert。保存部署并退出编辑器。
  4. 编辑管理 ingress 部署来引用 Bring Your Own(BYO)CA 证书。运行以下命令:

    oc edit deployment management-ingress-435ab
  5. multicloud-ca-cert 字符串替换为 byo-ca-cert。保存部署并退出编辑器。
  6. 登录到控制台并查看所使用的证书的详情,以此来验证自定义 CA 是否正在使用。

1.2.4.4. 刷新 cert-manager 证书

替换了 root CA 后,必须刷新所有由 root CA 签名的证书,且必须重启使用这些证书的服务。Cert-manager 从 root CA 创建默认签发者,因此由 cert-manager 签发以及由默认 ClusterIssuer 签名的所有证书都必须刷新。

删除与每个 cert-manager 证书关联的 Kubernetes secret,以刷新证书并重启使用该证书的服务。运行以下命令:

oc delete secret -n open-cluster-management $(oc get cert -n open-cluster-management -o wide | grep multicloud-ca-issuer | awk '{print $3}')

1.2.4.5. 恢复 root CA 证书

要恢复 root CA 证书,请完成以下步骤来更新 CA 签发者:

  1. 编辑 CA 签发者。运行以下命令:

    oc edit issuer -n open-cluster-management multicloud-ca-issuer
  2. 将编辑器中的 byo-ca-cert 字符串替换为 multicloud-ca-cert。保存签发者并退出编辑器。
  3. 编辑管理 ingress 部署来引用原始的 CA 证书。运行以下命令:

    oc edit deployment management-ingress-435ab
  4. byo-ca-cert 字符串替换为 multicloud-ca-cert 字符串 。保存部署并退出编辑器。
  5. 删除 BYO CA 证书。运行以下命令:

    oc delete secret -n open-cluster-management byo-ca-cert

刷新所有使用该 CA 的 cert-manager 证书。如需更多信息,请参阅前述部分“刷新 cert-manager 证书”。

有关由 Red Hat Advanced Cluster Management for Kubernates 创建和管理的证书的更多信息,请参阅证书

1.2.5. 替换管理入口证书

您可以替换管理入口证书。如果替换了 OpenShift Container Platform 的默认入口证书,您需要修改管理入口。如需更多信息,请参阅安全性已知问题中的登录到控制台时的 500 个内部错误

1.2.5.1. 替换管理入口证书的先决条件

将您的 management-ingress 证书和私钥准备妥当。如果需要,您可以使用 OpenSSL 生成 TLS 证书。将证书上的通用名称参数 CN 设置为 manangement-ingress。如果您要生成证书,请加入以下设置:

  • 在您的证书主题备用名称 (SAN) 列表中包括以下 IP 地址和域名:

    • 管理入口的服务名称:management-ingress
    • 包括 Red Hat Advanced Cluster Management for Kubernetes 的路由名称。运行以下命令接收路由名称:

      oc get route -n open-cluster-management

      您可以接收以下响应:

      multicloud-console.apps.grchub2.dev08.red-chesterfield.com
    • 添加 localhost IP 地址:127.0.0.1.
    • 添加 localhost 条目:localhost
1.2.5.1.1. 用于生成证书的示例配置文件

以下示例配置文件和 OpenSSL 命令提供了有关如何使用 OpenSSL 生成 TLS 证书的示例。查看以下 csr.cnf 配置文件,该文件定义了用来使用 OpenSSL 生成证书的配置设置。

[ req ]               # Main settings
default_bits = 2048       # Default key size in bits.
prompt = no               # Disables prompting for certificate values so the configuration file values are used.
default_md = sha256       # Specifies the digest algorithm.
req_extensions = req_ext  # Specifies the configuration file section that includes any extensions.
distinguished_name = dn   # Specifies the section that includes the distinguished name information.

[ dn ]               # Distinguished name settings
C = US                    # Country
ST = North Carolina             # State or province
L = Raleigh                # Locality
O = Red Hat Open Shift     # Organization
OU = Red Hat Advanced Container Management        # Organizational unit
CN = management-ingress  # Common name.

[ req_ext ]          # Extensions
subjectAltName = @alt_names # Subject alternative names

[ alt_names ]        # Subject alternative names
DNS.1 = management-ingress
DNS.2 = multicloud-console.apps.grchub2.dev08.red-chesterfield.com
DNS.3 = localhost
DNS.4 = 127.0.0.1

[ v3_ext ]          # x509v3 extensions
authorityKeyIdentifier=keyid,issuer:always  # Specifies the public key that corresponds to the private key that is used to sign a certificate.
basicConstraints=CA:FALSE                   # Indicates whether the certificate is a CA certificate during the certificate chain verification process.
#keyUsage=keyEncipherment,dataEncipherment   # Defines the purpose of the key that is contained in the certificate.
extendedKeyUsage=serverAuth                 # Defines the purposes for which the public key can be used.
subjectAltName=@alt_names                   # Identifies the subject alternative names for the identify that is bound to the public key by the CA.

备注:请务必使用您的管理入口的正确主机名更新标记的 SAN,即 DNS.2

1.2.5.1.2. 用于生成证书的 OpenSSL 命令

以下 OpenSSL 命令与上述配置文件一同用来生成所需的 TLS 证书。

  1. 生成您的证书颁发机构 (CA) RSA 私钥:

    openssl genrsa -out ca.key 4096
  2. 使用您的 CA 密钥生成自签名 CA 证书:

    openssl req -x509 -new -nodes -key ca.key -subj "/C=US/ST=North Carolina/L=Raleigh/O=Red Hat OpenShift" -days 400 -out ca.crt
  3. 为您的证书生成 RSA 私钥:

    openssl genrsa -out ingress.key 4096
  4. 使用私钥生成证书签名请求 (CSR):

    openssl req -new -key ingress.key -out ingress.csr -config csr.cnf
  5. 使用您的 CA 证书和密钥及 CSR 生成签名证书:

    openssl x509 -req -in ingress.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out ingress.crt -sha256 -days 300 -extensions v3_ext -extfile csr.cnf
  6. 检查证书内容:

    openssl x509  -noout -text -in ./ingress.crt

1.2.5.2. 替换自带 (BYO) 入口证书

完成以下步骤以替换您的 BYO 入口证书:

  1. 使用您的证书和私钥创建 byo-ingress-tls secret。运行以下命令:

    kubectl -n open-cluster-management create secret tls byo-ingress-tls-secret --cert ./ingress.crt --key ./ingress.key
  2. 验证是否在正确的命名空间中创建了 secret。

    kubectl get secret -n open-cluster-management | grep byo-ingress | grep tls
  3. 运行以下命令,创建包含 CA 证书的 secret:

    kubectl -n open-cluster-management create secret tls byo-ca-cert --cert ./ca.crt --key ./ca.key
  4. 编辑管理入口部署。获取部署的名称。运行以下命令:

    export MANAGEMENT_INGRESS=`oc get deployment -o custom-columns=:.metadata.name | grep management-ingress`
    
    oc edit deployment $MANAGEMENT_INGRESS -n open-cluster-management
    • multicloud-ca-cert 字符串替换为 byo-ca-cert
    • $MANAGEMENT_INGRESS-tls-secret 字符串替换为 byo-ingress-tls-secret
    • 保存部署并关闭编辑器。管理入口自动重启。
  5. 在管理入口 Pod 重启后,从浏览器导航到 Red Hat Advanced Cluster Management for Kubernetes 控制台。验证当前证书是您的证书,并且所有控制台访问和登录功能保持不变。

1.2.5.3. 恢复管理入口的默认自签名证书

  1. 编辑管理入口部署。将字符串 multicloud-ca-cert 替换为 byo-ca-cert。获取部署的名称。运行以下命令:

    export MANAGEMENT_INGRESS=`oc get deployment -o custom-columns=:.metadata.name | grep management-ingress`
    
    oc edit deployment $MANAGEMENT_INGRESS -n open-cluster-management
    1. byo-ca-cert 字符串替换为 multicloud-ca-cert
    2. byo -ingress-tls-secret 字符串替换为 $MANAGEMENT_INGRESS-tls-secret
    3. 保存部署并关闭编辑器。管理入口自动重启。
  2. 在所有 Pod 重启后,从浏览器导航到 Red Hat Advanced Cluster Management for Kubernetes 控制台。验证当前证书是您的证书,并且所有控制台访问和登录功能保持不变。
  3. 运行以下命令,删除自带 (BYO) 入口 secret 和入口 CA 证书:

    oc delete secret -n open-cluster-management byo-ingress-tls-secret
    oc delete secret -n open-cluster-management byo-ca-cert

有关由 Red Hat Advanced Cluster Management for Kubernates 创建和管理的证书的更多信息,请参阅证书。返回 Security 以了解更多有关保护集群的信息。

第 2 章 监管和风险

对于在私有云、多云和混合云环境中部署的工作负载,企业必须满足内部对软件工程、安全工程、弹性、安全性以及规范标准的要求。Red Hat Advanced Cluster Management for Kubernetes 监管功能为企业引进自己的安全策略提供了一个可扩展的策略框架。

2.1. 监管架构

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

Governance architecture diagram

监管架构由以下组件组成:

  • 监管和风险仪表板 :提供云监管和风险详情概述,其中包括策略和集群违反情况。

    备注:

    • 当策略传播到受管集群时,复制策略会命名为 namespaceName.policyName。因为 Kubernetes 项名称的限制,在创建策略时确保 namespaceName.policyName 的长度小于 63 个字符。
    • 当您在 hub 集群中搜索策略时,您可能还会在受管集群上收到复制策略的名称。例如,如果搜索 policy-dhaz-cert,则可能出现来自 hub 集群中的以下策略名称:default.policy-dhaz-cert
  • 基于策略的监管框架:支持基于与集群关联的属性(如地理区域)创建和部署到各种受管集群。请参阅 policy-collection 存储库,以查看预定义的策略示例,以及向集群部署策略的说明。您还可以贡献自定义策略控制器和策略。
  • 策略控制器 :根据您指定的控制在受管集群中评估一个或多个策略,并为违反行为生成 Kubernetes 事件。违反行为会被传播到 hub 集群中。安装中包含的策略控制器如下:Kubernetes 配置、证书和 IAM.您还可以创建自定义策略控制器。
  • 开源社区 :在 Red Hat Advanced Cluster Management 策略框架的基础上支持社区贡献。策略控制器和第三方策略也是 open-cluster-management/policy-collection 存储库的一部分。了解如何将第三方策略与 Red Hat Advanced Cluster Management for Kubernetes 集成。如需更多信息,请参阅 集成第三方策略控制器

了解 Red Hat Advanced Cluster Management for Kubernetes 策略的结构,以及如何使用 Red Hat Advanced Cluster Management for Kubernetes 监管和风险仪表板。

2.2. 策略概述

使用 Red Hat Advanced Cluster Management for Kubernetes 安全策略框架,以创建自定义策略控制器和其他策略。Kubernetes CustomResourceDefinition (CRD) 实例用于创建策略。有关 CRD 的更多信息,请参阅使用 CustomResourceDefinitions 扩展 Kubernetes API

每个 Red Hat Advanced Cluster Management for Kubernetes 策略可以至少有一个或多个模板。有关策略元素的更多详情,请参阅本页面的以下策略 YAML 表部分。

策略需要一个 PlacementRule,用于定义策略文档应用到的集群,以及将 Red Hat Advanced Cluster Management for Kubernetes 策略绑定到放置规则的 PlacementBinding

重要

  • 您必须创建一个 placementRule 以将策略应用到受管集群,并将 placementRulePlacementBinding 绑定。
  • 除集群命名空间外,您可在 hub 集群上的任意命名空间中创建策略。如果在集群命名空间中创建策略,则 Red Hat Advanced Cluster Management for Kubernetes 会将其删除。
  • 每个客户端和供应商负责确保其受管云环境满足适用于 Kubernetes 集群上托管的工作负载的内部软件工程、安全工程、弹性、安全性以及合规性企业安全标准。使用监管和安全功能来提高可见性并对配置进行修复,以满足标准。

2.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:
spec:
  policy-templates:
    - objectDefinition:
        apiVersion:
        kind:
        metadata:
          name:
        spec:
  remediationAction:
  disabled:

---
apiVersion: apps.open-cluster-management.io/v1
kind: PlacementBinding
metadata:
  name:
placementRef:
  name:
  kind:
  apiGroup:
subjects:
- name:
  kind:
  apiGroup:

---
apiVersion: apps.open-cluster-management.io/v1
kind: PlacementRule
metadata:
  name:
spec:
  clusterConditions:
  - type:
  clusterLabels:
    matchLabels:
      cloud:

2.2.2. 策略 YAML 表

字段描述

apiVersion

必需。将值设置为 policy.open-cluster-management.io/v1

kind

必需。将值设为 Policy 以表示策略类型。

metadata.name

必需。用于标识策略资源的名称。

metadata.annotations

可选。用于指定一组描述策略试图验证的标准集合的安全详情。:您可以从控制台根据您在策略页面上为策略定义的标准和类别查看 策略 违反情况。

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

正在接受检查的安全控制名称。例如,互联网安全中心 (CIS) 和证书策略控制器。

spec.policy-templates

必需。用于创建一个或多个应用到受管集群的策略。

spec.disabled

必需。将值设为 truefalsedisabled 参数提供启用和禁用策略的功能。

spec.remediationAction

可选。指定您的策略的修复。参数值是 enforceinform。如果指定,定义的 spec.remediationAction 值会覆盖子策略中定义的 remediationAction 参数,从 policy-templates 部分。例如,如果将 spec.remediationAction 值部分设定为 enforce,那么 policy-templates 部分中的 remediationAction 会在运行时被设置为 enforce重要:有些策略可能不支持 enforce 功能。

2.2.3. 策略示例文件

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
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:
            exclude: ["kube-*"]
            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: PlacementRule
  apiGroup: apps.open-cluster-management.io
subjects:
- name: policy-role
  kind: Policy
  apiGroup: policy.open-cluster-management.io
---
apiVersion: apps.open-cluster-management.io/v1
kind: PlacementRule
metadata:
  name: placement-policy-role
spec:
  clusterConditions:
  - status: "True"
    type: ManagedClusterConditionAvailable
  clusterSelector:
    matchExpressions:
      - {key: environment, operator: In, values: ["dev"]}

请参阅管理安全策略以创建和更新策略。您还可以启用和更新 Red Hat Advanced Cluster Management 策略控制器,以验证您的策略合规性。请参阅策略控制器。有关更多策略主题,请参阅监管和风险

2.3. 策略控制器

策略控制器监控并报告集群是否合规。通过开箱即用的策略模板应用预定义策略控制器和策略,以使用 Red Hat Advanced Cluster Management for Kubernetes 策略框架。策略控制器是 Kubernetes CustomResourceDefinition (CRD) 实例。有关 CRD 的更多信息,请参阅使用 CustomResourceDefinitions 扩展 Kubernetes API。策略控制器会修复策略违反情况,以使集群状态兼容。

您可以使用产品策略框架创建自定义策略和策略控制器。如需更多信息,请参阅创建自定义策略控制器

重要:只有配置策略控制器支持 enforce 功能。当策略控制器不支持 enforce 功能时,您必须手动修复策略。

查看以下主题以了解有关以下 Red Hat Advanced Cluster Management for Kubernetes 策略控制器的更多信息:

有关管理您的策略的更多主题,请参阅监管和风险

2.3.1. Kubernetes 配置策略控制器

配置策略控制器可用于配置任何 Kubernetes 资源,并在集群中应用安全策略。

配置策略控制器与本地 Kubernetes API 服务器通信,以获取集群中的配置列表。有关 CRD 的更多信息,请参阅使用 CustomResourceDefinitions 扩展 Kubernetes API

配置策略控制器是在安装过程中在 hub 集群上创建的。配置策略控制器支持 enforce 功能并监控以下策略的合规性:

当将配置策略的 remediationAction 设置为 enforce 时,控制器会在目标受管集群上创建副本策略。

2.3.1.1. 配置策略控制器 YAML 结构

Name:         configuration-policy-example
Namespace:
Labels:
APIVersion:   policy.open-cluster-management.io/v1
Kind:         ConfigPolicy
Metadata:
  Finalizers:
    finalizer.policy.open-cluster-management.io
Spec:
  Conditions:
    Ownership:
    NamespaceSelector:
      Exclude:
      Include:
    RemediationAction:
 Status:
   CompliancyDetails:
     Configuration-Policy-Example:
       Default:
       Kube - Public:
   Compliant:          Compliant
 Events:

2.3.1.2. 配置策略示例

apiVersion: policy.open-cluster-management.io/v1
kind: ConfigPolicy
metadata:
  name: policy-config
spec:
  namespaceSelector:
    include: ["default"]
    exclude: []
  remediationAction: inform
    severity: low
    object-templates:
    - complianceType: musthave
      objectDefinition:
        apiVersion: v1
        kind: Pod
        metadata:
          name: nginx-pod
        spec:
          containers:
          - image: nginx:1.7.9
            name: nginx
            ports:
           - containerPort: 80

2.3.1.3. 配置策略 YAML 标

表 2.1. 参数表

字段描述

apiVersion

必需。将值设置为 policy.open-cluster-management.io/v1

kind

必需。将值设置为 ConfigPolicy 来代表策略类型。

metadata.name

必需。策略的名称。

spec

必需。有关监控哪些配置策略以及如何进行修复的规格。

spec.namespaceSelector

必需。策略应用到的节点集群内命名空间。至少为 include 参数输入一个命名空间,这是您要将策略应用到的命名空间。exclude 参数指定您明确不希望将策略应用到的命名空间。

spec.remediationAction

必需。指定您的策略的修复。输入 inform

remediationAction.severity

必需。当策略不合规时,指定严重性。使用以下参数值: lowmediumhigh

remediationAction.complianceType

必需。用于列出必须被评估或应用到受管集群的角色的预期行为和任何 Kubernetes 对象。您必须使用以下操作动词作为参数值:

mustonlyhave :表示必须存在带有准确名称和相关字段的对象。

musthave :表示必须存在名称与指定 object-template 的名称相同的对象。模板中的其它字段是对象中存在的子集。

mustnothave:指明具有相同名称或标签的对象不能存在,需要删除,而不管规格或规则是什么。

了解策略将如何应用到您的 hub 集群中。如需更多详细信息,请参阅策略示例。了解如何创建和自定义策略,请参阅管理安全策略

有关控制器的更多信息,请参阅策略控制器

2.3.2. 证书策略控制器

证书策略控制器可以用来检测快要到期的证书,并检测时间太长(小时)或包含无法与指定模式匹配的 DNS 名称。

通过更新控制器策略中的以下参数来配置和自定义证书策略控制器:

  • minimumDuration
  • minimumCADuration
  • maximumDuration
  • maximumCADuration
  • allowedSANPattern
  • disallowedSANPattern

由于以下情况之一,您的策略可能会变得不合规:

  • 当证书过期的时间少于最短持续时间,或超过最长时间时。
  • 当 DNS 名称与指定模式匹配时。

证书策略控制器是在受管集群上创建的。控制器与本地 Kubernetes API 服务器通信,以获取包含证书的 secret 列表,并确定所有不合规的证书。有关 CRD 的更多信息,请参阅使用 CustomResourceDefinitions 扩展 Kubernetes API

证书策略控制器不支持 enforce 功能。

2.3.2.1. 证书策略控制器 YAML 结构

查看证书策略的以下示例,并查看 YAML 表中的元素:

apiVersion: policy.open-cluster-management.io/v1
kind: CertificatePolicy
metadata:
  name: certificate-policy-example
  namespace:
  labels: category=system-and-information-integrity
spec:
  namespaceSelector:
    include: ["default"]
    exclude: ["kube-*"]
  remediationAction:
  severity:
  minimumDuration:
  minimumCADuration:
  maximumDuration:
  maximumCADuration:
  allowedSANPattern:
  disallowedSANPattern:
2.3.2.1.1. 证书策略控制器 YAML 表

表 2.2. 参数表

字段描述

apiVersion

必需。将值设置为 policy.open-cluster-management.io/v1

kind

必需。将值设为 CertificatePolicy 以表示策略类型。

metadata.name

必需。用于标识策略的名称。

netadata.namespace

必需。创建了策略的受管集群内命名空间。

metadata.labels

可选。在证书策略中,category=system-and-information-integrity 标签将对策略进行分类,并促进查询证书策略。如果您的证书策略中 category 键的值不同,该值会被证书控制器覆盖。

spec

必需。有关要监控和刷新哪些证书的规格。

spec.namespaceSelector

必需。要将策略应用到的受管集群命名空间。输入 IncludeExclude 的参数值。备注:

• 当您创建多个证书策略并将其应用到同一受管集群时,必须为每个策略 namespaceSelector 分配一个不同的值。

• 如果证书策略控制器的 namespaceSelector 与任何命名空间不匹配,则该策略被视为合规。

spec.remediationAction

必需。指定您的策略的修复。将参数值设置为 inform。证书策略控制器只支持 inform 功能。

spec.severity

可选。当策略不合规时,会告知用户的严重性。使用以下参数值: lowmediumhigh

spec.minimumDuration

必需。如果没有指定值,则默认为 100h。参数指定证书被视为不合规前的最短持续时间(以小时为单位)。参数值使用 Golang 的持续时间格式。如需更多信息,请参阅 Golang 解析持续时间

spec.minimumCADuration

可选。设定一个与其他证书不同的值来标识可能很快过期的签名证书。如果没有指定参数值,则 CA 证书过期时间作为 minimumDuration 的值。如需更多信息,请参阅 Golang 解析持续时间

spec.maximumDuration

可选。指定一个值来标识创建的时间超过您所期望的限制值的证书。参数使用 Golang 的持续时间格式。如需更多信息,请参阅 Golang 解析持续时间

spec.maximumCADuration

可选。创建一个值来标识创建的时间超过您定义的限制值的签名的证书。参数使用 Golang 的持续时间格式。如需更多信息,请参阅 Golang 解析持续时间

spec.allowedSANPattern

可选。正则表达式,必须与您证书中定义的每个 SAN 条目匹配。这个参数会根据特征检查 DNS 名称。如需更多信息,请参阅 Golang 郑则表达式语法

spec.disallowedSANPattern

可选。正则表达式,不能与证书中定义的任何 SAN 条目匹配。这个参数会根据特征检查 DNS 名称。如需更多信息,请参阅 Golang 郑则表达式语法

2.3.2.2. 证书策略示例

当在 hub 集群上创建证书策略控制器时,会在受管集群上创建复制策略。受管集群上的证书策略可能类似以下文件:

apiVersion: policy.open-cluster-management.io/v1
kind: CertificatePolicy
metadata:
  name: certificate-policy-1
  namespace: kube-system
  label:
    category: "System-Integrity"
spec:
  namespaceSelector:
    include: ["default", "kube-*"]
    exclude: ["kube-system"]
  remediationAction: inform
  minimumDuration: 100h
  minimumCADuration: 200h
  maximumDuration: 2161h
  maximumCADuration: 43920h
  allowedSANPattern: "[[:alpha:]]"
  disallowedSANPattern: "[\\*]"

了解如何管理证书策略,请参阅管理证书策略以了解更多详细信息。有关更多主题,请参阅策略控制器

2.3.3. IAM 策略控制器

Identity and Access Management (IAM) 策略控制器可以用来接收有关不合规的 IAM 策略的通知。合规性检查是基于您在 IAM 策略中配置的参数。

IAM 策略控制器检查集群中所允许的集群管理员数量的合规性。IAM 策略控制器与本地 Kubernetes API 服务器通信。如需更多信息,请参阅使用 CustomResourceDefinitions 扩展 Kubernetes API

IAM 策略控制器在您的受管集群上运行。

2.3.3.1. IAM 策略 YAML 结构

查看 IAM 策略的以下示例,并查看 YAML 表中的参数:

apiVersion: policy.open-cluster-management.io/v1
kind: IamPolicy
metadata:
  name:
spec:
  severity:
  namespaceSelector:
    include:
    exclude:
  remediationAction:
  maxClusterRoleBindingUsers:

2.3.3.2. IAM 策略 YAMl 表

查看以下参数表以获详细信息:

表 2.3. 参数表

字段描述

apiVersion

必需。将值设置为 policy.open-cluster-management.io/v1

kind

必需。将值设为 Policy 以表示策略类型。

metadata.name

必需。用于标识策略资源的名称。

spec

必需。添加策略的配置详情。

spec.namespaceSelector

必需。策略应用到的节点集群内命名空间。至少为 include 参数输入一个命名空间,这是您要将策略应用到的命名空间。exclude 参数指定您明确不希望将策略应用到的命名空间。:在策略控制器的对象模板中指定的命名空间会覆盖前面参数值中的命名空间。

spec.remediationAction

必需。指定您的策略的修复。输入 inform

spec.maxClusterRoleBindingUsers

必需。在策略被视为不合规前可用的 IAM rolebinding 的最大数量。

2.3.3.3. IAM 策略示例

apiVersion: policy.open-cluster-management.io/v1
kind: IamPolicy # limit clusteradminrole and report violation
metadata:
  name: {{name}}-example
spec:
  severity: medium
  namespaceSelector:
    include: ["*"]
    exclude: ["kube-*", "openshift-*"]
  remediationAction: inform # will be overridden by remediationAction in parent policy
  maxClusterRoleBindingUsers: 5

了解如何管理 IAM 策略,请参阅管理 IAM 策略以了解更多详细信息。有关更多主题,请参阅策略控制器

2.3.4. 集成第三方策略控制器

集成第三方策略,在策略模板中创建自定义注解,以指定一个或多个合规标准、控制类别和控制。

您还可以使用来自 policy-collection/community 中的第三方策略。

了解如何集成以下第三方策略:

2.3.5. 创建自定义策略控制器

了解如何编写、应用、查看和更新您的自定义策略控制器。您可以为策略控制器创建 YAML 文件,以部署到集群中。查看以下部分以创建策略控制器:

2.3.5.1. 编写一个策略控制器

使用 multicloud-operators-policy-controller 仓库中的策略控制器框架。完成以下步骤来创建策略控制器:

  1. 运行以下命令克隆 multicloud-operators-policy-controller 仓库:

    git clone git@github.com:open-cluster-management/multicloud-operators-policy-controller.git
  2. 通过更新策略模式定义自定义控制器策略。您的策略可能类似以下内容:

    metadata:
      name: samplepolicies.policies.open-cluster-management.io
    spec:
      group: policy.open-cluster-management.io
      names:
        kind: SamplePolicy
        listKind: SamplePolicyList
        plural: samplepolicies
        singular: samplepolicy
  3. 更新策略控制器以监视 SamplePolicy kind。运行以下命令:

    for file in $(find . -name "*.go" -type f); do  sed -i "" "s/SamplePolicy/g" $file; done
    for file in $(find . -name "*.go" -type f); do  sed -i "" "s/samplepolicy-controller/samplepolicy-controller/g" $file; done
  4. 通过完成以下步骤重新编译并运行策略控制器:

    1. 登录到您的集群。
    2. 选择用户图标,然后点击 Configure client
    3. 将配置信息复制并粘贴到您的命令行中,然后按 Enter 键。
    4. 运行以下命令以应用您的策略 CRD 并启动控制器:

      export GO111MODULE=on
      
      kubectl apply -f deploy/crds/policy.open-cluster-management.io_samplepolicies_crd.yaml
      
      operator-sdk run --local --verbose

      您可能会收到以下输出来表示控制器在运行:

      {“level”:”info”,”ts”:1578503280.511274,”logger”:”controller-runtime.manager”,”msg”:”starting metrics server”,”path”:”/metrics”}
      {“level”:”info”,”ts”:1578503281.215883,”logger”:”controller-runtime.controller”,”msg”:”Starting Controller”,”controller”:”samplepolicy-controller”}
      {“level”:”info”,”ts”:1578503281.3203468,”logger”:”controller-runtime.controller”,”msg”:”Starting workers”,”controller”:”samplepolicy-controller”,”worker count”:1}
      Waiting for policies to be available for processing…
    5. 创建策略,验证控制器是否已检索策略,并在集群中应用策略。运行以下命令:

      kubectl apply -f deploy/crds/policy.open-cluster-management.io_samplepolicies_crd.yaml

      应用策略时,会出现一条消息来指示您的自定义控制器监控并检测到策略。信息可能类似以下内容:

    {"level":"info","ts":1578503685.643426,"logger":"controller_samplepolicy","msg":"Reconciling SamplePolicy","Request.Namespace":"default","Request.Name":"example-samplepolicy"}
    {"level":"info","ts":1578503685.855259,"logger":"controller_samplepolicy","msg":"Reconciling SamplePolicy","Request.Namespace":"default","Request.Name":"example-samplepolicy"}
    Available policies in namespaces:
    namespace = kube-public; policy = example-samplepolicy
    namespace = default; policy = example-samplepolicy
    namespace = kube-node-lease; policy = example-samplepolicy
  5. 运行以下命令,检查 status 字段中的合规详情:

    kubectl describe SamplePolicy example-samplepolicy -n default

    您的输出可能类似以下内容:

    status:
      compliancyDetails:
        example-samplepolicy:
          cluster-wide:
          - 5 violations detected in namespace `cluster-wide`, there are 0 users violations
            and 5 groups violations
          default:
          - 0 violations detected in namespace `default`, there are 0 users violations
            and 0 groups violations
          kube-node-lease:
          - 0 violations detected in namespace `kube-node-lease`, there are 0 users violations
            and 0 groups violations
          kube-public:
          - 1 violations detected in namespace `kube-public`, there are 0 users violations
            and 1 groups violations
      compliant: NonCompliant
  6. 更改策略规则和策略逻辑,为您的策略控制器引入新规则。完成以下步骤:

    1. 通过更新 SamplePolicySpec 在 YAML 文件中添加新字段 。您的规格应该和以下类似:

      spec:
        description: SamplePolicySpec defines the desired state of SamplePolicy
        properties:
          labelSelector:
            additionalProperties:
              type: string
            type: object
          maxClusterRoleBindingGroups:
            type: integer
          maxClusterRoleBindingUsers:
            type: integer
          maxRoleBindingGroupsPerNamespace:
            type: integer
          maxRoleBindingUsersPerNamespace:
            type: integer
    2. 使用新字段在 samplepolicy_controller.go 中更新 SamplePolicySpec 的数据结构。
    3. 使用新的路径更新 samplepolicy_controller.go 文件中的 PeriodicallyExecSamplePolicies 函数来运行策略控制器。查看 PeriodicallyExecSamplePolicies 字段的一个示例,请参阅 open-cluster-management/multicloud-operators-policy-controller
    4. 重新编译并运行策略控制器。请参阅编写策略控制器

您的策略控制器可以正常工作。

2.3.5.2. 将控制器部署到集群中

将自定义策略控制器部署到集群,并将策略控制器与监管和风险仪表板集成。完成以下步骤:

  1. 运行以下命令构建策略控制器镜像:

    operator-sdk build <username>/multicloud-operators-policy-controller:latest
  2. 运行以下命令将镜像推送到您选择的仓库中。例如,运行以下命令将镜像 push 到 Docker Hub:

    docker login
    
    docker push <username>/multicloud-operators-policy-controller
  3. 配置 kubectl 以指向由 Red Hat Advanced Cluster Management for Kubernetes 管理的集群。
  4. 替换 operator 清单以使用内置镜像名称,并更新命名空间以监视策略。命名空间必须是集群的命名空间。您的清单可能类似以下内容:

    sed -i "" 's|open-cluster-management/multicloud-operators-policy-controller|ycao/multicloud-operators-policy-controller|g' deploy/operator.yaml
    sed -i "" 's|value: default|value: <namespace>|g' deploy/operator.yaml
  5. 运行以下命令更新 RBAC 角色:

    sed -i "" 's|samplepolicies|testpolicies|g' deploy/cluster_role.yaml
    sed -i "" 's|namespace: default|namespace: <namespace>|g' deploy/cluster_role_binding.yaml
  6. 将策略控制器部署到集群中:

    1. 使用以下命令为集群设置服务帐户:

      kubectl apply -f deploy/service_account.yaml -n <namespace>
    2. 运行以下命令来为 operator 创建 RBAC:

      kubectl apply -f deploy/role.yaml -n <namespace>
      
      kubectl apply -f deploy/role_binding.yaml -n <namespace>
    3. 为您的 PolicyController 设置 RBAC。运行以下命令:

      kubectl apply -f deploy/cluster_role.yaml
      kubectl apply -f deploy/cluster_role_binding.yaml
    4. 运行以下命令设置 CustomResourceDefinition(CRD):

      kubectl apply -f deploy/crds/policies.open-cluster-management.io_samplepolicies_crd.yaml
    5. 运行以下命令来部署 multicloud-operator-policy-controller:

      kubectl apply -f deploy/operator.yaml -n <namespace>
    6. 运行以下命令验证控制器是否正常工作:

      kubectl get pod -n <namespace>
  7. 您必须通过为控制器创建一个 策略模板 来集成您的策略控制器。如需更多信息,请参阅从控制台创建集群安全策略
2.3.5.2.1. 扩展控制器部署

策略控制器部署不支持删除。您可以扩展部署,以更新部署应用到哪些 pod。完成以下步骤:

  1. 登录到受管集群。
  2. 导航到自定义策略控制器的部署。
  3. 扩展部署。当将部署扩展到零个 pod 时,策略控制程序部署将被禁用。

如需有关部署的更多信息,请参阅 OpenShift Container Platform 部署

您的策略控制器已部署并在集群中集成。如需更多信息,请参阅策略控制器

2.4. 策略示例

查看策略示例,了解如何在 Red Hat Advanced Cluster Management for Kubernetes 中创建和管理策略时如何在 hub 集群上定义规则、流程和控制。

:您可以将现有策略复制到 Policy YAML 中。当您粘贴现有策略时,会自动输入参数字段的值。您还可以使用搜索功能搜索策略 YAML 文件中的内容。

查看以下策略示例以查看具体策略是如何应用的:

更多主题请参阅监管和风险

2.4.1. 内存用量策略

Kubernetes 配置策略控制器负责监控内存用量策略的状态。使用内存用量策略来限制或约束您的内存和计算用量。如需更多信息,请参阅 Kubernetes 文档中的限制范围。在以下部分了解更多有关内存用量策略结构的详细信息。

2.4.1.1. 内存用量策略 YAML 结构

您的内存用量策略可能类似以下 YAML 文件:

   apiVersion: policy.open-cluster-management.io/v1
   kind: Policy
   metadata:
     name: policy-limitrange
     namespace:
   spec:
     complianceType:
     remediationAction:
     namespaces:
       exclude:
       include:
     object-templates:
       - complianceType:
         objectDefinition:
           apiVersion:
           kind:
           metadata:
             name:
           spec:
             limits:
             - default:
                 memory:
               defaultRequest:
                 memory:
               type:
           ...

2.4.1.2. 内存用量策略表

字段描述

apiVersion

必需。将值设置为 policy.open-cluster-management.io/v1

kind

必需。将值设为 Policy 以表示策略类型。

metadata.name

必需。用于标识策略资源的名称。

metadata.namespaces

可选。

spec.namespace

必需。策略应用到的节点集群内命名空间。输入 include 的参数值,这是您要将策略应用到的命名空间。exclude 参数指定您明确不希望将策略应用到的命名空间。:在策略控制器的对象模板中指定的命名空间会覆盖对应父策略中的命名空间。

remediationAction

可选。指定您的策略的修复。参数值是 enforceinform重要:有些策略可能不支持 enforce 功能。

disabled

必需。将值设为 truefalsedisabled 参数提供启用和禁用策略的功能。

spec.complianceType

必需。将值设为 "musthave"

spec.object-template

可选。用于列出必须接受评估或应用到受管集群的任何其他 Kubernetes 对象。

2.4.1.3. 内存用量策略示例

   apiVersion: policy.open-cluster-management.io/v1
   kind: Policy
   metadata:
     name: policy-limitrange
     namespace: mcm
   spec:
     complianceType: musthave
     remediationAction: inform
     namespaces:
       exclude: ["kube-*"]
       include: ["default"]
     object-templates:
       - complianceType: musthave
         objectDefinition:
           apiVersion: v1
           kind: LimitRange # limit memory usage
           metadata:
             name: mem-limit-range
           spec:
             limits:
             - default:
                 memory: 512Mi
               defaultRequest:
                 memory: 256Mi
               type: Container
           ...

如需更多信息,请参阅管理内存用量策略。查看由控制器监控的其他配置策略,请参阅 Kubernetes 配置策略控制器页面。

2.4.2. 命名空间策略

Kubernetes 配置策略控制器负责监控命名空间策略的状态。应用命名空间策略来为您的命名空间定义特定规则。在以下部分了解更多有关命名空间策略结构的详细信息。

2.4.2.1. 命名空间策略 YAML 结构

   apiVersion: policy.open-cluster-management.io/v1
   kind: Policy
   metadata:
     name: policy-namespace-1
     namespace:
   spec:
     complianceType:
     remediationAction:
     namespaces:
       exclude:
       include:
     object-templates:
       - complianceType:
         objectDefinition:
           kind:
           apiVersion:
           metadata:
             name:
        ...

2.4.2.2. 命名空间策略 YAML 表

字段描述

apiVersion

必需。将值设置为 policy.open-cluster-management.io/v1

kind

必需。将值设为 Policy 以表示策略类型。

metadata.name

必需。用于标识策略资源的名称。

metadata.namespaces

可选。

spec.namespace

必需。策略应用到的节点集群内命名空间。输入 include 的参数值,这是您要将策略应用到的命名空间。exclude 参数指定您明确不希望将策略应用到的命名空间。:在策略控制器的对象模板中指定的命名空间会覆盖对应父策略中的命名空间。

remediationAction

可选。指定您的策略的修复。参数值是 enforceinform重要:有些策略可能不支持 enforce 功能。

disabled

必需。将值设为 truefalsedisabled 参数提供启用和禁用策略的功能。

spec.complianceType

必需。将值设为 "musthave"

spec.object-template

可选。用于列出必须接受评估或应用到受管集群的任何其他 Kubernetes 对象。

2.4.2.3. 命名空间策略示例

您的命名空间策略可能类似以下 YAML 文件:

   apiVersion: policy.open-cluster-management.io/v1
   kind: Policy
   metadata:
     name: policy-namespace-1
     namespace: open-cluster-management
   spec:
     complianceType: musthave
     remediationAction: inform
     namespaces:
       exclude: ["kube-*"]
       include: ["default"]
     object-templates:
       - complianceType: musthave
         objectDefinition:
           kind: Namespace # must have namespace 'prod'
           apiVersion: v1
           metadata:
             name: prod
        ...

管理命名空间策略。如需更多信息,请参阅管理命名空间策略。如需了解其他配置策略,请参阅 Kubernetes 配置策略控制器

2.4.3. 镜像漏洞策略

应用镜像漏洞策略,以利用 Container Security Operator 来检测容器镜像是否有漏洞。如果没有安装 Container Security Operator,该策略会在受管集群上安装它。

镜像漏洞策略由 Kubernetes 配置策略控制器负责检查。有关 Security Operator 的更多信息,请参阅 Quay 存储库中的 Container Security Operator

备注:镜像漏洞策略在断开连接的安装过程中无法正常工作。

2.4.3.1. 镜像漏洞策略 YAML 结构

apiVersion: policy.open-cluster-management.io/v1
kind: Policy
metadata:
  name: policy-imagemanifestvulnpolicy
  namespace: default
  annotations:
    policy.open-cluster-management.io/standards: NIST-CSF
    policy.open-cluster-management.io/categories: DE.CM Security Continuous Monitoring
    policy.open-cluster-management.io/controls: DE.CM-8 Vulnerability Scans
spec:
  remediationAction:
  disabled:
  policy-templates:
  - objectDefinition:
      apiVersion: policy.open-cluster-management.io/v1
      kind: ConfigurationPolicy
      metadata:
        name:
      spec:
        remediationAction:
        severity: high
        object-templates:
          - complianceType:
            objectDefinition:
              apiVersion: operators.coreos.com/v1alpha1
              kind: Subscription
              metadata:
                name: container-security-operator
                namespace:
              spec:
                channel:
                installPlanApproval:
                name:
                source:
                sourceNamespace:
  - objectDefinition:
      apiVersion: policy.open-cluster-management.io/v1
      kind: ConfigurationPolicy
      metadata:
        name:
      spec:
        remediationAction:
        severity:
        namespaceSelector:
          exclude:
          include:
        object-templates:
          - complianceType:
            objectDefinition:
              apiVersion: secscan.quay.redhat.com/v1alpha1
              kind: ImageManifestVuln # checking for a kind
---
apiVersion: policy.open-cluster-management.io/v1
kind: PlacementBinding
metadata:
  name: binding-policy-imagemanifestvulnpolicy
  namespace: default
placementRef:
  name:
  kind:
  apiGroup:
subjects:
- name:
  kind:
  apiGroup:
---
apiVersion: apps.open-cluster-management.io/v1
kind: PlacementRule
metadata:
  name: placement-policy-imagemanifestvulnpolicy
  namespace: default
spec:
  clusterConditions:
  - status:
    type:
  clusterSelector:
    matchExpressions:
      []  # selects all clusters if not specified

2.4.3.2. 镜像漏洞策略 YAML 表

字段描述

apiVersion

必需。将值设置为 policy.open-cluster-management.io/v1

kind

必需。将值设为 Policy 以表示策略类型。

metadata.name

必需。用于标识策略资源的名称。

metadata.namespaces

可选。

spec.namespace

必需。策略应用到的节点集群内命名空间。输入 include 的参数值,这是您要将策略应用到的命名空间。exclude 参数指定您明确不希望将策略应用到的命名空间。:在策略控制器的对象模板中指定的命名空间会覆盖对应父策略中的命名空间。

remediationAction

可选。指定您的策略的修复。参数值是 enforceinform重要:有些策略可能不支持 enforce 功能。

disabled

必需。将值设为 truefalsedisabled 参数提供启用和禁用策略的功能。

spec.complianceType

必需。将值设为 "musthave"

spec.object-template

可选。用于列出必须接受评估或应用到受管集群的任何其他 Kubernetes 对象。

2.4.3.3. 镜像漏洞策略示例

apiVersion: policy.open-cluster-management.io/v1
kind: Policy
metadata:
  name: policy-imagemanifestvulnpolicy
  namespace: default
  annotations:
    policy.open-cluster-management.io/standards: NIST-CSF
    policy.open-cluster-management.io/categories: DE.CM Security Continuous Monitoring
    policy.open-cluster-management.io/controls: DE.CM-8 Vulnerability Scans
spec:
  remediationAction: inform
  disabled: false
  policy-templates:
  - objectDefinition:
      apiVersion: policy.open-cluster-management.io/v1
      kind: ConfigurationPolicy
      metadata:
        name: policy-imagemanifestvulnpolicy-example-sub
      spec:
        remediationAction: inform # will be overridden by remediationAction in parent policy
        severity: high
        object-templates:
          - complianceType: musthave
            objectDefinition:
              apiVersion: operators.coreos.com/v1alpha1
              kind: Subscription
              metadata:
                name: container-security-operator
                namespace: openshift-operators
              spec:
                channel: quay-v3.3
                installPlanApproval: Automatic
                name: container-security-operator
                source: redhat-operators
                sourceNamespace: openshift-marketplace
  - objectDefinition:
      apiVersion: policy.open-cluster-management.io/v1
      kind: ConfigurationPolicy
      metadata:
        name: policy-imagemanifestvulnpolicy-example-imv
      spec:
        remediationAction: inform # will be overridden by remediationAction in parent policy
        severity: high
        namespaceSelector:
          exclude: ["kube-*"]
          include: ["*"]
        object-templates:
          - complianceType: mustnothave # mustnothave any ImageManifestVuln object
            objectDefinition:
              apiVersion: secscan.quay.redhat.com/v1alpha1
              kind: ImageManifestVuln # checking for a kind
---
apiVersion: policy.open-cluster-management.io/v1
kind: PlacementBinding
metadata:
  name: binding-policy-imagemanifestvulnpolicy
  namespace: default
placementRef:
  name: placement-policy-imagemanifestvulnpolicy
  kind: PlacementRule
  apiGroup: apps.open-cluster-management.io
subjects:
- name: policy-imagemanifestvulnpolicy
  kind: Policy
  apiGroup: policy.open-cluster-management.io
---
apiVersion: apps.open-cluster-management.io/v1
kind: PlacementRule
metadata:
  name: placement-policy-imagemanifestvulnpolicy
  namespace: default
spec:
  clusterConditions:
  - status: "True"
    type: ManagedClusterConditionAvailable
  clusterSelector:
    matchExpressions:
      []  # selects all clusters if not specified

有关更多信息,请参阅管理镜像漏洞策略。查看由配置控制器监控的其他配置策略,请参阅 Kubernetes 配置策略控制器

2.4.4. Pod nginx 策略

Kubernetes 配置策略控制器负责监控 Pod nginx 策略的状态。应用 Pod 策略来为 Pod 定义容器规则。Nginx Pod 必须存在于集群中。

2.4.4.1. Pod nginx 策略 YAML 结构

   apiVersion: policy.open-cluster-management.io/v1
   kind: Policy
   metadata:
     name: policy-pod
     namespace:
   spec:
     complianceType:
     remediationAction:
     namespaces:
       exclude:
       include:
     object-templates:
       - complianceType:
         objectDefinition:
           apiVersion:
           kind: Pod # nginx pod must exist
           metadata:
             name:
           spec:
             containers:
             - image:
               name:
               ports:
               - containerPort:
        ...

2.4.4.2. Pod nginx 策略表

字段描述

apiVersion

必需。将值设置为 policy.open-cluster-management.io/v1

kind

必需。将值设为 Policy 以表示策略类型。

metadata.name

必需。用于标识策略资源的名称。

metadata.namespaces

可选。

spec.namespace

必需。策略应用到的节点集群内命名空间。输入 include 的参数值,这是您要将策略应用到的命名空间。exclude 参数指定您明确不希望将策略应用到的命名空间。:在策略控制器的对象模板中指定的命名空间会覆盖对应父策略中的命名空间。

remediationAction

可选。指定您的策略的修复。参数值是 enforceinform重要:有些策略可能不支持 enforce 功能。

disabled

必需。将值设为 truefalsedisabled 参数提供启用和禁用策略的功能。

spec.complianceType

必需。将值设为 "musthave"

spec.object-template

可选。用于列出必须接受评估或应用到受管集群的任何其他 Kubernetes 对象。

2.4.4.3. Pod nginx 策略示例

您的 Pod nginx 策略可能类似以下 YAML 文件:

   apiVersion: policy.open-cluster-management.io/v1
   kind: Policy
   metadata:
     name: policy-pod
     namespace: open-cluster-management
   spec:
     complianceType: musthave
     remediationAction: inform
     namespaces:
       exclude: ["kube-*"]
       include: ["default"]
     object-templates:
       - complianceType: musthave
         objectDefinition:
           apiVersion: v1
           kind: Pod # nginx pod must exist
           metadata:
             name: nginx-pod
           spec:
             containers:
             - image: nginx:1.7.9
               name: nginx
               ports:
               - containerPort: 80
        ...

了解如何管理 Pod nginx 策略,请参阅管理 Pod nginx 策略以了解更多详细信息。查看由配置控制器监控的其他配置策略,请参阅 Kubernetes 配置策略控制器。请参阅管理安全策略以管理其他策略。

2.4.5. Pod 安全策略

Kubernetes 配置策略控制器负责监控 Pod 安全策略的状态。应用 Pod 安全策略来保护 Pod 和容器。如需更多信息,请参阅 Kubernetes 文档中的 Pod 安全策略。在以下部分了解更多有关 pod 安全策略结构的详细信息。

2.4.5.1. Pod 安全策略 YAML 结构

   apiVersion: policy.open-cluster-management.io/v1
   kind: Policy
   metadata:
     name: policy-podsecuritypolicy
     namespace:
   spec:
     complianceType:
     remediationAction:
     namespaces:
       exclude:
       include:
     object-templates:
       - complianceType:
         objectDefinition:
           apiVersion:
           kind: PodSecurityPolicy # no privileged pods
           metadata:
             name:
             annotations:
           spec:
             privileged:
             allowPrivilegeEscalation:
             allowedCapabilities:
             volumes:
             hostNetwork:
             hostPorts:
             hostIPC:
             hostPID:
             runAsUser:
               rule:
             seLinux:
               rule:
             supplementalGroups:
               rule:
             fsGroup:
               rule:
        ...

2.4.5.2. Pod 安全策略表

字段描述

apiVersion

必需。将值设置为 policy.open-cluster-management.io/v1

kind

必需。将值设为 Policy 以表示策略类型。

metadata.name

必需。用于标识策略资源的名称。

metadata.namespaces

可选。

spec.namespace

必需。策略应用到的节点集群内命名空间。输入 include 的参数值,这是您要将策略应用到的命名空间。exclude 参数指定您明确不希望将策略应用到的命名空间。:在策略控制器的对象模板中指定的命名空间会覆盖对应父策略中的命名空间。

remediationAction

可选。指定您的策略的修复。参数值是 enforceinform重要:有些策略可能不支持 enforce 功能。

disabled

必需。将值设为 truefalsedisabled 参数提供启用和禁用策略的功能。

spec.complianceType

必需。将值设为 "musthave"

spec.object-template

可选。用于列出必须接受评估或应用到受管集群的任何其他 Kubernetes 对象。

2.4.5.3. Pod 安全策略示例

您的 Pod 安全策略可能类似以下 YAML 文件:

   apiVersion: policy.open-cluster-management.io/v1
   kind: Policy
   metadata:
     name: policy-podsecuritypolicy
     namespace: open-cluster-management
   spec:
     complianceType: musthave
     remediationAction: inform
     namespaces:
       exclude: ["kube-*"]
       include: ["default"]
     object-templates:
       - complianceType: musthave
         objectDefinition:
           apiVersion: policy/v1beta1
           kind: PodSecurityPolicy # no privileged pods
           metadata:
             name: restricted-open-cluster-management
             annotations:
            seccomp.security.alpha.kubernetes.io/allowedProfileNames: '*'
           spec:
             privileged: false # no priviliedged pods
             allowPrivilegeEscalation: false
             allowedCapabilities:
             - '*'
             volumes:
             - '*'
             hostNetwork: true
             hostPorts:
             - min: 1000 # ports < 1000 are reserved
               max: 65535
             hostIPC: false
             hostPID: false
             runAsUser:
               rule: 'RunAsAny'
             seLinux:
               rule: 'RunAsAny'
             supplementalGroups:
               rule: 'RunAsAny'
             fsGroup:
               rule: 'RunAsAny'
        ...

如需更多信息,请参阅管理 Pod 安全策略。查看由控制器监控的其他配置策略,请参阅 Kubernetes 配置策略控制器页面。

2.4.6. 角色策略

Kubernetes 配置策略控制器负责监控角色策略的状态。在 object-template 中定义角色来为集群中的特定角色设置规则和权限。在以下部分了解更多有关角色策略结构的详细信息。

2.4.6.1. 角色策略 YAML 结构

apiVersion: policy.open-cluster-management.io/v1
kind: Policy
metadata:
  name: policy-role
  namespace:
  annotations:
    policy.open-cluster-management.io/standards: NIST-CSF
    policy.open-cluster-management.io/categories: PR.AC Identity Management Authentication and Access Control
    policy.open-cluster-management.io/controls: PR.AC-4 Access Control
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 # will be overridden by remediationAction in parent policy
          severity: high
          namespaceSelector:
            exclude: ["kube-*"]
            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
  namespace:
placementRef:
  name: placement-policy-role
  kind: PlacementRule
  apiGroup: apps.open-cluster-management.io
subjects:
- name: policy-role
  kind: Policy
  apiGroup: policy.open-cluster-management.io
---
apiVersion: apps.open-cluster-management.io/v1
kind: PlacementRule
metadata:
  name: placement-policy-role
  namespace:
spec:
  clusterConditions:
    - type: ManagedClusterConditionAvailable
      status: "True"
  clusterSelector:
    matchExpressions:
      []

         ...

2.4.6.2. 角色策略表

字段描述

apiVersion

必需。将值设置为 policy.open-cluster-management.io/v1

kind

必需。将值设为 Policy 以表示策略类型。

metadata.name

必需。用于标识策略资源的名称。

metadata.namespaces

可选。

spec.namespace

必需。策略应用到的节点集群内命名空间。输入 include 的参数值,这是您要将策略应用到的命名空间。exclude 参数指定您明确不希望将策略应用到的命名空间。:在策略控制器的对象模板中指定的命名空间会覆盖对应父策略中的命名空间。

remediationAction

可选。指定您的策略的修复。参数值是 enforceinform重要:有些策略可能不支持 enforce 功能。

disabled

必需。将值设为 truefalsedisabled 参数提供启用和禁用策略的功能。

spec.complianceType

必需。将值设为 "musthave"

spec.object-template

可选。用于列出必须接受评估或应用到受管集群的任何其他 Kubernetes 对象。

2.4.6.3. 角色策略示例

应用角色策略来为集群中的特定角色设置规则和权限。有关角色的更多信息,请参阅基于角色的访问控制。您的角色策略可能类似以下 YAML 文件:

   apiVersion: policy.open-cluster-management.io/v1
   kind: Policy
   metadata:
     name: policy-role
     namespace: open-cluster-management
   spec:
     complianceType: musthave
     remediationAction: inform
     namespaces:
       exclude: ["kube-*"]
       include: ["default"]
     role-templates:
       - apiVersion: open-cluster-management.io/v1/v1alpha1 # role must follow defined permissions
         metadata:
           namespace: "" # will be inferred
           name: operator-role-policy
         selector:
           matchLabels:
             dev: "true"
         complianceType: musthave # at this level, it means the role must exist with the rules that it must have the following
         rules:
           - complianceType: musthave # at this level, it means if the role exists the rule is a musthave
             policyRule:
               apiGroups: ["extensions", "apps"]
               resources: ["deployments"]
               verbs: ["get", "list", "watch", "create", "delete","patch"]
          - complianceType: "mustnothave" # at this level, it means if the role exists the rule is a mustnothave
            policyRule:
              apiGroups: ["core"]
              resources: ["secrets"]
              verbs: ["get", "list", "watch","delete", "create", "update", "patch"]
         ...

如需更多信息,请参阅管理角色策略。查看由控制器监控的其他配置策略,请参阅 Kubernetes 配置策略控制器页面。了解有关 Red Hat Advanced Cluster Management for Kubernates RBAC 的更多信息,请参阅基于角色的访问控制

2.4.7. Rolebinding 策略

Kubernetes 配置策略控制器负责监控 rolebinding 策略的状态。应用 rolebinding 策略,以将策略绑定到受管集群中的命名空间。在以下部分了解更多有关命名空间策略结构的详细信息。

2.4.7.1. Rolebinding 策略 YAML 结构

   apiVersion: policy.open-cluster-management.io/v1
   kind: Policy
   metadata:
     name:
     namespace:
   spec:
     complianceType:
     remediationAction:
     namespaces:
       exclude:
       include:
     object-templates:
       - complianceType:
         objectDefinition:
           kind: RoleBinding # role binding must exist
           apiVersion: rbac.authorization.k8s.io/v1
           metadata:
             name: operate-pods-rolebinding
           subjects:
           - kind: User
             name: admin # Name is case sensitive
             apiGroup:
           roleRef:
             kind: Role #this must be Role or ClusterRole
             name: operator # this must match the name of the Role or ClusterRole you wish to bind to
             apiGroup: rbac.authorization.k8s.io
       ...

2.4.7.2. Rolebinding 策略表

字段描述

apiVersion

必需。将值设置为 policy.open-cluster-management.io/v1

kind

必需。将值设为 Policy 以表示策略类型。

metadata.name

必需。用于标识策略资源的名称。

metadata.namespaces

必需。创建了策略的受管集群内命名空间。

spec

必需。有关如何标识和修复合规违反情况的规格。

metadata.name

必需。用于标识策略资源的名称。

metadata.namespaces

可选。

spec.complianceType

必需。将值设为 "musthave"

spec.namespace

必需。要将策略应用到的受管集群命名空间。输入 include 的参数值,这是您要将策略应用到的命名空间。exclude 参数指定您明确不希望将策略应用到的命名空间。:在策略控制器的对象模板中指定的命名空间会覆盖对应父策略中的命名空间。

spec.remediationAction

必需。指定您的策略的修复。参数值是 enforceinform重要:有些策略可能不支持 enforce 功能。

spec.object-template

必需。用于列出必须接受评估或应用到受管集群的任何其他 Kubernetes 对象。

2.4.7.3. Rolebinding 策略示例

rolebinding 策略可能类似以下 YAML 文件:

   apiVersion: policy.open-cluster-management.io/v1
   kind: Policy
   metadata:
     name: policy-rolebinding
     namespace: open-cluster-management
   spec:
     complianceType: musthave
     remediationAction: inform
     namespaces:
       exclude: ["kube-*"]
       include: ["default"]
     object-templates:
       - complianceType: musthave
         objectDefinition:
           kind: RoleBinding # role binding must exist
           apiVersion: rbac.authorization.k8s.io/v1
           metadata:
             name: operate-pods-rolebinding
           subjects:
           - kind: User
             name: admin # Name is case sensitive
             apiGroup: rbac.authorization.k8s.io
           roleRef:
             kind: Role #this must be Role or ClusterRole
             name: operator # this must match the name of the Role or ClusterRole you wish to bind to
             apiGroup: rbac.authorization.k8s.io
       ...

了解如何管理 rolebinding 策略,请参阅管理 rolebinding 策略以了解更多详细信息。如需了解其他配置策略,请参阅 Kubernetes 配置策略控制器。请参阅管理安全策略以管理其他策略。

2.4.8. 安全性上下文约束策略

Kubernetes 配置策略控制器负责监控安全性上下文约束 (SCC) 策略的状态。应用安全性上下文约束 (SCC) 策略,通过在策略中定义条件来控制 Pod 的权限。在以下部分了解更多有关 SCC 策略的详细信息。

2.4.8.1. SCC 策略 YAML 结构

apiVersion: policy.open-cluster-management.io/v1
kind: Policy
metadata:
  name: policy-scc
  namespace: open-cluster-management-policies
spec:
  complianceType:
  remediationAction:
  namespaces:
    exclude:
    include:
  object-templates:
    - complianceType:
      objectDefinition:
        apiVersion:
        kind: SecurityContextConstraints # restricted scc
        metadata:
          annotations:
            kubernetes.io/description:
          name: sample-restricted-scc
        allowHostDirVolumePlugin:
        allowHostIPC:
        allowHostNetwork:
        allowHostPID:
        allowHostPorts:
        allowPrivilegeEscalation:
        allowPrivilegedContainer:
        allowedCapabilities:
        defaultAddCapabilities:
        fsGroup:
         type:
        groups:
        - system:
        priority:
        readOnlyRootFilesystem:
        requiredDropCapabilities:
        runAsUser:
          type:
        seLinuxContext:
          type:
        supplementalGroups:
          type:
        users:
        volumes:

2.4.8.2. SCC 策略表

字段描述

apiVersion

必需。将值设置为 policy.open-cluster-management.io/v1

kind

必需。将值设为 Policy 以表示策略类型。

metadata.name

必需。用于标识策略资源的名称。

metadata.namespace

必需。创建了策略的受管集群内命名空间。

spec.complianceType

必需。将值设为 "musthave"

spec.remediationAction

必需。指定您的策略的修复。参数值是 enforceinform重要:有些策略可能不支持 enforce 功能。

spec.namespace

必需。要将策略应用到的受管集群命名空间。输入 include 的参数值,这是您要将策略应用到的命名空间。exclude 参数指定您明确不希望将策略应用到的命名空间。:在策略控制器的对象模板中指定的命名空间会覆盖对应父策略中的命名空间。

spec.object-template

必需。用于列出必须接受评估或应用到受管集群的任何其他 Kubernetes 对象。

有关 SCC 策略内容的解释,请参阅 OpenShift Container Platform 文档中的关于安全性上下文约束

2.4.8.3. SCC 策略示例

应用安全性上下文约束 (SCC) 策略,通过在策略中定义条件来控制 Pod 的权限。如需更多信息,请参阅管理安全性上下文约束 (SCC)。您的 SCC 策略可能类似以下 YAML 文件:

   apiVersion: policy.open-cluster-management.io/v1
   kind: Policy
   metadata:
     name: policy-scc
     namespace: open-cluster-management
     annotations:
       policy.open-cluster-management.io/standards: NIST-CSF
       policy.open-cluster-management.io/categories: PR.PT Protective Technology
       policy.open-cluster-management.io/controls: PR.PT-3 Least Functionality
   spec:
     complianceType: musthave
     remediationAction: inform
     disabled: false
     namespaces:
       exclude: ["kube-*"]
       include: ["default"]
     object-templates:
       - complianceType: musthave
         objectDefinition:
           apiVersion: security.openshift.io/v1
           kind: SecurityContextConstraints # restricted scc
           metadata:
             annotations:
               kubernetes.io/description: restricted denies access to all host features and requires pods to be run with a UID, and SELinux context that are allocated to the namespace.  This is the most restrictive SCC and it is used by default for authenticated users.
             name: sample-restricted-scc
           allowHostDirVolumePlugin: false
           allowHostIPC: false
           allowHostNetwork: false
           allowHostPID: false
           allowHostPorts: false
           allowPrivilegeEscalation: true
           allowPrivilegedContainer: false
           allowedCapabilities: []
           defaultAddCapabilities: []
           fsGroup:
             type: MustRunAs
           groups:
           - system:authenticated
           priority: null
           readOnlyRootFilesystem: false
           requiredDropCapabilities:
           - KILL
           - MKNOD
           - SETUID
           - SETGID
           runAsUser:
             type: MustRunAsRange
           seLinuxContext:
             type: MustRunAs
           supplementalGroups:
             type: RunAsAny
           users: []
           volumes:
           - configMap
           - downwardAPI
           - emptyDir
           - persistentVolumeClaim
           - projected
           - secret
   ---
   apiVersion: apps.open-cluster-management.io/v1
   kind: PlacementBinding
   metadata:
     name: binding-policy-scc
     namespace: open-cluster-management-policies
   placementRef:
     name: placement-policy-scc
     kind: PlacementRule
     apiGroup: apps.open-cluster-management.io
   subjects:
   - name: policy-scc
     kind: Policy
     apiGroup: policy.mcm.ibm.com
   ---
   apiVersion: apps.open-cluster-management.io/v1
   kind: PlacementBinding
   metadata:
     name: policy-scc-production-clusters
     namespace: open-cluster-management-policies
   placementRef:
     name: production-clusters
     kind: PlacementRule
     apiGroup: apps.open-cluster-management.io
   subjects:
   - name: policy-scc
     kind: Policy
     apiGroup: policy.mcm.ibm.com
   ---
   apiVersion: apps.open-cluster-management.io/v1
   kind: PlacementRule
   metadata:
     name: placement-policy-scc
     namespace: open-cluster-management-policies
   spec:
     clusterConditions:
       - type: ManagedClusterConditionAvailable
         status: "True"
     clusterSelector:
       matchExpressions: []

要了解如何管理 SCC 策略,请参阅管理安全性上下文约束策略以了解更多详细信息。如需了解其他配置策略,请参阅 Kubernetes 配置策略控制器。请参阅管理安全策略以管理其他策略。

2.4.9. ETCD 加密策略

应用 etcd-encryption 策略,在 ETCD 数据存储中检测或启用敏感数据的加密。Kubernetes 配置策略控制器负责监控 etcd-encryption 策略的状态。如需更多信息,请参阅 OpenShift Container Platform 文档中的 ETCD Encyrption 部分。

在以下部分了解更多有关 etcd-encryption 策略结构的详细信息:

2.4.9.1. ETCD 加密策略 YAML 结构

etcd-encryption 策略可能类似以下 YAML 文件:

apiVersion: policy.open-cluster-management.io/v1
kind: ConfigurationPolicy
metadata:
  name: policy-etcdencryption
  namespace:
spec:
  complianceType:
  remediationAction:
  namespaces:
    exclude:
    include:
  object-templates:
    - complianceType:
      objectDefinition:
        apiVersion: config.openshift.io/v1
        kind: APIServer
        metadata:
          name: cluster
        spec:
          encryption:
            type:
        ...

2.4.9.2. ETCD 加密策略表

表 2.4. 参数表

字段描述

apiVersion

必需。将值设置为 policy.open-cluster-management.io/v1

kind

必需。将值设为 Policy 以表示策略类型,例如 ConfigurationPolicy

metadata.name

必需。用于标识策略资源的名称。

metadata.namespaces

可选。

spec.namespace

必需。策略应用到的节点集群内命名空间。输入 include 的参数值,这是您要将策略应用到的命名空间。exclude 参数指定您明确不希望将策略应用到的命名空间。:在策略控制器的对象模板中指定的命名空间会覆盖对应父策略中的命名空间。

remediationAction

可选。指定您的策略的修复。参数值是 enforceinform重要:有些策略可能不支持 enforce 功能。

disabled

必需。将值设为 truefalsedisabled 参数提供启用和禁用策略的功能。

spec.complianceType

必需。将值设为 "musthave"

spec.object-template

可选。用于列出必须接受评估或应用到受管集群的任何其他 Kubernetes 对象。如需更多信息,请参阅 OpenShift Container Platform 文档

2.4.9.3. etcd 加密策略示例

apiVersion: policy.open-cluster-management.io/v1
kind: ConfigurationPolicy
metadata:
  name: policy-etcdencryption
  namespace: default
spec:
  complianceType: musthave
  remediationAction: inform
  namespaces:
    exclude: ["kube-*"]
    include: ["default"]
  object-templates:
    - complianceType: musthave
      objectDefinition:
        apiVersion: config.openshift.io/v1
        kind: APIServer
        metadata:
          name: cluster
        spec:
          encryption:
            type: aescbc
        ...

如需更多信息,请参阅管理 ETCD 加密策略。查看由控制器监控的其他配置策略,请参阅 Kubernetes 配置策略控制器页面。

2.4.10. 集成 gatekeeper 约束和约束模板

Gatekeeper 是一个验证 webhook,它强制执行基于 CustomResourceDefinition(CRD)的策略,该策略与 Open Policy Agent(OPA)一起运行。您可以安装 Gatekeeper 来将 gatekeeper 策略与 Red Hat Advanced Cluster Management for Kubernetes 集成。Gatekeeper 策略可用于评估 Kubernetes 资源合规性。您可以使用 OPA 作为策略引擎,并使用 Rego 作为策略语言。

gatekeeper 策略已创建为 Kubernetes 配置策略。Gatekeeper 策略包括约束模板(ConstraintTemplates)和约束、审计模板和准入模板。如需更多信息,请参阅 Gatekeeper

先决条件:

  • 您必须在受管集群上安装 Gatekeeper 才能使用 gatekeeper 策略控制器。如需更多信息,请参阅 open-policy-agent/gatekeeper 存储库。
  • Kubernetes 版本 1.14 或更高版本

Red Hat Advanced Cluster Management 在 Red Hat Advanced Cluster Management gatekeeper 策略中应用以下约束模板:

  • ConstraintTemplates 和约束:使用 policy-gatekeeper-k8srequiredlabels 策略在受管集群上创建 gatekeeper 约束模板。

    apiVersion: policy.open-cluster-management.io/v1
    kind: ConfigurationPolicy
    metadata:
      name: policy-gatekeeper-k8srequiredlabels
    spec:
      remediationAction: enforce # will be overridden by remediationAction in parent policy
      severity: low
      object-templates:
        - complianceType: musthave
          objectDefinition:
            apiVersion: templates.gatekeeper.sh/v1beta1
            kind: ConstraintTemplate
            metadata:
              name: k8srequiredlabels
            spec:
              crd:
                spec:
                  names:
                    kind: K8sRequiredLabels
                  validation:
                    # Schema for the `parameters` field
                    openAPIV3Schema:
                      properties:
                        labels:
                          type: array
                          items: string
              targets:
                - target: admission.k8s.gatekeeper.sh
                  rego: |
                    package k8srequiredlabels
                    violation[{"msg": msg, "details": {"missing_labels": missing}}] {
                      provided := {label | input.review.object.metadata.labels[label]}
                      required := {label | label := input.parameters.labels[_]}
                      missing := required - provided
                      count(missing) > 0
                      msg := sprintf("you must provide labels: %v", [missing])
                    }
        - complianceType: musthave
          objectDefinition:
            apiVersion: constraints.gatekeeper.sh/v1beta1
            kind: K8sRequiredLabels
            metadata:
              name: ns-must-have-gk
            spec:
              match:
                kinds:
                  - apiGroups: [""]
                    kinds: ["Namespace"]
                namespaces:
                  - e2etestsuccess
                  - e2etestfail
              parameters:
                labels: ["gatekeeper"]
  • audit 模板:使用 policy-gatekeeper-audit 定期检查并评估为检测出错误协调而强制执行的 gatekeeper 策略的现有资源。

    apiVersion: policy.open-cluster-management.io/v1
    kind: ConfigurationPolicy
    metadata:
      name: policy-gatekeeper-audit
    spec:
      remediationAction: inform # will be overridden by remediationAction in parent policy
      severity: low
      object-templates:
        - complianceType: musthave
          objectDefinition:
            apiVersion: constraints.gatekeeper.sh/v1beta1
            kind: K8sRequiredLabels
            metadata:
              name: ns-must-have-gk
            status:
              totalViolations: 0
  • 准入 模板:使用 policy-gatekeeper-admission 检查由 gatekeeper admission webhook 创建的错误配置:

    apiVersion: policy.open-cluster-management.io/v1
    kind: ConfigurationPolicy
    metadata:
      name: policy-gatekeeper-admission
    spec:
      remediationAction: inform # will be overridden by remediationAction in parent policy
      severity: low
      object-templates:
        - complianceType: mustnothave
          objectDefinition:
            apiVersion: v1
            kind: Event
            metadata:
              namespace: openshift-gatekeeper-system # set it to the actual namespace where gatekeeper is running if different
              annotations:
                constraint_action: deny
                constraint_kind: K8sRequiredLabels
                constraint_name: ns-must-have-gk
                event_type: violation

如需了解更多详细信息,请参阅 policy-gatekeeper-sample.yaml

了解如何使用 Red Hat Advanced Cluster Management gatekeeper Operator 策略安装 gatekeeper 并创建一个 Red Hat Advanced Cluster Management gatekeeper operator 策略,请参阅 Gatekeeper 策略集成以了解更多详细信息。有关安全框架的更多信息,请参阅监管和风险

2.5. 管理安全策略

使用监管和风险仪表板来创建、查看和管理安全策略和策略违反情况。您可以通过 CLI 和控制台为您的策略创建 YAML 文件。

Governance and risk 页面中,您可以通过按类别或标准过滤违反情况来自定义概述视图,折叠概述以查看较少的信息,您可以搜索策略。您还可以根据策略或集群违反过滤违反表视图。

策略表列出了策略的以下详情:策略名称命名空间Remediation集群违反标准、Catego ries 和 Controls。您可以选择 Actions 图标来编辑、禁用、通知或删除策略。

当您在表列表中选择一个策略时,控制台中会显示以下信息标签页:

  • 详情 :选择 Details 选项卡来查看策略详情、放置详情和 _Policy 模板表列表。
  • status :选择 Status 选项卡来查看违反情况的表列表。您可以根据集群模板过滤您的视图。要查看您的策略的合规状态,请选择 Status 选项卡。点 View history 链接查看违反信息列表。
  • YAML :选择 YAML 选项卡来查看,或使用编辑器编辑您的策略。选择 YAML 切换来查看或隐藏编辑器。

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

更多主题请参阅监管和风险

2.5.1. 管理安全策略

创建一个安全策略,根据您指定的安全标准、类别和控制,报告并验证您的集群合规性。要为 Red Hat Advanced Cluster Management for Kubernetes 创建策略,您必须在受管集群上创建 YAML 文件。

:您可以将现有策略复制到 Policy YAML 中。当您粘贴现有策略时,会自动输入参数字段的值。您还可以使用搜索功能搜索策略 YAML 文件中的内容。

2.5.1.1. 创建安全策略

您可以使用命令行界面 (CLI) 或者从控制台创建安全策略。需要集群管理员访问权限。

重要:您必须定义一个 PlacementPolicy 和 PlacementBinding,才能将您的策略应用到特定的集群。为 Cluster binding 字段输入一个值来定义 PlacementPolicy 和 PlacementBinding。查看 Red Hat Advanced Cluster Management 策略所需的对象定义:

  • PlacementRule:定义必须部署策略 的集群选择器
  • PlacementBinding:将放置绑定到 PlacementPolicy。

策略概述中查看策略 YAML 文件的更多描述。

2.5.1.1.1. 使用命令行界面创建安全策略

完成以下步骤,使用命令行界面 (CLI) 创建策略:

  1. 运行以下命令来创建策略:

    kubectl create -f policy.yaml -n <namespace>
  2. 定义策略使用的模板。要编辑 .yaml 文件,请添加 templates 字段来定义模板。您的策略可能类似以下 YAML 文件:

    apiVersion: policy.open-cluster-management.io/v1
    kind: Policy
    metadata:
      name: policy1
    spec:
      remediationAction: "enforce" # or inform
      disabled: false # or true
      namespaces:
        include: ["default"]
        exclude: ["kube*"]
      policy-templates:
        - objectDefinition:
            apiVersion: policy.open-cluster-management.io/v1
            kind: ConfigurationPolicy
            metadata:
              namespace: kube-system # will be inferred
              name: operator
            spec:
              remediationAction: "inform"
              object-templates:
                complianceType: "musthave" # at this level, it means the role must exist and must have the following rules
                apiVersion: rbac.authorization.k8s.io/v1
                kind: Role
                metadata:
                  name: example
                objectDefinition:
                  rules:
                    - complianceType: "musthave" # at this level, it means if the role exists the rule is a musthave
                      apiGroups: ["extensions", "apps"]
                      resources: ["deployments"]
                      verbs: ["get", "list", "watch", "create", "delete","patch"]
  3. 定义 PlacementRule。务必更改 PlacementRule,以通过 clusterNamesclusterLabels 指定需要应用策略的集群。查看创建和管理放置规则。您 PlacementRule 可能类似如下内容:

    apiVersion: apps.open-cluster-management.io/v1
    kind: PlacementRule
    metadata:
      name: placement1
    spec:
      clusterConditions:
        - type: ManagedClusterConditionAvailable
          status: "True"
      clusterNames:
      - "cluster1"
      - "cluster2"
      clusterLabels:
        matchLabels:
          cloud: IBM
  4. 定义一个 PlacementBinding 来绑定您的策略和 PlacementRule。您 PlacementBinding 可能类似以下 YAML 示例:

    apiVersion: policy.open-cluster-management.io/v1
    kind: PlacementBinding
    metadata:
      name: binding1
    placementRef:
      name: placement1
      apiGroup: apps.open-cluster-management.io
      kind: PlacementRule
    subjects:
    - name: policy1
      apiGroup: policy.mcm.ibm.com
      kind: Policy
2.5.1.1.1.1. 通过 CLI 查看您的安全策略

完成以下步骤,通过 CLI 查看您的安全策略:

  1. 运行以下命令,查看具体安全策略的详情:

    kubectl get securitypolicy <policy-name> -n <namespace> -o yaml
  2. 运行以下命令,查看您的安全策略的描述:

    kubectl describe securitypolicy <name> -n <namespace>
2.5.1.1.2. 从控制台创建集群安全策略

从控制台创建新策略时,也会在 YAML 编辑器中创建 YAML 文件。

  1. 在导航菜单中点击 Govern risk
  2. 要创建策略,请点击 Create policy
  3. 为以下参数输入或选择值:

    • Name
    • Specifications
    • Cluster selector
    • Remediation action
    • Standards
    • Categories
    • Controls
  4. 查看以下 Red Hat Advanced Cluster Management for Kubernetes 安全策略定义示例。复制并粘贴策略的 YAML 文件。

    您的 YAML 文件可能类似以下策略:

     apiVersion: policy.open-cluster-management.io/v1
     kind: Policy
     metadata:
       name: policy-pod
       annotations:
         policy.open-cluster-management.io/categories: 'SystemAndCommunicationsProtections,SystemAndInformationIntegrity'
         policy.open-cluster-management.io/controls: 'control example'
         policy.open-cluster-management.io/standards: 'NIST,HIPAA'
     spec:
       complianceType: musthave
       namespaces:
         exclude: ["kube*"]
         include: ["default"]
       object-templates:
       - complianceType: musthave
         objectDefinition:
           apiVersion: v1
           kind: Pod
           metadata:
             name: nginx1
           spec:
             containers:
             - name: nginx
               image: 'nginx:1.7.9'
               ports:
               - containerPort: 80
       remediationAction: enforce
       disabled: false
    
     ---
     apiVersion: apps.open-cluster-management.io/v1
     kind: PlacementBinding
     metadata:
       name: binding-pod
     placementRef:
       name: placement-pod
       kind: PlacementRule
       apiGroup: apps.open-cluster-management.io
     subjects:
     - name: policy-pod
       kind: Policy
       apiGroup: policy.mcm.ibm.com
    
     ---
     apiVersion: apps.open-cluster-management.io/v1
     kind: PlacementRule
     metadata:
       name: placement-pod
     spec:
       clusterConditions:
         - type: ManagedClusterConditionAvailable
           status: "True"
       clusterLabels:
         matchLabels:
           cloud: "IBM"
  5. 点击 Create Policy

从控制台创建了安全策略。

2.5.1.1.2.1. 从控制台查看您的安全策略

您可以在控制台中查看任何安全策略及其状态。

  1. 从控制台登录到集群。
  2. 在导航菜单中点击 Governance and risk 来查看您的策略的表列表。

    :您可以通过选择 Policies 标签页或 Cluster violations 标签页来过滤策略列表。

  3. 选择一个策略来查看更多详情。Overview 标签页、Status 标签页和 YAML 标签页会显示。

2.5.1.2. 更新安全策略

查看以下部分以了解如何更新安全策略。

2.5.1.2.1. 禁用安全策略

您的策略默认是启用的。您可以通过完成以下步骤禁用您的策略:

  1. 登录您的 Red Hat Advanced Cluster Management for Kubernetes 控制台。
  2. 在导航菜单中点击 Govern risk 来查看您的策略的表列表。
  3. Actions 图标 > Disable policy 来禁用您的策略。此时会出现 Disable Policy 对话框。
  4. 点击 Disable policy

您的策略已禁用。

2.5.1.2.2. 删除安全策略

通过 CLI 或控制台删除安全策略。

  • 通过 CLI 删除安全策略:

    1. 运行以下命令来删除安全策略:
    kubectl delete policy <securitypolicy-name> -n <open-cluster-management-namespace>

    + 删除策略后,它会从目标集群或集群中删除。运行以下命令验证您的策略是否已移除: kubectl get policy <securitypolicy-name> -n <open-cluster-management-namespace>

  • 从控制台删除安全策略:

    1. 在导航菜单中点击 Govern risk 来查看您的策略的表列表。
    2. 在策略违反表中点击您要删除的策略的 Actions 图标。
    3. 点击 Remove
    4. Remove policy 对话框中点击 Remove policy

要管理其他策略,请参阅管理安全策略以了解更多信息。有关策略的更多主题,请参阅监管和风险

2.5.2. 管理配置策略

了解如何创建、应用、查看和更新您的配置策略。

2.5.2.1. 创建配置策略

您可以使用命令行界面 (CLI) 或者从控制台为配置策略创建 YAML 文件。查看以下部分以创建配置策略:

2.5.2.1.1. 通过 CLI 创建配置策略

完成以下步骤,通过 CLI 创建配置策略:

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

    kubectl create -f configpolicy-1.yaml

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

      apiVersion: policy.open-cluster-management.io/v1
      kind: Policy
      metadata:
        name: policy-1
        namespace: kube-system
      spec:
        namespaces:
          include: ["default", "kube-*"]
          exclude: ["kube-system"]
        remediationAction: inform
        disabled: false
        complianceType: musthave
        object-templates:
       ...
  2. 运行以下命令来应用策略:

    kubectl apply -f <policy-file-name>  --namespace=<namespace>
  3. 运行以下命令,验证并列出策略:

    kubectl get policy --namespace=<namespace>

您的配置策略已创建。

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

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

  1. 运行以下命令,查看具体配置策略的详情:

    kubectl get policy <policy-name> -n <namespace> -o yaml
  2. 运行以下命令,查看您的配置策略的描述:

    kubectl describe policy <name> -n <namespace>
2.5.2.1.2. 从控制台创建配置策略

从控制台创建配置策略时,也会在 YAML 编辑器中创建 YAML 文件。完成以下步骤,从控制台创建配置策略:

  1. 从控制台登录到集群。
  2. 在导航菜单中点击 Governance and risk
  3. 点击 Create policy
  4. 通过为规格参数选择一个配置策略来指定您要创建的策略。继续为以下字段输入或选择适当的值:

    • Name
    • Specifications
    • Cluster selector
    • Remediation action
    • Standards
    • Categories
    • Controls
  5. 点击 Create
2.5.2.1.2.1. 从控制台查看您的配置策略

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

  1. 从控制台登录到集群。
  2. 在导航菜单中点击 Govern risk 来查看您的策略的表列表。

    :您可以选择 All policies 选项卡或者 Cluster violations 选项卡来过滤您的策略表列表。

  3. 选择一个策略来查看更多详情。Overview 标签页、Status 标签页和 YAML 标签页会显示。

2.5.2.2. 更新配置策略

查看以下部分以了解如何更新配置策略。

2.5.2.2.1. 禁用配置策略

完成以下步骤以禁用您的配置策略:

  1. 登录您的 Red Hat Advanced Cluster Management for Kubernetes 控制台。
  2. 在导航菜单中点击 Govern risk 来查看您的策略的表列表。
  3. Actions 图标 > Disable 来禁用您的策略。此时会出现 Disable Policy 对话框。
  4. 点击 Disable policy

您的策略已禁用。

2.5.2.3. 删除配置策略

通过 CLI 或控制台删除配置策略。

  • 通过 CLI 删除配置策略:

    1. 运行以下命令来删除配置策略:

        kubectl delete policy <policy-name> -n <mcm namespace>

      删除策略后,它会从一个或多个目标集群中移除。

    2. 运行以下命令验证您的策略是否已移除:
      kubectl get policy <policy-name> -n <mcm namespace>
  • 通过控制台删除配置策略:

    1. 在导航菜单中点击 Govern risk 来查看您的策略的表列表。
    2. 在策略违反表中点击您要删除的策略的 Actions 图标。
    3. 点击 Remove
    4. Remove policy 对话框中点击 Remove policy

您的策略已删除。

查看配置策略示例,请参阅策略示例。请参阅管理安全策略以管理其他策略。

2.5.3. 管理镜像漏洞策略

配置策略控制器负责监控镜像漏洞策略的状态。应用镜像漏洞策略可检查容器是否有漏洞。了解如何创建、应用、查看和更新您的镜像漏洞策略。

2.5.3.1. 创建镜像漏洞策略

您可以使用命令行界面 (CLI) 或者从控制台为镜像漏洞策略创建 YAML。查看以下部分以创建镜像漏洞策略:

2.5.3.1.1. 通过 CLI 创建镜像漏洞策略

完成以下步骤,通过 CLI 创建镜像漏洞策略:

  1. 运行以下命令,为您的镜像漏洞策略创建 YAML 文件:

    kubectl create -f imagevulnpolicy-1.yaml
  2. 运行以下命令来应用策略:

    kubectl apply -f <imagevuln-policy-file-name>  --namespace=<namespace>
  3. 运行以下命令,列出并验证策略:

    kubectl get imagevulnpolicy --namespace=<namespace>

您的镜像漏洞策略已创建。

2.5.3.1.1.1. 通过 CLI 查看您的镜像漏洞策略

完成以下步骤,通过 CLI 查看您的镜像漏洞策略:

  1. 运行以下命令,查看具体镜像漏洞策略的详情:

    kubectl get imagevulnpolicy <policy-name> -n <namespace> -o yaml
  2. 运行以下命令,查看您的镜像漏洞策略的描述:

    kubectl describe imagevulnpolicy <name> -n <namespace>

2.5.3.2. 从控制台创建镜像漏洞策略

从控制台创建镜像漏洞策略时,也会在 YAML 编辑器中创建 YAML 文件。完成以下步骤,从控制台创建镜像漏洞策略:

  1. 从控制台登录到集群。
  2. 在导航菜单中点击 Governance and risk
  3. 点击 Create policy
  4. Specifications 字段中选择 ImageManifestVulnPolicy。参数值会自动设置。您可以编辑值。
  5. 点击 Create

镜像漏洞策略已创建。

2.5.3.3. 从控制台查看镜像漏洞违反情况

  1. 在导航菜单中点击 Govern risk 来查看您的策略的表列表。
  2. 选择 policy-imagemanifestvulnpolicy > Status 来查看违反策略的集群位置。

    您的镜像安全漏洞违反情况可能类似如下:

    imagemanifestvulns exist and should be deleted: [sha256.7ac7819e1523911399b798309025935a9968b277d86d50e5255465d6592c0266] in namespace default; [sha256.4109631e69d1d562f014dd49d5166f1c18b4093f4f311275236b94b21c0041c0] in namespace calamari; [sha256.573e9e0a1198da4e29eb9a8d7757f7afb7ad085b0771bc6aa03ef96dedc5b743, sha256.a56d40244a544693ae18178a0be8af76602b89abe146a43613eaeac84a27494e, sha256.b25126b194016e84c04a64a0ad5094a90555d70b4761d38525e4aed21d372820] in namespace open-cluster-management-agent-addon; [sha256.64320fbf95d968fc6b9863581a92d373bc75f563a13ae1c727af37450579f61a] in namespace openshift-cluster-version
  3. 选择 Cluster 链接以导航到 OpenShift Container Platform 控制台。
  4. 在 OpenShift Container Platform 控制台的导航菜单中点击 Administration = > Custom Resource Definitions
  5. 选择 imagemanifestvulns > Instances 选项卡来查看所有 imagemanifestvulns 实例。
  6. 选择一个条目来查看更多详情。

2.5.3.4. 更新镜像漏洞策略

查看以下部分以了解如何更新镜像漏洞策略。

2.5.3.4.1. 禁用镜像漏洞策略

完成以下步骤以禁用您的镜像漏洞策略:

  1. 登录您的 Red Hat Advanced Cluster Management for Kubernetes 控制台。
  2. 在导航菜单中点击 Govern risk 来查看您的策略的表列表。
  3. Actions 图标 > Disable 来禁用您的策略。此时会出现 Disable Policy 对话框。
  4. 点击 Disable policy

您的策略已禁用。

2.5.3.4.2. 删除镜像漏洞策略

通过 CLI 或控制台删除镜像漏洞策略。

  • 通过 CLI 删除镜像漏洞策略:

    1. 运行以下命令来删除证书策略:

       kubectl delete policy <imagevulnpolicy-name> -n <mcm namespace>

      删除策略后,它会从一个或多个目标集群中移除。

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

       kubectl get policy <imagevulnpolicy-name> -n <mcm namespace>
  • 从控制台删除镜像漏洞策略:

    1. 在导航菜单中点击 Govern risk 来查看您的策略的表列表。
    2. 在策略违反表中点击您要删除的策略的 Actions 图标。
    3. 点击 Remove
    4. Remove policy 对话框中点击 Remove policy

您的镜像漏洞策略已删除。

查看镜像漏洞策略示例,请参阅镜像漏洞策略页面中的镜像漏洞策略示例。请参阅 Kubernetes 配置策略控制器,以了解由 Kubernetes 配置策略控制器监控的其他策略。请参阅管理安全策略以管理其他策略。

2.5.4. 管理内存用量策略

应用内存用量策略来限制或约束您的内存和计算用量。在以下部分中了解如何创建、应用、查看和更新您的内存用量策略。

2.5.4.1. 创建内存用量策略

您可以使用命令行界面 (CLI) 或者从控制台为内存用量策略创建 YAML 文件。查看以下部分以创建内存用量策略:

2.5.4.1.1. 通过 CLI 创建内存用量策略

完成以下步骤,通过 CLI 创建内存用量策略:

  1. 运行以下命令,为您的内存用量策略创建 YAML 文件:

    kubectl create -f memorypolicy-1.yaml
  2. 运行以下命令来应用策略:

    kubectl apply -f <memory-policy-file-name>  --namespace=<namespace>
  3. 运行以下命令,列出并验证策略:

    kubectl get memorypolicy --namespace=<namespace>

通过 CLI 创建了您的内存用量策略。

2.5.4.1.1.1. 通过 CLI 查看您的策略

完成以下步骤,通过 CLI 查看您的内存用量策略:

  1. 运行以下命令,查看具体内存用量策略的详情:

    kubectl get memorypolicy <policy-name> -n <namespace> -o yaml
  2. 运行以下命令,查看您的内存用量策略的描述:

    kubectl describe memorypolicy <name> -n <namespace>
2.5.4.1.2. 从控制台创建内存用量策略

从控制台创建内存用量策略时,也会在 YAML 编辑器中创建 YAML 文件。完成以下步骤,从控制台创建内存用量策略:

  1. 登录您的 Red Hat Advanced Cluster Management for Kubernetes 控制台。
  2. 在导航菜单中点击 Governance and risk
  3. 点击 Create policy
  4. Specifications 字段中选择 Limitrange。参数值会自动设置。您可以编辑值。
  5. 点击 Create
2.5.4.1.2.1. 从控制台查看您的内存用量策略

您可以在控制台中查看任何内存用量策略及其状态。

  1. 从控制台登录到集群。
  2. 在导航菜单中点击 Govern risk 来查看您的策略的表列表。

    :您可以通过选择 Policies 标签页或 Cluster violations 标签页来过滤策略列表。

  3. 选择一个策略来查看更多详情。
  4. 选择 Status 选项卡来查看策略违反情况。

2.5.4.2. 更新内存用量策略

查看以下部分以了解如何更新内存用量策略。

2.5.4.2.1. 禁用内存用量策略

完成以下步骤以禁用您的内存用量策略:

  1. 登录您的 Red Hat Advanced Cluster Management for Kubernetes 控制台。
  2. 在导航菜单中点击 Govern risk 来查看您的策略的表列表。
  3. Actions 图标 > Disable 来禁用您的策略。此时会出现 Disable Policy 对话框。
  4. 点击 Disable policy

您的策略已禁用。

2.5.4.2.2. 删除内存用量策略

通过 CLI 或控制台删除内存用量策略。

  • 通过 CLI 删除内存用量策略:

    1. 运行以下命令来删除内存用量策略:

       kubectl delete policy <memorypolicy-name> -n <mcm namespace>

      删除策略后,它会从一个或多个目标集群中移除。

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

       kubectl get policy <memorypolicy-name> -n <mcm namespace>
  • 从控制台删除内存用量策略:

    1. 在导航菜单中点击 Govern risk 来查看您的策略的表列表。
    2. 在策略违反表中点击您要删除的策略的 Actions 图标。
    3. 点击 Remove
    4. Remove policy 对话框中点击 Remove policy

您的内存用量策略已删除。

查看内存用量策略示例,请参阅内存用量策略页面中的内存用量策略示例。请参阅 Kubernetes 配置策略控制器以了解其他配置策略。请参阅管理安全策略以管理其他策略。

2.5.5. 管理命名空间策略

应用命名空间策略可为您的命名空间定义特定规则。在以下部分中了解如何创建、应用、查看和更新您的内存用量策略。

2.5.5.1. 创建命名空间策略

您可以使用命令行界面 (CLI) 或者从控制台为命名空间策略创建 YAML 文件。查看以下部分以创建命名空间策略:

2.5.5.1.1. 通过 CLI 创建命名空间策略

完成以下步骤,通过 CLI 创建命名空间策略:

  1. 运行以下命令,为您的命名空间策略创建 YAML 文件:

    kubectl create -f namespacepolicy-1.yaml
  2. 运行以下命令来应用策略:

    kubectl apply -f <namespace-policy-file-name>  --namespace=<namespace>
  3. 运行以下命令,列出并验证策略:

    kubectl get namespacepolicy --namespace=<namespace>

通过 CLI 创建了您的命名空间策略。

2.5.5.1.1.1. 通过 CLI 查看您的命名空间策略

完成以下步骤,通过 CLI 查看您的命名空间策略:

  1. 运行以下命令,查看具体命名空间策略的详情:

    kubectl get namespacepolicy <policy-name> -n <namespace> -o yaml
  2. 运行以下命令,查看您的命名空间策略的描述:

    kubectl describe namespacepolicy <name> -n <namespace>
2.5.5.1.2. 从控制台创建命名空间策略

从控制台创建命名空间策略时,也会在 YAML 编辑器中创建 YAML 文件。完成以下步骤,从控制台创建命名空间策略:

  1. 登录您的 Red Hat Advanced Cluster Management for Kubernetes 控制台。
  2. 在导航菜单中点击 Governance and risk
  3. 点击 Create policy
  4. Specifications 字段中选择 Namespace。参数值会自动设置。您可以编辑值。
  5. 点击 Create
2.5.5.1.2.1. 从控制台查看您的命名空间策略

您可在控制台中查看任何命名空间策略及其状态。

  1. 从控制台登录到集群。
  2. 在导航菜单中点击 Governance and risk 来查看您的策略的表列表。

    备注:您可以通过选择 Policies 标签页或 Cluster violations 标签页来过滤策略列表。

  3. 选择一个策略来查看更多详情。
  4. 选择 Status 选项卡来查看策略违反情况。

2.5.5.2. 更新命名空间策略

查看以下部分以了解如何更新命名空间策略。

2.5.5.2.1. 禁用命名空间策略

完成以下步骤以禁用您的命名空间策略:

  1. 登录您的 Red Hat Advanced Cluster Management for Kubernetes 控制台。
  2. 在导航菜单中点击 Govern risk 来查看您的策略的表列表。
  3. Actions 图标 > Disable 来禁用您的策略。此时会出现 Disable Policy 对话框。
  4. 点击 Disable policy

您的策略已禁用。

2.5.5.2.2. 删除命名空间策略

通过 CLI 或控制台删除命名空间策略。

  • 通过 CLI 删除命名空间策略:

    1. 运行以下命令来删除命名空间策略:

       kubectl delete policy <memorypolicy-name> -n <mcm namespace>

      删除策略后,它会从一个或多个目标集群中移除。

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

       kubectl get policy <memorypolicy-name> -n <mcm namespace>
  • 从控制台删除命名空间策略:

    1. 在导航菜单中点击 Govern risk 来查看您的策略的表列表。
    2. 在策略违反表中点击您要删除的策略的 Actions 图标。
    3. 点击 Remove
    4. Remove policy 对话框中点击 Remove policy

您的命名空间策略已删除。

查看命名空间策略示例,请参阅命名空间策略页面上的命名空间策略示例。请参阅 Kubernetes 配置策略控制器以了解其他配置策略。请参阅管理安全策略以管理其他策略。

2.5.6. 管理 Pod nginx 策略

Kubernetes 配置策略控制器负责监控 Pod nginx 策略的状态。应用 Pod nginx 策略可为您的 Pod 定义容器规则。了解如何创建、应用、查看和更新您的 Pod nginx 策略。

2.5.6.1. 创建 Pod nginx 策略

您可以从命令行界面 (CLI) 或者从控制台为 Pod nginx 策略创建 YAML。查看以下部分以创建 Pod nginx 策略:

2.5.6.1.1. 通过 CLI 创建 Pod nginx 策略

完成以下步骤,通过 CLI 创建 Pod nginx 策略:

  1. 运行以下命令,为您的 Pod nginx 策略创建 YAML 文件:

    kubectl create -f podnginxpolicy-1.yaml
  2. 运行以下命令来应用策略:

    kubectl apply -f <podnginx-policy-file-name>  --namespace=<namespace>
  3. 运行以下命令,列出并验证策略:

    kubectl get podnginxpolicy --namespace=<namespace>

通过 CLI 创建了您的镜像 Pod nginx 策略。

2.5.6.1.1.1. 通过 CLI 查看您的 nginx 策略

完成以下步骤,通过 CLI 查看您的 Pod nginx 策略:

  1. 运行以下命令,查看具体 Pod nginx 策略的详情:

    kubectl get podnginxpolicy <policy-name> -n <namespace> -o yaml
  2. 运行以下命令,查看您的 Pod nginx 策略的描述:

    kubectl describe podnginxpolicy <name> -n <namespace>

2.5.6.2. 从控制台创建 Pod nginx 策略

从控制台创建 Pod nginx 策略时,也会在 YAML 编辑器中创建 YAML 文件。完成以下步骤,从控制台创建 Pod nginx 策略:

  1. 登录您的 Red Hat Advanced Cluster Management for Kubernetes 控制台。
  2. 在导航菜单中点击 Govern risk
  3. 点击 Create policy
  4. Specifications 字段中选择 Pod。参数值会自动设置。您可以编辑值。
  5. 点击 Create
从控制台查看您的 Pod nginx 策略

您可以在控制台中查看任何 Pod nginx 策略及其状态。

  1. 从控制台登录到集群。
  2. 在导航菜单中点击 Govern risk 来查看您的策略的表列表。

    备注:您可以通过选择 Policies 标签页或 Cluster violations 标签页来过滤策略列表。

  3. 选择一个策略来查看更多详情。
  4. 选择 Status 选项卡来查看策略违反情况。

2.5.6.3. 更新 Pod nginx 策略

查看以下部分以了解如何更新 Pod nginx 策略。

2.5.6.3.1. 禁用 Pod nginx 策略

完成以下步骤以禁用 Pod nginx 策略:

  1. 登录您的 Red Hat Advanced Cluster Management for Kubernetes 控制台。
  2. 在导航菜单中点击 Govern risk 来查看您的策略的表列表。
  3. Actions 图标 > Disable 来禁用您的策略。此时会出现 Disable Policy 对话框。
  4. 点击 Disable policy

您的策略已禁用。

2.5.6.3.2. 删除 Pod nginx 策略

通过 CLI 或控制台删除 Pod nginx 策略。

  • 通过 CLI 删除 Pod nginx 策略:

    1. 运行以下命令来删除 Pod nginx 策略:

      kubectl delete policy <podnginxpolicy-name> -n <namespace>

      删除策略后,它会从一个或多个目标集群中移除。

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

      kubectl get policy <podnginxpolicy-name> -n <namespace>
  • 从控制台删除 Pod nginx 策略:

    1. 在导航菜单中点击 Govern risk 来查看您的策略的表列表。
    2. 在策略违反表中点击您要删除的策略的 Actions 图标。
    3. 点击 Remove
    4. Remove policy 对话框中点击 Remove policy

您的 Pod nginx 策略已删除。

查看 Pod nginx 策略示例,请参阅 Pod nginx 策略页面中的 Pod nginx 策略示例。请参阅 Kubernetes 配置策略控制器以了解其他配置策略。请参阅管理安全策略以管理其他策略。

2.5.7. 管理 Pod 安全策略

应用 Pod 安全策略来保护 Pod 和容器。在以下部分中了解如何创建、应用、查看和更新您的 Pod 安全策略。

2.5.7.1. 创建 Pod 安全策略

您可以使用命令行界面 (CLI) 或者从控制台为 Pod 安全策略创建 YAML 文件。查看以下部分以创建 Pod 安全策略:

2.5.7.1.1. 通过 CLI 创建 Pod 安全策略

完成以下步骤,通过 CLI 创建 Pod 安全策略:

  1. 运行以下命令,为您的 Pod 安全策略创建 YAML 文件:

    kubectl create -f podsecuritypolicy-1.yaml
  2. 运行以下命令来应用策略:

    kubectl apply -f <podsecurity-policy-file-name>  --namespace=<namespace>
  3. 运行以下命令,列出并验证策略:

    kubectl get podsecuritypolicy --namespace=<namespace>

通过 CLI 创建了您的 Pod 安全策略。

2.5.7.1.1.1. 通过 CLI 查看您的 Pod 安全策略

完成以下步骤,通过 CLI 查看您的 Pod 安全策略:

  1. 运行以下命令,查看具体 Pod 安全策略的详情:

    kubectl get podsecuritypolicy <policy-name> -n <namespace> -o yaml
  2. 运行以下命令,查看您的 Pod 安全策略的描述:

    kubectl describe podsecuritypolicy <name> -n <namespace>
2.5.7.1.2. 从控制台创建 Pod 安全策略

从控制台创建 Pod 安全策略时,也会在 YAML 编辑器中创建 YAML 文件。完成以下步骤,从控制台创建 Pod 安全策略:

  1. 登录您的 Red Hat Advanced Cluster Management for Kubernetes 控制台。
  2. 在导航菜单中点击 Govern risk
  3. 点击 Create policy
  4. Specifications 字段中选择 Podsecuritypolicy。参数值会自动设置。您可以编辑值。
  5. 点击 Create
2.5.7.1.2.1. 从控制台查看您的 Pod 安全策略

您可以在控制台中查看任何 Pod 安全策略及其状态。

  1. 从控制台登录到集群。
  2. 在导航菜单中点击 Govern risk 来查看您的策略的表列表。

    :您可以通过选择 Policies 标签页或 Cluster violations 标签页来过滤策略列表。

  3. 选择一个策略来查看更多详情。
  4. 选择 Status 选项卡来查看策略违反情况。

2.5.7.2. 更新 Pod 安全策略

查看以下部分以了解如何更新 Pod 安全策略。

2.5.7.2.1. 禁用 Pod 安全策略

完成以下步骤以禁用您的 Pod 安全策略:

  1. 登录您的 Red Hat Advanced Cluster Management for Kubernetes 控制台。
  2. 在导航菜单中点击 Govern risk 来查看您的策略的表列表。
  3. Actions 图标 > Disable 来禁用您的策略。此时会出现 Disable Policy 对话框。
  4. 点击 Disable policy

您的策略已禁用。

2.5.7.2.2. 删除 Pod 安全策略

通过 CLI 或控制台删除 Pod 安全策略。

  • 通过 CLI 删除 Pod 安全策略:

    1. 运行以下命令来删除 Pod 安全策略:

       kubectl delete policy <podsecurity-policy-name> -n <mcm namespace>

      删除策略后,它会从一个或多个目标集群中移除。

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

       kubectl get policy <podsecurity-policy-name> -n <mcm namespace>
  • 从控制台删除 Pod 安全策略:

    1. 在导航菜单中点击 Govern risk 来查看您的策略的表列表。
    2. 在策略违反表中点击您要删除的策略的 Actions 图标。
    3. 点击 Remove
    4. Remove policy 对话框中点击 Remove policy

您的 Pod 安全策略已删除。

查看 Pod 安全策略示例,请参阅 Pod 安全策略页面上的 Pod 安全策略示例。请参阅 Kubernetes 配置策略控制器以了解其他配置策略。请参阅管理安全策略以管理其他策略。

2.5.8. 管理角色策略

Kubernetes 配置策略控制器负责监控角色策略的状态。应用角色策略来为集群中的特定角色设置规则和权限。在以下部分中了解如何创建、应用、查看和更新您的角色策略。

2.5.8.1. 创建角色策略

您可以使用命令行界面 (CLI) 或者从控制台为角色策略创建 YAML 文件。查看以下部分以创建角色策略:

2.5.8.1.1. 通过 CLI 创建角色策略

完成以下步骤,通过 CLI 创建角色:

  1. 运行以下命令,为您的角色策略创建 YAML 文件:

    kubectl create -f rolepolicy-1.yaml
  2. 运行以下命令来应用策略:

    kubectl apply -f <role-policy-file-name>  --namespace=<namespace>
  3. 运行以下命令,列出并验证策略:

    kubectl get rolepolicy --namespace=<namespace>

通过 CLI 创建了您的角色策略。

2.5.8.1.1.1. 通过 CLI 查看您的角色策略

完成以下步骤,通过 CLI 查看您的角色策略:

  1. 运行以下命令,查看具体角色策略的详情:

    kubectl get rolepolicy <policy-name> -n <namespace> -o yaml
  2. 运行以下命令,查看您的角色策略的描述:

    kubectl describe rolepolicy <name> -n <namespace>
2.5.8.1.2. 从控制台创建角色策略

从控制台创建角色策略时,也会在 YAML 编辑器中创建 YAML 文件。完成以下步骤,从控制台创建角色策略:

  1. 登录您的 Red Hat Advanced Cluster Management for Kubernetes 控制台。
  2. 在导航菜单中点击 Govern risk
  3. 点击 Create policy
  4. Specifications 字段中选择 Role。参数值会自动设置。您可以编辑值。
  5. 点击 Create
2.5.8.1.2.1. 从控制台查看您的角色策略

您可以在控制台中查看任何角色策略及其状态。

  1. 从控制台登录到集群。
  2. 在导航菜单中点击 Govern risk 来查看您的策略的表列表。

    备注:您可以通过选择 Policies 标签页或 Cluster violations 标签页来过滤策略列表。

  3. 选择一个策略来查看更多详情。
  4. 选择 Status 选项卡来查看策略违反情况。

2.5.8.2. 更新角色策略

查看以下部分以了解如何更新角色策略。

2.5.8.2.1. 禁用角色策略

完成以下步骤以禁用您的角色策略:

  1. 登录您的 Red Hat Advanced Cluster Management for Kubernetes 控制台。
  2. 在导航菜单中点击 Govern risk 来查看您的策略的表列表。
  3. Actions 图标 > Disable 来禁用您的策略。此时会出现 Disable Policy 对话框。
  4. 点击 Disable policy

您的策略已禁用。

2.5.8.2.2. 删除角色策略

通过 CLI 或控制台删除角色策略。

  • 通过 CLI 删除角色策略:

    1. 运行以下命令来删除角色策略:

       kubectl delete policy <podsecurity-policy-name> -n <mcm namespace>

      删除策略后,它会从一个或多个目标集群中移除。

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

       kubectl get policy <podsecurity-policy-name> -n <mcm namespace>
  • 从控制台删除角色策略:

    1. 在导航菜单中点击 Govern risk 来查看您的策略的表列表。
    2. 在策略违反表中点击您要删除的策略的 Actions 图标。
    3. 点击 Remove
    4. Remove policy 对话框中点击 Remove policy

您的角色策略已删除。

查看角色策略示例,请参阅角色策略页面上的角色策略示例。请参阅 Kubernetes 配置策略控制器以了解其他配置策略。请参阅管理安全策略以管理其他策略。

2.5.9. 管理 rolebinding 策略

了解如何创建、应用、查看和更新 rolebinding 策略。

2.5.9.1. 创建 rolebinding 策略

您可以使用命令行界面 (CLI) 或者从控制台为 rolebinding 策略创建 YAML 文件。查看以下部分以创建 rolebinding 策略:

2.5.9.1.1. 通过 CLI 创建 rolebinding 策略

完成以下步骤,通过 CLI 创建 rolebinding 策略:

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

    kubectl create -f rolebindingpolicy.yaml
  2. 运行以下命令来应用策略:

    kubectl apply -f <rolebinding-policy-file-name>  --namespace=<namespace>
  3. 运行以下命令,验证并列出策略:

    kubectl get rolebindingpolicy --namespace=<namespace>

您的 rolebinding 策略已创建。

2.5.9.1.1.1. 通过 CLI 查看您的 rolebinding 策略

完成以下步骤,通过 CLI 查看您的 rolebinding 策略:

  1. 运行以下命令,查看具体 rolebinding 策略的详情:

    kubectl get rolebindingpolicy <policy-name> -n <namespace> -o yaml
  2. 运行以下命令,查看您的 rolebinding 策略的描述:

    kubectl describe rolebindingpolicy <name> -n <namespace>
2.5.9.1.2. 从控制台创建 rolebinding 策略

从控制台创建 rolebinding 策略时,也会在 YAML 编辑器中创建 YAML 文件。完成以下步骤,从控制台创建 rolebinding 策略:

  1. 从控制台登录到集群。
  2. 在导航菜单中点击 Governance and risk
  3. 点击 Create policy
  4. 为以下字段输入或选择适当的值:

    • Name
    • Specifications
    • Cluster selector
    • Remediation action
    • Standards
    • Categories
    • Controls
    • Disabled
  5. 点击 Create

已创建一个 rolebinding 策略。

2.5.9.1.2.1. 从控制台查看您的 rolebinding 策略

您可以在控制台中查看任何 rolebinding 策略及其状态。

  1. 从控制台登录到集群。
  2. 在导航菜单中点击 Governance and risk 来查看您的策略的表列表。

    备注:您可以通过选择 Policies 标签页或 Cluster violations 标签页来过滤策略列表。

  3. 选择一个策略来查看更多详情。
  4. 选择 Status 选项卡来查看 rolebinding 策略违反情况。

2.5.9.2. 更新 rolebinding 策略

查看以下部分以了解如何更新 rolebinding 策略。

2.5.9.2.1. 禁用 rolebinding 策略

完成以下步骤以禁用 rolebinding 策略:

  1. 登录您的 Red Hat Advanced Cluster Management for Kubernetes 控制台。
  2. 在导航菜单中点击 Govern risk 来查看您的策略的表列表。
  3. Actions 图标 > Disable 来禁用您的策略。此时会出现 Disable Policy 对话框。
  4. 点击 Disable policy

您的策略已禁用。

2.5.9.2.2. 删除 rolebinding 策略

通过 CLI 或控制台删除 rolebinding 策略。

  • 通过 CLI 删除 rolebinding 策略:

    1. 运行以下命令来删除 rolebinding 策略:

       kubectl delete policy <podsecurity-policy-name> -n <namespace>

      删除策略后,它会从一个或多个目标集群中移除。

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

       kubectl get policy <podsecurity-policy-name> -n <namespace>
  • 从控制台删除 rolebinding 策略:

    1. 在导航菜单中点击 Govern risk 来查看您的策略的表列表。
    2. 在策略违反表中点击您要删除的策略的 Actions 图标。
    3. 点击 Remove
    4. Remove policy 对话框中点击 Remove policy

您的 rolebinding 策略已删除。

查看 rolebinding 策略示例,请参阅 rolebinding 策略页面上的 rolebinding 策略示例。请参阅 Kubernetes 配置策略控制器以了解其他配置策略。请参阅管理安全策略以管理其他策略。

2.5.10. 管理安全性上下文约束策略

了解如何创建、应用、查看和更新安全性上下文约束 (SCC) 策略。

2.5.10.1. 创建 SCC 策略

您可以使用命令行界面 (CLI) 或者从控制台为 SCC 策略创建 YAML 文件。查看以下部分以创建 SCC 策略:

2.5.10.1.1. 通过 CLI 创建 SCC 策略

如需了解更多详细信息,请参阅 OpenShift Container Platform 文档中的创建安全性上下文约束

2.5.10.1.1.1. 通过 CLI 查看您的 SCC 策略

如需了解更多详细信息,请参阅 OpenShift Container Platform 文档中的检查 SCC

2.5.10.1.2. 从控制台创建 SCC 策略

从控制台创建 SCC 策略时,也会在 YAML 编辑器中创建 YAML 文件。完成以下步骤,从控制台创建 SCC 策略:

  1. 从控制台登录到集群。
  2. 在导航菜单中点击 Governance and risk
  3. 点击 Create policy
  4. 为以下字段输入或选择适当的值:

    • Name
    • Specifications
    • Cluster selector
    • Remediation action
    • Standards
    • Categories
    • Controls
    • Disabled
  5. Create

已创建一个 SCC 策略。

2.5.10.1.2.1. 从控制台查看 SCC 策略

您可以在控制台中查看任何 SCC 策略及其状态。

  1. 从控制台登录到集群。
  2. 在导航菜单中点击 Governance and risk 来查看您的策略的表列表。

    备注:您可以通过选择 Policies 标签页或 Cluster violations 标签页来过滤策略列表。

  3. 选择一个策略来查看更多详情。
  4. 选择 Status 选项卡来查看 SCC 策略违反情况。

2.5.10.2. 更新 SCC 策略

查看以下部分以了解如何更新 SCC 策略。

2.5.10.2.1. 禁用 SCC 策略

完成以下步骤以禁用您的 SCC 策略:

  1. 登录您的 Red Hat Advanced Cluster Management for Kubernetes 控制台。
  2. 在导航菜单中点击 Govern risk 来查看您的策略的表列表。
  3. Actions 图标 > Disable 来禁用您的策略。此时会出现 Disable Policy 对话框。
  4. 点击 Disable policy

您的策略已禁用。

2.5.10.2.2. 删除 SCC 策略

通过 CLI 或控制台删除 SCC 策略。

请参阅 OpenShift Container Platform 文档中的删除 SCC,以了解有关通过 CLI 删除 SCC 策略的更多信息。

  • 从控制台删除 SCC 策略:

    1. 在导航菜单中点击 Govern risk 来查看您的策略的表列表。
    2. 在策略违反表中点击您要删除的策略的 Actions 图标。
    3. 点击 Remove
    4. Remove policy 对话框中点击 Remove policy

您的 SCC 策略已删除。

要查看 SCC 策略示例,请参阅安全性上下文约束策略安全性上下文约束策略示例部分。如需了解其他配置策略,请参阅 Kubernetes 配置策略控制器。请参阅管理安全策略以管理其他策略。

2.5.11. 管理证书策略

了解如何创建、应用、查看和更新您的证书策略。

2.5.11.1. 创建证书策略

您可以使用命令行界面 (CLI) 或者从控制台为证书策略创建 YAML 文件。查看以下部分以创建证书策略:

2.5.11.1.1. 通过 CLI 创建证书策略

完成以下步骤,通过 CLI 创建证书策略:

  1. 为您的证书策略创建一个 YAML 文件。运行以下命令:

    kubectl create -f policy-1.yaml
  2. 运行以下命令来应用策略:

    kubectl apply -f <certificate-policy-file-name>  --namespace=<namespace>
  3. 运行以下命令,验证并列出策略:

    kubectl get certificatepolicy --namespace=<namespace>

您的证书策略已创建。

2.5.11.1.1.1. 通过 CLI 查看您的证书策略

完成以下步骤,通过 CLI 查看您的证书策略:

  1. 运行以下命令,查看具体证书策略的详情:

    kubectl get certificatepolicy <policy-name> -n <namespace> -o yaml
  2. 运行以下命令,查看您的证书策略的描述:

    kubectl describe certificatepolicy <name> -n <namespace>
2.5.11.1.2. 从控制台创建证书策略

从控制台创建证书策略时,也会在 YAML 编辑器中创建 YAML 文件。完成以下步骤,从控制台创建证书策略:

  1. 从控制台登录到集群。
  2. 在导航菜单中点击 Governance and risk
  3. 点击 Create policy
  4. Specifications 参数选择 CertificatePolicy。选择策略时会自动设置其余参数的值。您可以编辑值。
  5. 点击 Create

已创建一个证书策略。

2.5.11.1.2.1. 从控制台查看您的证书策略

您可以在控制台中查看任何证书策略及其状态。

  1. 从控制台登录到集群。
  2. 在导航菜单中点击 Govern risk 来查看您的策略的表列表。

    :您可以通过选择 Policies 标签页或 Cluster violations 标签页来过滤策略列表。

  3. 选择一个策略来查看更多详情。此时会显示 Details 选项卡、Status 选项卡和 YAML 标签页。
  4. 要查看您的策略的合规状态,请选择 Status 选项卡。点 View history 链接查看违反信息列表。

2.5.11.2. 更新证书策略

2.5.11.2.1. 自带证书

您可以使用证书策略控制器来监控您自己的证书。您必须完成以下一项要求来监控您自己的证书:

  • 为您的证书创建 Kubernetes TLS Secret。
  • 将标签 certificate_key_name 添加到您的 Kubernetes secret 中以监控您的证书。

运行以下命令,创建一个 Kubernetes TLS secret 来监控您自己的证书:

kubectl -n <namespace> create secret tls <secret name> --cert=<path to certificate>/<certificate name> --key=<path to key>/<key name>
2.5.11.2.2. 添加一个标签到您的 Kubernetes secret 中

通过添加 certificate_key_name 标签来更新 TLS Secret 中的 metadata 参数。运行以下命令来添加 certificate_key_name 标签:

  kubectl label secret my-certificate -n default certificate_key_name=cert

更新后的 TLS Secret 可能类似以下内容:

   apiVersion: policy.open-cluster-management.io/v1
   kind: Secret
   metadata:
     name: my-certificate
     namespace: default
     labels:
       certificate_key_name: cert
   type: Opaque
   data:
     cert: <Certificate Data>
     key: <Private Key Data>

备注:从控制台添加标签时,您必须手动将该标签添加到 TLS Secret YAML 文件中。

2.5.11.2.3. 禁用证书策略

创建证书策略时,该策略默认是启用的。完成以下步骤,通过 CLI 或控制台禁用证书策略:

  • 从控制台禁用证书策略:

    1. 登录您的 Red Hat Advanced Cluster Management for Kubernetes 控制台。
    2. 在导航菜单中点击 Govern risk 来查看您的策略的表列表。
    3. Actions 图标 > Disable 来禁用您的策略。此时会出现 Disable Policy 对话框。
    4. 点击 Disable policy

您的策略已禁用。

2.5.11.2.4. 删除证书策略

通过 CLI 或控制台删除证书策略。

  • 通过 CLI 删除证书策略:

    1. 运行以下命令来删除证书策略:
    kubectl delete policy <cert-policy-name> -n <namespace>

    + 删除策略后,它会从目标集群或集群中删除。

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

      kubectl get policy <policy-name> -n <mcm namespace>
  • 从控制台删除证书策略:

    1. 在导航菜单中点击 Govern risk 来查看您的策略的表列表。
    2. 在策略违反表中点击您要删除的策略的 Actions 图标。
    3. 点击 Remove
    4. Remove policy 对话框中点击 Remove policy

您的证书策略已删除。

查看证书策略示例,请参阅证书策略控制器页面上的证书策略示例。有关其他策略控制器的更多信息,请参阅策略控制器。请参阅管理安全策略以管理其他策略。

2.5.12. 管理 IAM 策略

应用 IAM 策略来检查受管集群中所允许的集群管理员数量。在以下部分中了解如何创建、应用、查看和更新您的 IAM 策略。

2.5.12.1. 创建 IAM 策略

您可以使用命令行界面 (CLI) 或者从控制台为 IAM 策略创建 YAML 文件。

2.5.12.1.1. 通过 CLI 创建 IAM 策略

完成以下步骤,通过 CLI 创建 IAM 策略:

  1. 使用 IAM 策略定义创建 YAML 文件。运行以下命令:

    kubectl create -f iam-policy-1.yaml

    您的 IAM 策略可能类似以下 YAML 文件:

    apiVersion: policy.open-cluster-management.io/v1
    kind: IamPolicy
    metadata:
      name: iam-grc-policy
      label:
        category: "System-Integrity"
    spec:
      namespaceSelector:
        include: ["default","kube-*"]
        exclude: ["kube-system"]
      remediationAction: inform
      disabled: false
      maxClusterRoleBindingUsers: 5
  2. 运行以下命令来应用策略:

    kubectl apply -f <iam-policy-file-name>  --namespace=<mcm_namespace>
  3. 运行以下命令,验证并列出策略:

    kubectl get <iam-policy-file-name> --namespace=<mcm_namespace>

您的 IAM 策略已创建。

2.5.12.1.1.1. 通过 CLI 查看您的 IAM 策略

完成以下步骤以查看您的 IAM 策略:

  1. 运行以下命令,查看具体 IAM 策略的详情:

    kubectl get iampolicy <policy-name> -n <namespace> -o yaml
  2. 运行以下命令,查看您的 IAM 策略的描述:

    kubectl describe iampolicy <name> -n <namespace>
2.5.12.1.2. 从控制台创建 IAM 策略

从控制台创建 IAM 策略时,也会在 YAML 编辑器中创建 YAML 文件。完成以下步骤,从控制台创建 IAM 策略:

  1. 从控制台登录到集群。
  2. 在导航菜单中点击 Govern risk
  3. 点击 Create policy
  4. Specifications 字段中选择 IamPolicy。选择策略时会自动设置其余参数的值。您可以编辑值。
  5. 点击 Create

已创建一个 IAM 策略。

2.5.12.1.2.1. 从控制台查看您的 IAM 策略

您可以在控制台中查看任何 IAM 策略及其状态。

  1. 从控制台登录到集群。
  2. 在导航菜单中点击 Govern risk 来查看您的策略的表列表。

    :您可以通过选择 Policies 标签页或 Cluster violations 标签页来过滤策略列表。

  3. 选择一个策略来查看更多详情。
  4. 选择 Status 选项卡来查看 IAM 策略违反情况。

2.5.12.2. 更新 IAM 策略

查看以下部分以了解如何更新 IAM 策略。

2.5.12.2.1. 禁用 IAM 策略

完成以下步骤以禁用您的 IAM 策略:

  1. 登录您的 Red Hat Advanced Cluster Management for Kubernetes 控制台。
  2. 在导航菜单中点击 Govern risk 来查看您的策略的表列表。
  3. Actions 图标 > Disable 来禁用您的策略。此时会出现 Disable Policy 对话框。
  4. 点击 Disable policy

您的策略已禁用。

2.5.12.2.2. 删除 IAM 策略

通过 CLI 或控制台删除配置策略。

  • 通过 CLI 删除 IAM 策略:

    1. 运行以下命令来删除 IAM 策略:

        kubectl delete policy <iam-policy-name> -n <mcm namespace>

      删除策略后,它会从一个或多个目标集群中移除。

    2. 运行以下命令验证您的策略是否已移除:
      kubectl get policy <iam-policy-name> -n <mcm namespace>
  • 从控制台删除 IAM 策略:

    1. 在导航菜单中点击 Govern risk 来查看您的策略的表列表。
    2. 在策略违反表中点击您要删除的策略的 Actions 图标。
    3. 点击 Remove
    4. Remove policy 对话框中点击 Remove policy

您的策略已删除。

查看 IAM 策略控制器页面中的 IAM 策略示例。如需了解更多主题,请参阅管理安全策略

2.5.13. 管理 ETCD 加密策略

应用加密策略以在 ETCD 数据存储中检测或启用对敏感数据的加密。以下部分介绍了如何创建、应用、查看和更新您的保护策略。

2.5.13.1. 创建加密策略

您可以使用命令行界面(CLI)或者从控制台为加密策略创建 YAML 文件。查看以下部分以创建加密策略:

2.5.13.1.1. 通过 CLI 创建加密策略

完成以下步骤,通过 CLI 创建加密策略:

  1. 运行以下命令,为您的加密策略创建 YAML 文件:

    kubectl create -f etcd-encryption-policy-1.yaml
  2. 运行以下命令来应用策略:

    kubectl apply -f <etcd-encryption-policy-file-name>  --namespace=<namespace>
  3. 运行以下命令,列出并验证策略:

    kubectl get etcd-encryption-policy --namespace=<namespace>

通过 CLI 创建您的加密策略。

2.5.13.1.1.1. 通过 CLI 查看您的加密策略

完成以下步骤,通过 CLI 查看您的加密策略:

  1. 运行以下命令,查看具体加密策略的详情:

    kubectl get etcd-encryption-policy <policy-name> -n <namespace> -o yaml
  2. 运行以下命令,查看您的加密策略的描述:

    kubectl describe etcd-encryption-policy <name> -n <namespace>
2.5.13.1.2. 从控制台创建加密策略

从控制台创建加密策略时,也会在 YAML 编辑器中创建 YAML 文件。完成以下步骤,从控制台创建加密策略:

  1. 登录您的 Red Hat Advanced Cluster Management for Kubernetes 控制台。
  2. 在导航菜单中点击 Govern risk
  3. 点击 Create policy
  4. Specifications 字段中选择 EtcdEncryption。选择策略时会自动设置其余参数的值。您可以编辑值。
  5. 点击 Create
2.5.13.1.2.1. 从控制台查看您的加密策略

您可以在控制台中查看任何加密策略及其状态。

  1. 从控制台登录到集群。
  2. 在导航菜单中点击 Govern risk 来查看您的策略的表列表。

    :您可以选择 All policies 选项卡或者 Cluster violations 选项卡来过滤您的策略表列表。

  3. 选择一个策略来查看更多详情。Overview 标签页、Status 标签页和 YAML 标签页会显示。

2.5.13.2. 更新加密策略

查看以下部分以了解如何更新加密策略。

2.5.13.2.1. 禁用加密策略

完成以下步骤以禁用您的加密策略:

  1. 登录您的 Red Hat Advanced Cluster Management for Kubernetes 控制台。
  2. 在导航菜单中点击 Govern risk 来查看您的策略的表列表。
  3. Actions 图标 > Disable 来禁用您的策略。此时会出现 Disable Policy 对话框。
  4. 点击 Disable policy

您的策略已禁用。

2.5.13.2.2. 删除加密策略

通过 CLI 或控制台删除加密策略。

  • 通过 CLI 删除加密策略:

    1. 运行以下命令来删除加密策略:
     kubectl delete policy <podsecurity-policy-name> -n <mcm namespace>

    + 删除策略后,它会从目标集群或集群中删除。

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

       kubectl get policy <podsecurity-policy-name> -n <mcm namespace>
  • 从控制台删除加密策略:

    1. 在导航菜单中点击 Govern risk 来查看您的策略的表列表。
    2. 在策略违反表中点击您要删除的策略的 Actions 图标。
    3. 点击 Remove
    4. Remove policy 对话框中点击 Remove policy

您的加密策略已删除。

查看加密策略示例,请参阅 ETCD 加密策略页中的 ETCD 加密策略示例。请参阅 Kubernetes 配置策略控制器以了解其他配置策略。请参阅管理安全策略以管理其他策略。

2.5.14. gatekeeper 策略集成

了解如何创建、应用、查看和更新您的 gatekeeper 策略。

需要的访问权限 :集群管理员

先决条件 :您必须安装 Gatekeeper。如需更多信息,请参阅 open-policy-agent/gatekeeper 存储库。

2.5.14.1. 创建 gatekeeper 策略

您可以使用命令行界面(CLI)为 gatekeeper 策略创建 YAML 文件。使用 Red Hat Advanced Cluster Management for Kubernetes 配置策略,将 gatekeeper 策略从 hub 集群传播到受管集群。查看以下部分,为准入和审核场景创建 gatekeeper 策略:

2.5.14.1.1. 创建用于准入的 gatekeeper 策略

使用 Red Hat Advanced Cluster Management 配置策略创建一个 gatekeeper 策略,该策略会查找由 gatekeeper admission webhook 生成的事件。

备注:gatekeeper 必须将 emit-admission-events 设置为 true 一起部署。

  1. 为您的 gatekeeper 策略创建 YAML 文件。运行以下命令:

    kubectl create -f policy-gatekeeper-admission.yaml

    您的 gatekeeper 策略可能类似以下策略:

apiVersion: policy.open-cluster-management.io/v1
kind: Policy
metadata:
  name: policy-gatekeeper
  namespace: default
  annotations:
    policy.open-cluster-management.io/standards:
    policy.open-cluster-management.io/categories:
    policy.open-cluster-management.io/controls:
spec:
  disabled: false
  policy-templates:
    - objectDefinition:
        apiVersion: policy.open-cluster-management.io/v1
        kind: ConfigurationPolicy
        metadata:
          name: policy-gatekeeper-k8srequiredlabels
        spec:
          remediationAction: enforce # will be overridden by remediationAction in parent policy
          severity: low
          object-templates:
            - complianceType: musthave
              objectDefinition:
                apiVersion: templates.gatekeeper.sh/v1beta1
                kind: ConstraintTemplate
                metadata:
                  name: k8srequiredlabels
                spec:
                  crd:
                    spec:
                      names:
                        kind: K8sRequiredLabels
                      validation:
                        # Schema for the `parameters` field
                        openAPIV3Schema:
                          properties:
                            labels:
                              type: array
                              items: string
                  targets:
                    - target: admission.k8s.gatekeeper.sh
                      rego: |
                        package k8srequiredlabels
                        violation[{"msg": msg, "details": {"missing_labels": missing}}] {
                          provided := {label | input.review.object.metadata.labels[label]}
                          required := {label | label := input.parameters.labels[_]}
                          missing := required - provided
                          count(missing) > 0
                          msg := sprintf("you must provide labels: %v", [missing])
                        }
            - complianceType: musthave
              objectDefinition:
                apiVersion: constraints.gatekeeper.sh/v1beta1
                kind: K8sRequiredLabels
                metadata:
                  name: ns-must-have-gk
                spec:
                  match:
                    kinds:
                      - apiGroups: [""]
                        kinds: ["Namespace"]
                  parameters:
                    labels: ["gatekeeper"]
    - objectDefinition:
        apiVersion: policy.open-cluster-management.io/v1
        kind: ConfigurationPolicy
        metadata:
          name: policy-gatekeeper-admission
        spec:
          remediationAction: inform # will be overridden by remediationAction in parent policy
          severity: low
          object-templates:
            - complianceType: mustnothave
              objectDefinition:
                apiVersion: v1
                kind: Event
                metadata:
                  namespace: gatekeeper-system
                  annotations:
                    constraint_action: deny
                    constraint_kind: K8sRequiredLabels
                    constraint_name: ns-must-have-gk
                    event_type: violation
2.5.14.1.2. 为审计创建 gatekeeper 策略

使用产品配置策略创建一个 gatekeeper 策略,该策略会根据 gatekeeper 策略定期检查并评估现有资源。Red Hat Advanced Cluster Management 配置策略检查 gatekeeper 约束的 status 字段中的违反情况。

  1. 为您的 gatekeeper 策略创建 YAML 文件。运行以下命令:

    kubectl create -f policy-gatekeeper-audit.yaml

    您的 gatekeeper 策略可能类似以下策略:

    apiVersion: policy.open-cluster-management.io/v1
    kind: Policy
    metadata:
      name: policy-gatekeeper
      namespace: default
      annotations:
        policy.open-cluster-management.io/standards:
        policy.open-cluster-management.io/categories:
        policy.open-cluster-management.io/controls:
    spec:
      disabled: false
      policy-templates:
        - objectDefinition:
            apiVersion: policy.open-cluster-management.io/v1
            kind: ConfigurationPolicy
            metadata:
              name: policy-gatekeeper-audit
            spec:
              remediationAction: inform # will be overridden by remediationAction in parent policy
              severity: low
              object-templates:
                - complianceType: musthave
                  objectDefinition:
                    apiVersion: constraints.gatekeeper.sh/v1beta1
                    kind: K8sRequiredLabels
                    metadata:
                      name: ns-must-have-gk
                    status:
                      totalViolations: 0
                      violations: []

有关将第三方策略整合到产品中的更多信息,请参阅集成第三方策略控制器