如何在 Kubernetes 中实施策略？

本文要点

• 策略定义了最终用户可以在集群上执行的操作和可行的方式，以确保集群符合标准。

• 为了限制 Kubernetes 中的容器，你可以应用针对网络、卷、资源使用、资源消耗、访问控制和安全的各种策略。

• 开放策略代理门禁（OPA Gatekeeper）在 Kubernetes 集群上实施策略并加强管理。

• OPA 门禁使用 Kubernetes.admission 控制器 Webhooks 拦截对 API 服务器的请求。

• “约束”（Constraint）是一个声明，要求系统满足一组给定的要求。每个约束都使用声明性查询语言 Rego 编写。

在 Kubernetes 中实施策略

我们知道，Kubernetes 可以管理一个高可用的计算机集群，集群中的计算机连接在一起作为单个单元执行任务。

Kubernetes 包含许多抽象，这些抽象允许将容器化的应用程序部署到集群，而无需将它们附加到单独的机器上。

简而言之，Kubernetes 是——

• 适应场景广泛的：支持公共、私有、混合和多重云

• 可扩展的：模块化、可插拔、支持 hook、可组合

• 自我修复的：自动部署、自动重启、自动复制、自动扩展

在本文中，我将解释什么是 Kubernetes 策略，以及它们如何帮助你管理和保护 Kubernetes 集群。我们还将探讨为什么我们需要策略引擎来编写和管理策略。

Kubernetes 策略——简介

用最简单的术语来说，策略（Policy）定义了最终用户可以在集群上执行的操作和可行的方式，以确保集群符合组织策略。例如，策略可以是管理类型，以满足某些组织约定；也可以用来满足法律要求或执行最佳实践。

启用策略后，组织可以控制 Kubernetes 的运营，并确保集群符合组织策略。

实施策略的主要好处

默认情况下，Kubernetes 集群上的容器运行时使用的计算资源是无限的。要限制或禁用它们的资源，你必须通过以下方式实施适当的策略：

1. 网络策略——定义 Pod 组与彼此以及其他网络端点通信的方式——使用"NetworkPolicy"资源标签选择 Pod，并定义规则以指定所选 Pod 可以进行哪些通信。

2. 卷策略——Kubernetes 调度器对可连接到一个节点的卷数量有默认限制。若要为各种云提供商定义可附加到一个节点的最大卷数，请使用特定于节点的卷限制。

3. 资源使用策略——要对资源使用施加约束，请对命名空间中的适当资源使用“限制范围选项”。

4. 计算每个 Pod 或容器的资源使用情况。

5. 每个 PersistentVolumeClaim 的存储请求。

6. 请求与限制之间的比率。

7. 设置计算资源的默认请求/限制，并在运行时将其自动注入到容器中。

8. 资源消耗策略——要限制每个命名空间的总资源消耗，请使用下列“资源配额”

9. 计算资源配额

10. 存储资源配额

11. 对象计数配额

12. 根据“配额范围选项"中定义的范围限制资源数量

13. 请求与限制——每个容器可以为 CPU 或内存指定一个请求和一个限制值。

14. 配额和集群容量——以绝对单位表示

15. 默认限制优先级类别使用——例如，限制某些高优先级 Pod 的使用

16. 访问控制策略——要允许/拒绝细粒度权限，请使用 RBAC（基于角色的访问控制）和允许/拒绝细粒度权限的可定义规则。例如，“自动扩展”角色可能具有“更新”特定命名空间中部署的权限，以更改其副本数。

17. 安全策略——要定义和控制 Pod 的安全性，请使用 Pod 安全策略（在 v1.15 上可用）。根据 Kubernetes文档，它将启用 Pod 创建和更新的细粒度授权。它还定义了 Pod 必须遵守的一组条件（符合这些条件的 Pod 才能被系统接受），以及相关字段的缺省值。它们允许管理员控制以下内容：

• 运行特权容器

• 主机命名空间的使用

• 主机网络和端口的使用

• 卷类型的使用

• 主机文件系统的使用

• 将 escalation 限制为 root 特权

• 容器的用户和组 ID

• 容器使用的 AppArmor 或 seccomp 或 sysctl 配置文件

Kubernetes 策略的局限性

