本文介绍: Kubernetes 的 Pod Security Policy,正如其名字所暗示的,仅是针对 Pod 工作的,是一种用来验证和控制 Pod 及其属性的机制。另外 PSP 只能屏蔽非法 Pod 的创建,无法执行任何补救/纠正措施。而 Gatekeeper 和 Kyverno 的作用范围就不是局限在 Pod 上,并且也有更多更深入的功能,而不只是简单的验证功能。策略引擎是一种能对整个 Kubernetes 环境进行全局控制的方法。
一、前言
① Kubernetes 策略
- Kubernetes 的 Pod Security Policy,正如其名字所暗示的,仅是针对 Pod 工作的,是一种用来验证和控制 Pod 及其属性的机制。
- 另外 PSP 只能屏蔽非法 Pod 的创建,无法执行任何补救/纠正措施。而 Gatekeeper 和 Kyverno 的作用范围就不是局限在 Pod 上,并且也有更多更深入的功能,而不只是简单的验证功能。
- 策略引擎是一种能对整个 Kubernetes 环境进行全局控制的方法。
② Gatekeeper 简介
- Gatekeeper 是一个由 Google、微软等多个公司合作推出的开源项目,后来捐赠给了 CNCF,现已经历了三次迭代。Gatekeeper 是通用策略引擎 Open Policy Agent(OPA)的 Kubernetes 专用实现。由于 Open Policy Agent 与 Gatekeeper 之间的关系,该项目经常被写成“OPA Gatekeeper”来表明这层关系。Gatekeeper 实现了请求验证功能,最近还加入了变异能力。
- OPA 的一个主要特征是依赖于使用一种叫做 Rego 的专用编程语言,这种语言被用来实现策略决策的必要逻辑。通过 Rego,OPA 能够广泛适用于包括 Kubernetes 在内的多种不同的软件,实现高层次的逻辑操作。
③ Kyverno 简介
- Kyverno 是来自 Nirmata 的开源项目,后来也捐赠给了 CNCF。和 Gatekeeper 一样,Kyverno 也是一个具有验证和变异能力的 Kubernetes 策略引擎,但是它还有生成资源的功能,最近还加入了 API 对象查询的能力。
- 与 Gatekeeper 不同,Kyverno 原本就是为 Kubernetes 编写的。和 Gatekeeper 相比,Kyverno 除了对象生成功能之外,还无需专用语言即可编写策略,从实现语言的角度上来看,Kyverno 的模型更为简洁。
二、对比
三、分析
① Gatekeeper 的优势
② Gatekeeper 的劣势
③ Kyverno 的优势
④ Kyverno 的劣势
⑤ 具体分析
- Kubernetes 是一个声明式的系统:用户向 Kubernetes 提出对状态的要求,Kubernetes 通过各种控制器,去协调观察到的状态,以使其与用户期望的状态一致,这就是云原生平台的核心价值主张。为了实现这一目标,逻辑实现的重任从用户身上转移到了平台本身,每个资源类型都存在一些内部逻辑,这些逻辑就是协调其状态所需的能力。
- 对于 Gatekeeper 来说,到目前为止最大的弱点是它需要一种叫做 Rego 的专门的编程语言来实现这种逻辑,这种语言在其他地方都无法使用。这是一个现实,因为 OPA 是一个通用的策略引擎。只有通过 Gatekeeper 将其改编成 Kubernetes 形式,才能利用其能力。
- 实际上,用户负责描述他们希望调和的对象(策略),以及提供必要的逻辑(Rego)来调和它。使用外部 DSL 来管理 Kubernetes 策略,在很多方面都会变得繁琐和复杂,并给项目增加技术债务。作为一种权衡,其明显的优势是可以实现非常强大的策略。毕竟,当一个人需要编写一种编程语言时,他只受限于该语言的能力及其输入。不过,如果可以在其他地方利用 OPA,就可以分摊这种费用。
- 相比 Gatekeeper 来说,Kyverno 的第一印象就是没有那么复杂的技术需求。因为它是专门为 Kubernetes 构建的,并且用声明式的方法来表达策略,所以它的心理模型与 Kubernetes 对象的描述和协调方式是相同的。执行策略决策所需的逻辑被从用户的负担中移除,成为工具本身的领域。这种模式导致策略的编写方式得到了极大的简化,全面的降低了策略引擎的使用难度。
- Kyverno 的编译和生成能力,使它从一个简单的准入控制器转变为一个真正的自动化工具。通过结合这三种能力,再加上最近增加的 API 查询能力,Kyverno 能够执行 Gatekeeper 所不能执行的任务,而且还能够消除可能在整个集群和/或组织中分散使用的其他和不同的工具。这种简单性加上它的自动化能力和对其他工具的整合,为新用户以及有经验的用户和操作者带来了巨大的价值。
- 根据所介绍的信息,Kyverno 应该是应用 Kubernetes 策略的一个比较自然的选择。但如果用户符合下面两个用例中的一种或两种,就更应该选择 Gatekeeper。
-
- 有一种需求和具体意图,使用一致的核心工具将策略应用于组织内不同的系统(即,不仅仅是 Kubernetes)。反对意见:根据经验,无论是在云原生社区内部还是外部,大多数组织目前已经在使用其他工具将策略应用于现有系统。这通常是因为这些系统以及为这些系统实施策略的软件在 Kubernetes 以及 OPA 和 Gatekeeper 之前就已经存在。此外,这些现有工具通常不要求使用编程语言来实现其策略。因此,考虑到现有的知识、运营和资本投资,大多数组织不太可能为了实现工具一致性带来的价值,选择放弃这些工具,转而使用技术负担较重的新工具。如果正在寻找一个跨 Kubernetes 和其他系统使用的单一策略引擎,Kyverno 不适合你。
-
- 策略的复杂度很高。反对意见:根据经验,大多数 Kubernetes 用户都没有使用包括 PSP 在内的任何策略支持。而 2020 年对在 AWS 上运行容器化工作负载的客户的调查也得到了类似的结果,只有 49% 的客户使用策略。这些用户中的绝大多数都在做的是重复的策略——例如“容器不应该有特权”或“确保所有命名空间都带有给定的标签”或“验证 Pods 没有使用 hostPath 卷”等。“复杂”这个词是相对的,有点主观,但这样的策略表达方式绝对不复杂。Kyverno 允许以最简单的形式编写策略,这反过来又更容易推理和维护。如果要为一个更复杂、更困难的工具支付额外的价格,就应该尽量物尽其用,否则无法获得价值。如果无需实现高度复杂的策略,Gatekeeper 不会带来好处。
四、结论
- Gatekeeper 和 Kyverno 项目本身都是有价值、有能力的策略引擎,每个项目都有各自的优缺点。最终,用户应该根据自己的需求和限制条件进行评估并做出最明智的决定,但作为一般建议,所有生产用户都应该计划使用策略引擎来保护集群的安全并简化 Kubernetes 管理。
原文地址:https://blog.csdn.net/Forever_wj/article/details/134784484
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。
如若转载,请注明出处:http://www.7code.cn/show_39738.html
如若内容造成侵权/违法违规/事实不符,请联系代码007邮箱:suwngjj01@126.com进行投诉反馈,一经查实,立即删除!
声明:本站所有文章,如无特殊说明或标注,均为本站原创发布。任何个人或组织,在未征得本站同意时,禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益,可联系我们进行处理。