云原生｜浅谈Kubernetes 安全防护问题，构建安全容器化应用

Kubernetes 是一个开源的容器编排平台，它可以提供容器化应用的部署、管理和拓展。现如今 Kubernetes 已经成为容器编排的事实标准，越来越多的团队将自己产品托管在 Kubernetes 上，随着这一趋势云原生技术也不断发展与演进，而安全一直是企业比较关注的核心问题之一。

RedHat 在 23 年《Kubernetes 安全状况报告》中提到：三分之二的受访者会因为 Kubernetes 安全问题而延迟或减慢部署；容器和 Kubernetes 安全合规事件会造成负面影响；漏洞和配置错误是容器和 Kubernetes 环境的首要安全问题；少部分受访者的安全防护和 DevOps 是分开的；来自开源软件是软件供应链安全的担忧；

不同团队侧重方向不同，最终实践的安全防护也不相同，下文从几个方向来讨论安全这一主题。

一、DevSecOps

什么是 DevSecOps？DevSecOps 和 DevOps 的区别在哪里？

DevSecOps（Develop, Security, Operation）分别代表了“开发，安全，运维”，从字面上可以看出 Security 始终贯穿整个 DevOps 流程。这是因为随着发布速率和频率不断提高，传统的应用安全团队无法跟上发布的节奏。在过去，安全性总是由单独的安全团队在开发周期快要结束时才参与进来，随着产品快速迭代，安全团队无法确保每个发布都是安全的，正是因为这种脱节才衍生出 DevSecOps 的概念。

DevOps 强调开发和运维团队之间的协作，以简化应用的开发周期，从此可以达成快速迭代抢占市场的模式，以此敏捷开发的管理方式也推广开来。DevSecOps 将安全融入整个流程，这一点不仅体现在应用的开发过程中，而是所有。它的生命周期与 DevOps 类似，包括编码、构建、测试、部署、运行和监控，甚至包括规划和调研……每个阶段都应该包含强有力的安全检查或审核。

DevSecOps 带来全新的文化冲击，这不仅要求开发人员熟知应用安全性的基本准则，也需要知道如何衡量风险，更需要知道如何实施或弥补损失。DevSecOps 本意是希望借助一系列安全测试、漏洞扫描、安全审计等方式提前发现或修复潜在的安全漏洞。在开发阶段或测试阶段就能早早发现安全风险，并确保立即解决这些威胁。这总比事后补救要更好，毕竟一旦出现“补救”也就意味着已经造成“损失”。

现在我们可以回答第二个问题，它们之间的区别在哪里？

● 安全：最主要的区别在于安全的整合，DevOps 专注于开发和运维之间的协作，本质上并没有将安全作为整个流程的关键部分。DevSecOps 则将安全作为整个交付流程中的一个综合因素。它更倡导安全作为首位因素，期望考虑到方方面面存在安全隐患的可能性。

●安全团队介入时间点：上述我们提到过，传统的安全团队一般在开发周期将要结束时才会参与，DevSecOps 在项目开始之初就融入到各个阶段。

●工具的偏向：DevSecOps 会使用一些代码分析工具、自动安全测试或审查工具。DevOps 则更偏向自动化和高效的流程管理。

DevSecOps 和 DevOps 本质上是两种不同的理念，并没有好坏之分，也不代表 DevSecOps 要优于 DevOps。无论做出哪种选择，最终都要结合实际情况和最终目标来选择适合的。如果所在行业受到严格监管，需要处理敏感的客户数据，比如需要通过某种监管才能出口，那么 DevSecOps 可能是比较明智的选择。反之，如果没有这些“束缚”，更在意的是快速迭代，那 DevOps 便是首选。

DevSecOps 推荐工具（https://time.geekbang.org/column/article/197268）。

二、Kubernetes 原生安全防护

Kubernetes 原生安全防护的原则是：当安全防护与管理容器化应用的系统保持一致时，安全防护才能得到最有效的实现。

它必须具备以下特点才能被称为“Kubernetes 原生”：

1、直接和 Kubernetes API 服务器集成

2、评估 Kubernetes 软件本身的漏洞

3、以 Kubernetes 对象模型中的资源（包括部署、命名空间、服务、容器集等）为基础，建立策略管理等安全功能

4、尽量使用内置的 Kubernetes 安全功能来处理执行，以实现更高的自动化、可扩展性和可靠性

5、分析 Kubernetes 特定工作和配置中的声明性数据

当我们阅读技术文档时，总是会看到一些“原则”或“特点”，这些条条框框看起来晦涩难懂，其实它只是描述某一概念的特征，当结合实际场景就会容易理解很多。

比如第一条“直接和 Kubernetes API 服务器集成”，这是为了获得 Kubernetes 上工作负载信息，假设现在需要基于 Kubernetes 做一个定制化插件，如果不与 Kubernetes API 服务器集成在一起，我们很难了解整个架构的全貌。Kubernetes 上部署了哪些中间件，有哪些业务容器已经部署在上面，如果需要调度应该怎么更合理分配资源，有哪些边缘计算？

通过结合实际业务场景反推，我们不仅能了解“特点”为什么这么制定，也能更好地思考它的局限性以及延展性。