从上面的内容可以看出，Kubernetes 没有单一的安全配置。例如，我们需要具体定义特定用户可以执行的操作、他们所属的组、他们可以在各种 Kubernetes 资源（pod、部署、服务等）上执行的操作以及适用于他们所创建对象的网络和 pod 安全策略，等等；这些都不能用跨不同策略组件的规则来表达。

由于缺乏单点安全解决方案，只能手动确保合规意味着更容易出错且更让人头疼。我们需要一种轻量级的通用策略引擎，这种引擎允许开发人员独立操作而不牺牲合规性，并且还要简化策略执行，自动发现违规和冲突。策略作者还可以创作和部署自定义策略，以控制策略准入的服务功能的行为。

开放策略代理门禁介绍

开放策略代理门禁（Open Policy Agent Gatekeeper）在 Kubernetes 集群上执行策略并加强管理。它提供的主要功能如下：

• 可扩展的参数化策略库。

• 高级声明性语言（Rego），用于在系统中编写细粒度的策略。

• 用于实例化策略库的原生 Kubernetes CRD——可以在你希望系统满足一组给定要求的位置定义一些“约束”（Constraint）。

• 用于扩展策略库的原生 Kubernetes CRD——可以定义“约束模板”（ConstraintTemplate），该模板允许用户声明新的约束。

• 审核功能——可以根据集群中实施的约束定期评估复制的资源，以检测不匹配项。

• 可用于编写策略测试的测试框架。通过编写策略测试，可以加快新规则的开发过程并节省时间。

• 
  
  

• 开放策略代理门禁组件（图源：开放策略代理门禁文档）

  
  

Kubernetes提供了准入控制器 Webhooks——Admission Controller Webhooks（HTTP 回调），以在将准入请求作为对象持久存储在 Kubernetes 中之前拦截它们；OPA 门禁使用相同的方法从 API 服务器做出策略决策。一旦完成所有对象修改，并且 API 服务器验证了传入对象，将就会调用"准入验证 Webhooks"，它们可以拒绝或接受执行策略的请求。

门禁会实施由开放策略代理执行的基于 CRD 的策略，从而使用户能够通过配置自定义准入控制。

关键概念

• 控件验证——将所有门禁安装在集群中之后，只要在集群中创建、更新或删除资源，API 服务器都将触发门禁准入 Webhook 来处理准入请求。在验证过程中，门禁充当 API 服务器和 OPA 之间的桥梁。API 服务器将强制执行 OPA 执行的所有策略。

• 策略/约束——约束是一个声明，希望系统满足给定的一组要求。每条约束都使用 Rego（一种声明性查询语言）编写，用于枚举违反系统预期状态的数据实例。所有约束均按与逻辑计算。只要有一条约束条件不满足，则整个请求将被拒绝。

• 审核功能——可以根据集群中实施的约束对复制资源进行定期评估，以检测原有的配置错误。

• 某些约束需要数据复制，因为这些约束需要访问集群中除评估对象之外的对象。例如，强制入口主机名唯一的约束必须有权访问集群中的其他所有入口。

使用 OPA 门禁实施简单约束/约束模板

在这个示例中，我们将定义新的约束模板和约束，要求所有标签都存在并有效。我将使用 OPA 门禁安装随附的示例。

安装

运行下面的命令来使用预构建的映像在集群中部署门禁的发行版。

kubectl apply -f https://raw.githubusercontent.com/open-policy-agent/gatekeeper/master/deploy/gatekeeper.yaml

Kubernetes 集群已准备就绪

我们已经准备好了 Kubernetes 集群，下面使用预构建的映像安装门禁。

开放策略代理门禁安装完成

门禁角色和 CRD 现在已安装。下一步是创建新的约束模板，以强制命名空间上的标签存在并有效。

定义约束模板

ConstraintTemplate（约束模板）定义了需要强制的内容以及约束的模式。这里你可能注意到了 openAPIV3Schema 和 targets 约束字段，它们允许用户微调约束的行为。

apiVersion: templates.gatekeeper.sh/v1beta1kind: ConstraintTemplatemetadata:  name: k8srequiredlabelsspec:  crd:    spec:      names:        kind: K8sRequiredLabels        listKind: K8sRequiredLabelsList        plural: k8srequiredlabels        singular: 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])        }

使用以下命令安装约束模板

kubectl apply -f https://raw.githubusercontent.com/open-policy-agent/gatekeeper/master/demo/basic/templates/k8srequiredlabels_template.yaml

