共计 5166 个字符，预计需要花费 13 分钟才能阅读完成。
本文整顿自云原生 Meetup 杭州站上，极狐(GitLab) DevOps 技术布道师马景贺的演讲。
当听到云原生的时候，你会想起什么？
可能很多人很天然地就会想到 Kubernetes、容器、微服务、开源等等，这些关键词是咱们接触云原生绕不开的话题。然而以上还少了一个关键词：平安。
云原生从 2013 年呈现，2015 年倒退起来当前，平安也逐步被关注和器重。
以云原生中罕用的镜像平安为例，下图是通过拉取罕用镜像，用 Trivy 进行扫描的后果，不同色彩对应不同等级的破绽。例如 node.js 这个开源我的项目，高危破绽有 544 个，中危级破绽有 921 个；还有 Jenkins，破绽数量也不少。
能够看到，容器镜像平安问题比较严重，对于容器镜像平安的更多剖析报告，感兴趣的敌人能够参阅 Anchore 公布的 2021 年、2022 年软件供应链平安报告。
一个残缺的软件开发生命周期包含源代码开发、构建、测试、部署等环节，每一个步骤都可能存在潜在平安危险。咱们应该把平安嵌入到每一个环节中去，也就是将 DevSecOps 利用到云原生利用程序开发的每一个环节中去，再加上 K8s 容器镜像平安扫描，能力打造一个残缺的云原生平安生态。
DevSecOps 是什么？如何帮忙咱们打造云原生平安生态？
DevSecOps 是一个兼具深度和广度的纵深平安进攻零碎，从 Source code、Build、Test 到 Deploy，任何一个阶段，都有对应的平安伎俩。其次，DevSecOps 是流程、工具、文化的深度联合，传统的研发团队里，开发人员只负责代码的开发，不会关注后续的运维等流程，但在 DevSecOps 规范要求下，平安是团队中每个人的责任，须要贯通从开发到运维全生命周期的每一个环节。
DevSecOps 强调的 平安测试左移，其实就是更早地让研发退出进来。咱们软件研发过程中的大部分平安问题，都是在开发阶段引入的，因而，如果从 Source code 阶段就尽早将平安思考在内，从源头处晋升平安能力，就能更无效、更低成本地发现和解决平安问题。
平安继续自动化 也是很重要的一个局部，因为一个残缺的平安流程，波及到很多平安工具，如果每个工具都手动配置，手动触发平安测试，那么工作量就会大大晋升。所以 DevSecOps 冀望的是平安继续自动化，开发写完代码提交变更当前（MR 或者 PR），就能够进行主动扫描，产出报告并倡议你如何修复。
当然了当初也进入 ChatGPT 时代，我前段时间做了一个 Demo，ChatGPT 在 Code Review 阶段就通知你哪些是有平安危险的，甚至还会给出举荐的修复代码，感兴趣的敌人也能够去尝试一下
Gartner 每年会针对新技术会公布一个技术成熟度曲线，上图是 2022 年的数据，DevSecOps 就在最右侧，代表着它曾经很成熟了，这也是为什么从 2019 年开始，很多企业都在开始探讨 DevSecOps。
下图是我依据行业数据绘制的示意图，能够看出 DevSecOps 一词是在 2012 年由 Gartner 提出，引起强烈关注，达到高峰期；2016 年缓缓往下走，2018 年前后达到泡沫幻灭期；终于在 2022 年达到成熟期。
从 2012 年提出概念，到往年曾经有 11 年了，DevSecOps 经验了一个残缺的技术成熟度曲线，当初曾经到了落地生根的阶段，这也是为什么，当初咱们能够分享 DevSecOps 的落地实际，而非停留在概念。
如何寻找云原生 DevSecOps 落地切入点？
平安是一个比拟大的概念，当咱们提到平安，可能包含主机平安、网络安全、利用平安……本文侧重于应用程序平安畛域。
下图尽管只是一个 Yaml 文件，然而曾经蕴含了咱们应该如何实际 DevSecOps 的重要信息。
镜像是重点，因为云原生时代都是镜像交付。尽管它是一个简略的二进制文件，但蕴含了很多货色，比方 OS、代码等，大部分的平安问题由此而生，此外 Yaml 文件自身也可能存在平安问题，比方上图下方红框展现的内容，即把敏感信息写到了 Yaml 文件中。
咱们来进行一个拆分：
应用程序部署整体能够拆分成 3 层：
- 底座是 K8s 集群
- 两头是容器镜像
- 顶层是应用程序
咱们落地 DevSecOps 时，也是依照这 3 层来打造平安防护体系。
第一层：K8s 平安
首先第一层，基于 K8s 的平安防护伎俩，可能很多人都晓得，比方 RBAC（权限治理）、Network Policy（网络策略）、Audit（审计日志）等。
第二层：容器镜像平安
第二层容器镜像，当咱们编写 Dockerfile 时，有一些最佳实际能够遵循，例如如何抉择根底镜像。
不同的根底镜像，安全漏洞数量不一样，攻击面大小也不一样。正如前文展现的几个容器镜像的破绽数量，都是不一样。如果咱们抉择适合的根底镜像，那么就能缩小攻击面。具体的就不开展了，大家能够去搜一下 Dockerfile best practice，网上有很多介绍。
另外就是镜像扫描，这也是十分重要的一环。
当初做镜像扫描的开源工具有不少，比方 Trivy、Clair、Anchore 等。应用这些工具能够帮忙扫描咱们采纳的根底镜像是否平安，发现破绽，而后进行修复，最初把这个镜像作为繁多可信源的镜像，团队外部后续应用此镜像来制作其余镜像，那么安全性就能进步很多。
另外这两年在讲软件供应链平安，有一条就是通过数字签名来进步制品的可信性，比方 OpenSSF 基金会（开源平安基金会）下的 cosign 我的项目就能够对镜像进行签名，但为什么须要签名呢？
当构建镜像时，应用 1.0.0 tag 来构建，然而咱们能够在再次批改代码之后，从新用 1.0.0 这个 tag 来构建镜像，并 push 到制品仓库。如果部署时仍旧拿 1.0.0 进行部署，那么内容其实曾经被篡改，这也就是镜像的不可信，是镜像平安的另外一个维度。
如果对镜像进行签名，就能很好的防止这个问题。当镜像构建之后就对其进行签名，在部署时再进行验证，如果验证不通过，那么阐明这个镜像被篡改了，就不应该再进行后续的部署。
以上就是对于容器镜像平安的几个办法。接下来咱们看下最上层的应用程序平安。
第三层：应用程序平安
大部分公司，都有专门的运维人员或者平安人员帮咱们增强 K8s 和容器镜像平安防护，而最上层最靠近业务，也是开发人员关注更多的一层。
这一层有十分多的平安防护伎俩，例如 Secret Detection、Dependency scanning、SAST、DAST 等，上图只列举了一部分。
以 Secret Detection 为例，依据我的教训，70% 以上的平安问题都来自于敏感信息透露。当咱们在本地 Debug 时，很容易把 Password 写死，但测试提交代码时，可能忘了删除，间接把 Password Push 到代码仓库，就造成了透露，所以 Secret Detection 在应用程序平安这部分的作用十分重要。
云原生 DevSecOps 是一个深度 + 广度的纵深进攻体系，从 K8s、Docker 到应用程序平安，每一层开展都有十分多的平安伎俩。总结来说，有以下落地准则：
- 分层施行，循序渐进
- 由简入繁，化繁为简
- 器重数据，简化工具
- 平安左移，研发闭环
- 继续优化，继续平安
针对以上云原生开发平安防护体系，极狐 GitLab 提供开箱即用的 DevSecOps 性能，包含七大性能：容器镜像扫描、动态利用平安测试 (SAST)、动静利用平安扫描（DAST）、密钥检测、License 合规、依赖项扫描以及含糊测试。
这么多平安性能，如何去实现落地？
一言以蔽之，就是 将这些平安性能集成到 CI/CD（继续集成 / 继续部署）中去，达到继续测试和继续平安的成果。极狐 GitLab 把所有平安性能和 CI/CD 集成到 Workflow 中，这个 Workflow 和研发工作流交融到一块，十分残缺。
而且，只须要几行代码，就能够实现对应伎俩的平安扫描，简略易用。
下图就是每个平安性能对应的 CI/CD Pipeline 代码。在这个过程中，开发不须要晓得每个平安性能利用的工具是什么，不须要学习工具如何配置，只须要输出这几行代码，就能进行扫描，非常容易上手。
图中不同平安伎俩标注不同色彩，是一个简略倡议，也就是蓝色的几种平安伎俩是非常容易实际而且收效不错的，如果要全副落地实际，能够采取这种循序渐进的形式，先落地蓝色局部，再落地绿色局部。
极狐 GitLab x KubeSphere 云原生平安体系如何构建？
接下来，咱们来聊聊如何把 KubeSphere 和极狐 GitLab 进行联合，利用 CI/CD，把平安防护伎俩集成到软件开发生命周期中。
极狐 GitLab 介绍
极狐 GitLab 是一个一体化的 DevOps 平台，其提供的一体化 DevOps 能力笼罩软件开发全生命周期（从打算到运维），同时内置平安性能，可能利用开箱即用的平安能力构建 DevSecOps 体系。
KubeSphere 介绍
Kubernetes 是一个非常复杂的容器编排平台，学习老本十分高，KubeSphere 所做的事件就是高度产品化和形象了底层 Kubernetes，是一个面向云原生的操作系统，解决了 K8s 应用门槛高和云原生生态工具庞杂的痛点。
在 KubeSphere 上应用极狐 GitLab 搭建 DevOps 有什么劣势？
最典型的长处就是能够实现极狐 GitLab & Runner 的云原生运行并实现灵便调度。
能够看下图这个实例，当研发人员提交代码变更之后，就会触发 CI/CD Pipeline，而极狐 GitLab CI 如果检测到有 Job 须要运行，就会给 Runner 一个信号，触发背地的调度机制，Executors 帮忙实现所有的 Step，例如对 Go 源码进行 Check out、Build、Test。
如何在 KubeSphere 上装置极狐 GitLab？
极狐 GitLab 和 KubeSphere 的集成次要有两个形式：
➤ 形式一
间接把极狐 GitLab Runner 作为单组件，装置在 KubeSphere 上，当咱们的利用程序代码提交之后，开始跑 CI 时，就会主动在 KubeSphere 上实现所有构建操作，并间接反馈数据。
装置步骤如下：
- 在 KubeSphere 的 App Management 下，通过 App Repositories 增加一个 App Repo；点击 Add 按钮，在呈现的界面中输出 Repo name 和 URL（极狐 GitLab Runner 的 Helm Chart 地址为 https://charts.gitlab.io）。
- 在 Create App 中抉择“From App Template”：
- 抉择 gitlab runner：
- 批改 Yaml 文件内容，输出极狐 GitLab 实例地址 Runner Token 等，点击 Install 即可。
- 装置胜利当前，就能够在 KubeSphere 上看到 jh-runner namespace 上面有 Pod 在失常运行。
➤ 形式二
把整个极狐 GitLab 源代码托管平台装置到 KubeSphere 下面去，目前在 KubeSphere 上部署极狐 GitLab 十分便当，只须要利用 KubeSphere 利用商店搜寻极狐 GitLab 即可一键部署。装置好当前，团队就能够间接在 KubeSphere 下面应用极狐 GitLab 进行合作了。
具体装置教程：
https://gitlab.cn/blog/2022/04/01/jihu-kubesphere/?jh=gu0%20%…
以上介绍了如何在 KubeSphere 上装置极狐 GitLab/Runner，接下来咱们通过一个 Demo 介绍如何在 KubeSphere 上进行 DevSecOps 检测。
极狐 GitLab x KubeSphere 平安扫描 Demo
装置完当前，通过 Project → Settings → CI/CD 这个门路找到 Runner 页面，右边是我的项目专用 Runner，也就是只有这个我的项目能够用，其余我的项目用不了；左边共享 Runner 则是能够被此实例下的其余我的项目所应用的 Runner。
接下来具体演示一下扫描过程：
- 先创立一个 Issue，这是 Workflow 的第一步，而后将这个需要 Issue 指派给本人；接着开始进行本地的代码编写，这里模仿一个场景，把 Token 这个敏感信息写进去，看看平安扫描过程是否能发现。
- 接下来咱们创立一个 MR，把这段有问题的代码提交下来，提交时能够选定指派人或审核人，让其他人来帮忙审核代码。
- 创立 MR 当前，就会进行主动扫描，这时候就扫描进去了咱们成心放进去的 Token，从而发现这个潜在平安问题。
- 最初，修复后从新提交，再次扫描没有问题就能够合入了。
以上就是一个简略的 Demo，来应用极狐 GitLab 的平安扫描性能。
总结
本文给大家介绍了极狐 GitLab 和 KubeSphere 各自的劣势，并探讨了如何联合 KubeSphere 和极狐 GitLab 来构建一个云原生利用平安体系，最初通过一个示例来展现极狐 GiLab DevSecOps 性能的工作原理，心愿对大家有帮忙～
本文由博客一文多发平台 OpenWrite 公布！