“评估 Kubernetes 软件本身的漏洞”好像没什么必要，作为云原生时代的操作系统，很多工程师会下意识忽略 Kubernetes 本身也会存在漏洞，亦或“即使 Kubernetes 出现漏洞，我也无能力去修补”。对于普通工程师来说，可能唯一能做的就是定期计划性迭代 Kubernetes 版本，不得不承认在生产环境对 Kubernetes 集群规划迭代是一个很繁琐且危险的事情，一不小心就会导致应用大面积宕机。但换个角度看，不管处理不处理，风险它都在那里，选择视而不见并不是最优的解决方案。

上述特点中第三条可以和第四条结合起来似乎在回答某个问题，如果它们是答案，是不是可以反向推断出问题：“如何构建 Kubernetes 原生的策略管理？”

Kubernetes 中会包含很多基础的资源对象，Pod、Namespace、Server……即使不依靠 CRD 也能应对大部分场景，所以它才成为云原生时代的操作系统。如果想要在此基础上构建出合理的策略管理，那么至少要对这些基础资源对象有一个清晰的认知。比如要明白为什么在 Kubernetes 中不使用镜像作为最小的调度单位，而是使用 Pod？PV、PVC、StorageClass 这些又代表着什么？Service 和 Ingress 又是什么？在理解这些问题背后的设计，能帮助我们站在更加宏观的角度看清整个架构的全貌，也有助于我们建立安全策略。

Kubernetes 本身也会有一套机制来实现集群的安全控制，比如 API Server 的认证授权、准入控制、Secret、RBAC 鉴权等。这些机制可以保证容器与所在宿主机的隔离，限制容器对其他基础设施造成的影响，划分容器获取宿主机资源的上下限……这些安全控制明确了组件的边界划分，让容器在最小权限内平稳运行。

配置错误可能是最容易造成安全问题的原因，这也是为什么第五点需要特别强调“分析 Kubernetes 特定工作和配置中的声明性数据”。

k8sgpt（https://github.com/k8sgpt-ai/k8sgpt）是一个用于扫描 Kubernetes 集群、诊断和分析问题的工具。作者知道有一些辅助工具能帮助 Yaml 文件的格式做出矫正，但在 AI 迅速发展的今天，也可以尝试用 AI 辅助分析/校验这些配置（当然也要注意敏感信息）。当然，最终需要做出判断的还是工程师本身，毕竟 AI 也无法为你担责（要注意 AI 所产生的幻觉）。

三、容器安全防护

容器安全防护包括了三个方面：保护容器管道和应用的安全；保护容器部署环境和基础架构的安全；在运行时保护容器化工作负载的安全。

在云原生环境下，容器是标准的应用交付方式，容器安全的重要性也不言而喻。

构建镜像

构建镜像是最基础的一环，使用 buildah可以从零开始构建兼容 OCI 和 Docker 的镜像。对于安全来说，一个基础镜像是衍生镜像的起点。

一般情况下工程师会选择来自知名公司或开源组织公开的镜像，这些镜像的来源清晰，镜像中所有包含的组件源码都可以获得。从安全角度来说，通过评估源码重新构建镜像是很稳妥的方式，但随着应用增加，组件更迭也会对镜像带来新的变数。这也衍生出私有镜像仓库和镜像扫描程序，定期扫描私有镜像仓库内所有镜像，通过识别不当配置容器来降低风险。

传统应用在交付时需要提供“物料清单”，当中记录了所有使用组件的版本信息及来源。在云原生环境下，容器镜像也应该提供包含出处细节且通过扫描的清单。这便于我们重新构建镜像，保持它的来源可信，持续跟踪它的安全。

我们始终希望镜像是相对安全的，经过一些实践后，一些通用工具总是避免安装它们，比如 wget、curl、netcat、ssh、编译器、调试器等。这些工具让镜像变得臃肿，可能也会受到供应链攻击，参考 xz 供应链安全事件。

访问权限与部署

当镜像构建成功后，意味着下一步就是如何保护好它们。私有容器镜像仓库往往是不错的选择，它可以将存储的镜像实现自动化和分配策略，最大限度减少因为容器带来的漏洞的人为错误。企业级安全防护功能的容器镜像仓库内置了漏洞扫描程序，当然这可能需要付出更多的成本。

使用 DevOps 平台配合另外一些安全扫描的工具也是一个不错的选择，这不仅解决了镜像的管理和构建，同时也解决了部署的问题。如今 DevOps 平台已经被各大云厂商熟用，大规模实践方案已经相当成熟。

运行时保护

容器安全防护不会随着测试和部署的结束而终止，而是延伸到容器化应用运行时。运行时，应用可能无法预测危险来自何处，运行时安全防护应该包括查找行为异常的应用。在现实实践中可以通过容器化监控来检测异常行为，避免意外的网络流、特权提升、加密挖矿等。

使用 Kubernetes 的网络策略也可以是一个选择，允许容器与容器之间的通信，实施零信任策略后可以确保单个容器受损后不影响其他容器，而造成应用的大面积宕机。

四、后记

本篇讨论了云原生环境下的安全防护方向，结合了少部分场景提出了一些实践思路，无论团队的安全侧重方向如何，“安全”这一主题都应该贯穿我们整个应用的生命周期。

资源来源: 《Kubernetes 权威指南》

1.https://www.cnblogs.com/FLY_DREAM/p/17599368.html

2.https://www.ibm.com/cn-zh/topics/devsecops

3.https://www.redhat.com/zh/topics/containers/advantages-of-kubernetes-native-security

4.https://www.redhat.com/zh/topics/security/container-security

作者：王凯| 后端开发工程师

版权声明:本文由神州数码云基地团队整理撰写，若转载请注明出处。

公众号搜索神州数码云基地，了解更多技术干货！