如何在 Kubernetes 中实施策略?

阅读数:745 2019 年 10 月 28 日 08:00

如何在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. 资源使用策略——要对资源使用施加约束,请对命名空间中的适当资源使用“限制范围选项”。
    1. 计算每个 Pod 或容器的资源使用情况。
    2. 每个 PersistentVolumeClaim 的存储请求。
    3. 请求与限制之间的比率。
    4. 设置计算资源的默认请求 / 限制,并在运行时将其自动注入到容器中。
  4. 资源消耗策略——要限制每个命名空间的总资源消耗,请使用下列“资源配额”
    1. 计算资源配额
    2. 存储资源配额
    3. 对象计数配额
    4. 根据“配额范围选项 " 中定义的范围限制资源数量
    5. 请求与限制——每个容器可以为 CPU 或内存指定一个请求和一个限制值。
    6. 配额和集群容量——以绝对单位表示
    7. 默认限制优先级类别使用——例如,限制某些高优先级 Pod 的使用
  5. 访问控制策略——要允许 / 拒绝细粒度权限,请使用 RBAC(基于角色的访问控制)和允许 / 拒绝细粒度权限的可定义规则。例如,“自动扩展”角色可能具有“更新”特定命名空间中部署的权限,以更改其副本数。
  6. 安全策略——要定义和控制 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中实施策略?

    开放策略代理门禁组件(图源:开放策略代理门禁文档)

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 集群已准备就绪

我们已经准备好了 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

如何在Kubernetes中实施策略?

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

如何在Kubernetes中实施策略?

OPA 门禁约束已创建

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

如何在Kubernetes中实施策略?

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

如何在Kubernetes中实施策略?

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"

如何在Kubernetes中实施策略?

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

如何在Kubernetes中实施策略?

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

评论

发布