前言
Kubernetes 是一个开源的容器编排平台，它可以提供容器化应用的部署，管理和拓展。现如今Kubernetes已经成为容器编排的事实标准，越来越多的团队将自己的产品托管在Kubernetes上，随着这一趋势云原生技术也不断发展与演进，而安全一直是企业比较关注的核心问题之一。
RedHat在23年《Kubernetes 安全状况报告》中提到：三分之二的受访者会因为Kunernetes 安全问题而延或减慢部署；容器和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推荐工具。
Kubernete 原生安全防护
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集群规划迭代是一个很繁琐且危险的事情，一不小心就会导致应用大面积宕机。但换个角度看，不管处不处理，风险它都在那里，选择视而不见并不是最优的解决方案。
上述特点中第三条可以和第四条结合起来似乎在回答某个问题，如果它们是答案，是不是可以反向推断出问题：”如何构建Kubernete原生的策略管理？“
Kubernete中会包含很多基础的资源对象，Pod,Namespace,Server…即使不依靠CRD也能应对大部分场景，所以它才成为云原生时代的操作系统。如果想要在此基础上构建出合理的策略管理，那么至少要对这些基础资源对象有一个清晰的认知。比如要明白为什么在Kubernete中不使用镜像作为最小的调度单位，而是使用Pod？PV,PVC,StorageClass这些又代表着什么？Service和Ingress 又是什么？在理解这些问题背后的设计，能帮助我们站在更加宏观的角度看清整个架构的全貌，也有助于我们建立安全策略。
Kubernete本身也会有一套机制来实现集群的安全控制，比如API Server的认证授权，准入控制，Secret，RBAC鉴权等。这些机制可以保证容器与所在宿主机的隔离，限制容器对其他基础设施造成的影响，划分容器获取宿主机资源的上下限……这些安全控制明确了组件的边界划分，让容器在最小权限内平稳运行。
配置错误可能是最容易造成安全问题的原因，这也是为什么第五点需要特别强调”分析Kubernetes特定工作和配置中的声明性数据”。
k8sgpt是一个用于扫描Kubernete集群，诊断和分析问题的工具。作者知道有一些辅助工具能帮助Yaml文件的格式做出矫正，但在AI迅速发展的今天，也可以尝试用AI辅助分析/校验这些配置(当然也要注意敏感信息)。当然，最终需要做出判断还得是工程师本身，毕竟AI也无法为你担责(要注意AI所产生的幻觉)。
容器安全防护
容器安全防护包括了三个方面：保护容器管道和应用的安全；保护容器部署环境和基础架构的安全；在运行时保护容器化工作负载的安全。
在云原生环境下，容器是标准的应用交付标准，容器安全的重要性也不言而喻。
构建镜像
构建镜像是最基础的一环，使用buildah可以从零开始构建兼容OCI和Docker的镜像。对于安全来说，一个基础镜像是衍生镜像的起点。
一般情况下工程师会选择来自知名公司或开源组织公开的镜像，这些镜像的来源清晰，镜像中所有包含的组件源码都可以获得。从安全角度来说，通过评估源码重新构建镜像是很稳妥的方式，但随着应用增加，组件更迭也会对镜像带来新的变数。这也衍生出私有镜像仓和镜像扫描程序，定期扫描私有镜像仓内所有镜像，通过识别不当配置容器来降低风险。
传统应用时在交付时需要提供”物料清单”，当中记录了所有使用组件的版本信息及来源。在云原生环境下，容器镜像也应该提供包含出处细节，且通过扫描的清单。这便于我们重新构建镜像，保持它的来源可信，持续跟踪它的安全。
我们始终希望镜像是相对安全的，经过一些实践后，一些通用工具总是避免安装它们，比如wget，curl，netcat,ssh,编译器，调试器等。这些工具让镜像变得臃肿，可能也会收到供应链攻击，参考xz供应链安全事件。
访问权限与部署
当镜像构建成功后，意味着下一步就是如何保护好它们。私有容器镜像仓往往是不错的选择，它可以将存储的镜像实现自动化和分配策略，最大限度减少因为容器带来漏洞的人为错误。企业级安全防护功能的容器镜像仓库内置了漏洞扫描程序，当然这可能需要付出更多的成本。
使用DevOps平台配合另外一些安全扫描的工具也是一个不错的选择，这不仅解决了镜像的管理和构建，同时也解决了部署的问题。如今DevOps平台已经被各大云厂商熟用，大规模实践方案已经相当成熟。
运行时保护
容器安全防护不会随着测试和部署的结束而中止，而是延伸到容器化应用运行时。运行时，应用可能无法预测危险来自何处，运行时安全防护应该包括查找行为异常的应用。在现实实践中可以通过容器化监控来检测异常行为，避免意外的网络流，特权提升，加密挖矿等。
使用Kubernetes的网络策略也可以是一个选择，允许容器与容器之间的通信，实施零信任策略后可以确保单个容器受损后不影响其他容器，而造成应用的大面积宕机。
后记
本篇讨论了云原生环境下的安全防护方向，结合了少部分场景提出了一些实践思路，无论团队的安全侧重方向如何，”安全”这一主题都应该贯穿我们整个应用的生命周期。
资源来源
《Kubernetes权威指南》
https://www.cnblogs.com/FLY_DREAM/p/17599368.html
https://www.ibm.com/cn-zh/topics/devsecops
https://www.redhat.com/zh/topics/containers/advantages-of-kubernetes-native-security
https://www.redhat.com/zh/topics/security/container-security