本文要点

策略定义了最终用户可以在集群上执行的操作和可行的方式，以确保集群符合标准。
为了限制Kubernetes中的容器，你可以应用针对网络、卷、资源使用、资源消耗、访问控制和安全的各种策略。
开放策略代理门禁（OPA Gatekeeper）在Kubernetes集群上实施策略并加强管理。
OPA门禁使用Kubernetes.admission控制器Webhooks拦截对API服务器的请求。
“约束”（Constraint）是一个声明，要求系统满足一组给定的要求。每个约束都使用声明性查询语言Rego编写。

在Kubernetes中实施策略

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

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

简而言之，Kubernetes是——

适应场景广泛的：支持公共、私有、混合和多重云
可扩展的：模块化、可插拔、支持hook、可组合
自我修复的：自动部署、自动重启、自动复制、自动扩展

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

Kubernetes策略——简介

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

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

简化运营	管理团队可以随时更新策略，无需重编译或重新部署服务
简化策略执行/自动从损害和冲突中恢复	策略部署完全自动化、自动发现违规和冲突、保证一致性
灵活应对需求变化	策略编写者无需专业开发运维知识即可读写和管理策略规则

实施策略的主要好处

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

网络策略——定义Pod组与彼此以及其他网络端点通信的方式——使用"NetworkPolicy"资源标签选择Pod，并定义规则以指定所选Pod可以进行哪些通信。
卷策略——Kubernetes调度器对可连接到一个节点的卷数量有默认限制。若要为各种云提供商定义可附加到一个节点的最大卷数，请使用特定于节点的卷限制。
资源使用策略——要对资源使用施加约束，请对命名空间中的适当资源使用“限制范围选项”。
1. 计算每个Pod或容器的资源使用情况。
2. 每个PersistentVolumeClaim的存储请求。
3. 请求与限制之间的比率。
4. 设置计算资源的默认请求/限制，并在运行时将其自动注入到容器中。
资源消耗策略——要限制每个命名空间的总资源消耗，请使用下列“资源配额”
1. 计算资源配额
2. 存储资源配额
3. 对象计数配额
4. 根据“配额范围选项"中定义的范围限制资源数量
5. 请求与限制——每个容器可以为CPU或内存指定一个请求和一个限制值。
6. 配额和集群容量——以绝对单位表示
7. 默认限制优先级类别使用——例如，限制某些高优先级Pod的使用
访问控制策略——要允许/拒绝细粒度权限，请使用RBAC（基于角色的访问控制）和允许/拒绝细粒度权限的可定义规则。例如，“自动扩展”角色可能具有“更新”特定命名空间中部署的权限，以更改其副本数。
安全策略——要定义和控制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/v1beta1
kind: ConstraintTemplate
metadata:
  name: k8srequiredlabels
spec:
  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/v1beta1
kind: K8sRequiredLabels
metadata:
  name: ns-must-have-gk
spec:
  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/v1beta1
kind: K8sContainerLimits
metadata:
  name: container-must-have-limits
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Pod"]
  parameters:
    cpu: "200m"
    memory: "1Gi"

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

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

apiVersion: v1
kind: Pod
metadata:
  name: opa
  namespace: production
  labels:
    owner: me.agilebank.demo
spec:
  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管理员可以在整个堆栈中进行基于策略的细粒度控制，但是由于应用程序部署的复杂性，应用策略的过程还是会存在挑战。

参考

作者介绍

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

原文链接：

Implementing Policies in Kubernetes

创作场景

如何在 Kubernetes 中实施策略？