OPA 门禁 ConstraintTemplate 已创建

创建 ConstratintTemplate 后，下一步是定义约束并将其应用于命名空间。

定义约束

以下约束使用上一步中定义的 K8sRequiredLabels 约束模板。下一步是使用约束来确保在所有命名空间上都定义了门禁标签。

apiVersion: constraints.gatekeeper.sh/v1beta1kind: K8sRequiredLabelsmetadata:  name: ns-must-have-gkspec:  match:    kinds:      - apiGroups: [""]        kinds: ["Namespace"]  parameters:    labels: ["gatekeeper"]

match 字段用来定义给定约束将会应用的对象范围。

• kinds 接受带有 apiGroups 的对象列表，kinds 字段列出约束将会应用的对象组/类别。

• namespaces 是命名空间名称的列表。定义的约束将只应用到列出的命名空间中的资源。

• labelSelector 和 namespaceSelector 是标准的 Kubernetes 标签和命名空间选择器。

使用以下命令安装上述约束

kubectl apply -f https://raw.githubusercontent.com/open-policy-agent/gatekeeper/master/demo/basic/constraints/all_ns_must_have_gatekeeper.yaml

OPA 门禁约束已创建

现在约束模板和约束已启用，下面来尝试创建不带标签的新命名空间。

OPA 门禁测试简单约束

如你所见，OPA 门禁阻止了没有标签的命名空间的创建。接下来我们看一下设置容器限制策略的示例。

使用 OPA 门禁实施容器限制约束/约束模板

在这个示例中，我们将定义新的约束模板和约束，要求在 Pod 的定义期间指定容器限制。

我们将重用 Kubernetes 集群和上一个演示中安装的门禁组件。第一步是定义约束模板。

定义约束模板

ConstraintTemplate 定义了需要强制的内容以及约束的模式。此处的限制在 k8scontainterlimits_template.yaml.中定义。使用以下命令安装约束模板：

kubectl apply -f https://raw.githubusercontent.com/open-policy-agent/gatekeeper/master/demo/agilebank/templates/k8scontainterlimits_template.yaml

OPA 门禁容器限制约束模板已创建

定义约束

下一步是定义约束，以确保 cpu 和内存应等于或小于 200m 和 1Gi 的限制。

apiVersion: constraints.gatekeeper.sh/v1beta1kind: K8sContainerLimitsmetadata:  name: container-must-have-limitsspec:  match:    kinds:      - apiGroups: [""]        kinds: ["Pod"]  parameters:    cpu: "200m"    memory: "1Gi"

OPA 门禁容器限制约束已创建

现在我们已经创建了约束模板和约束，下面尝试创建没有限制的新资源。

apiVersion: v1kind: Podmetadata:  name: opa  namespace: production  labels:    owner: me.agilebank.demospec:  containers:    - name: opa      image: openpolicyagent/opa:0.9.2      args:        - "run"        - "--server"        - "--addr=localhost:8080"

kubectl apply -f https://raw.githubusercontent.com/open-policy-agent/gatekeeper/master/demo/agilebank/bad_resources/opa_no_limits.yaml

OPA 门禁容器限制约束测试

如你所见，约束模板和约束禁止了无限制的 Pod 创建。

恭喜！我们已经使用 OPA 门禁策略引擎成功实施了策略。

要卸载门禁策略引擎，请先清除门禁系统命名空间中旧的约束、约束模板和配置资源，然后卸载门禁。目前，卸载操作仅会删除门禁系统，这将确保门禁删除所有终结器，否则终结器将需要手动删除。

总结

尽管开放策略代理门禁使 Kubernetes 管理员可以在整个堆栈中进行基于策略的细粒度控制，但是由于应用程序部署的复杂性，应用策略的过程还是会存在挑战。

参考

1. Kubernetes准入Webhooks
   

2. Kubernetes限制范围
   

3. Kubernetes资源配额
   

4. Kubernetes Pod安全策略
   

5. Kubernetes存储限制
   

6. 开放策略代理
   

7. 门禁Github
   

8. 门禁示例
   

作者介绍

Karthikeyan Shanmugam（Karthik）是一位经验丰富的解决方案架构专家，在银行、金融服务、医疗保健和航空业的企业应用程序设计和开发领域拥有超过 18 年的经验。目前他在应用程序转换领域提供技术咨询和解决方案。

原文链接：

Implementing Policies in Kubernetes