关于云原生:云原生安全趋势演进大揭秘｜云原生安全公开课第一期

3次阅读

共计 3994 个字符，预计需要花费 10 分钟才能阅读完成。

Hello 大家好，明天的分享大抵分为三个局部：云原生的倒退历程，云原生的平安治理，以及平安产品介绍。

对于倒退历程这一部分，次要会从云原生历史的角度登程进行讲述，以及从历史中咱们学习到了什么。第二局部平安治理，次要就目前的局势，咱们应该怎么做好平安治理这方面动手。这两大点都是从一个宏观的视角登程，在之后的云原生平安公开课中会更多从宏观角度去剖析，包含：问脉底层的 SDK 到底怎么实现；咱们做一些比拟难的技术挑战时，是怎么解决问题的······大家能够关注一下之后的课程。

那么咱们来到第一局部“云原生的倒退历程”，说到云原生，大家会想到什么货色呢？有的人可能会想到 K8s，有的人可能会想到 Docker。但其实最早的都不是这两个货色。最早是来源于 Linux 内核所提供的两个个性：一个叫 Cgroup、一个叫 Namespace。这是 Linux 内核很早就提供了的性能：Cgroup 反对对于过程资源的应用限度，Namespace 提供了对于过程资源的隔离限度。在 Kernel 层咱们发现 Cgroup 做了限度，比方你想占用多少 CPU 资源、内存资源，都是由 Cgroup 决定的。而 Cgroup 上是由 Namespace 限度的，对过程信息、网络信息等不同力度等资源做了限度。这两个外围的能力，就是咱们所谓的容器化，是最根底的基石。

2009 年的时候就诞生了一个我的项目，叫 Linux Container，俗称 LXC。这个我的项目就是最早的沙盒化利用，它容许使用者以一个虚拟化的形式去运行本人的利用。但有的同学可能会比拟纳闷，“为什么 2009 年就有 LXC 了，可是我感觉云原生是最近几年才火起来的。”我感觉这是一个很好的问题，为什么 LXC 在 2009 年的时候始终没有失去宽泛的推广或利用呢？起因很简略，因为 LXC 它只用了 Cgroup 和 Namespace，就导致了我在一台机器上用 LXC 跑起来了某个 application，在另外一台机器上可能跑不起来了。因为一个 application 可能会存在一些 libc 的依赖，在动静编译的状况下必须跟另外一台机器保持一致能力用这个 LXC。所以 LXC 在 2009 年推出来之后没有实现大范畴推广。

直到 2014 年 Docker 的横空出世，它在 Github 下面开源，扭转了云原生畛域的倒退历程。

Docker 实质上和过后的其余容器化我的项目没有特地大的区别，然而却做了一个十分奇妙的微翻新，那就是将操作系统的文件系统也打包到利用当中。这个微翻新使得所有基于 Docker 打包的 application，真正做到了 build once, run everywhere。

然而 Docker 这个我的项目，即便播种了大量的社区关注，仍然被外界认为仅仅只是玩具。起因在于，Docker 自身并没有方法帮忙开发者实现大规模场景下的利用部署。

很显著，方才那个问题很多厂商都留神到了，于是纷纷推出自家的集群产品。其中以两个产品最为突出，一个是 Google 开源的 Kubernetes，一个是 Docker 开源的 Docker Swarm。

这场和平的输赢也不言而喻，目前 Kubernetes 以统治级的位置成为了开源集群的佼佼者。上图为 Kubernetes 的架构，不难看出，对于容器运行时的治理，使得大规模的容器化部署变成了可能。

随着云原生技术的倒退，越来越多的我的项目被盖章到 CNCF 当中，整个社区生态也逐步丰盛，慢慢呈现出百家争鸣的态势。

云原生遍及的基本在于生产力的进步，而进步生产力的外围在于“标准化”。镜像使得利用标准化，容器又能够运行标准化的镜像，集群又能够调度标准化的容器。这一系列流程升高了开发的老本，从而进步了生产效率。在肉眼可见的将来当中，基础设施的技术栈只会越来越对立，最终造成业界通用的规范。

2017 年，正式公布了凋谢容器规范 (OCI)。这个规范的颁布也意味着，容器的全生命周期都被纳入到标准化轨道当中。

随着云原生技术的倒退，社区也围绕一直呈现的新兴技术，诞生了很多新的平安工具，比方 trivy/tetragon/kubiscan 等等。接下来是第二局部“平安治理”，为什么讲这一部分呢？我集体认为云原生是一个比拟新兴技术。当初很多甲方企业也好，乙方企业也好，在推动云原生过程当中，还是处于一个相当进行时的状态。不是所有业务线都可能齐全涌入到这套生态外面。所以不论是甲方还是乙方的安全部门，咱们要去做标准化的产品，都会发现这两头有很多很多的坑和问题。

其中“产品复杂度”就是最重要的一个问题。首先咱们来聊一下这个事件，当咱们须要去解决一家企业云原生平安问题的时候，咱们心愿用一个什么样的形式去解决它，个别有两种选项：针对每一个问题都用一个特定的形式去解决，比方：针对镜像就拿一个服务器专门去扫描镜像；针对容器就给每一个机器独自部署一个 agent；针对仓库就拿一个专门的工具扫描近程仓库镜像。通过产品去解决云原生平安的问题。

在面对盘根错节的云原生对象时，咱们能够发现，存在着所谓技术基石的概念，这些概念撑持着整个宏大的云原生技术体系。找到基石就是找到平安的切入点。

以根底对象进行粒度切割之后，会发现根底对象有大量的差异化实现，比方容器运行时就有：Docker/containerd/podman 等等，不可能每一种差异化实现都非凡解决，因而须要进行标准化的适配。

资产是平安危险的指南针，然而云原生对象之间关系比较复杂，比方仓库和镜像之间，镜像和容器之间，容器和集群之间，都存在数据关联关系。

假如咱们当初收到了某一个和 Pod 产生的安全事件 (如某个 Pod 下面有反弹 shell)，那基于 Pod 登程能够关联到的数据是十分多的，这个时候更重要的是进行取舍。对于理论的平安经营人员而言，反弹 shell 的解决流程须要先止损，因而 Pod 必定须要先关联到能够定位相干运行资源的资产，比方 node/container，而对于 image，关联的优先级反而没有那么高。咱们再来看一个例子，假如咱们要将镜像扫描集成到 CI/CD 的自动化构建流程当中，咱们应该怎么进行告警？首先有一个前提条件是，CI/CD 的数据量是十分大的，基本上一个成熟我的项目可能每天就要触发上千次的 pipeline。这种状况下，应该怎么进行数据取舍？最好的做法是将宏大的数据绑定到 CI/CD 平台的每一个 pipeline 中，而产品侧只留粗统计粒度的告警。这样做的益处在于，保障了产品侧告警及时性的同时，最大限度的交融进了 DevOps 的开发流程当中。

对于面向外围对象的安全策略，方才咱们提到云原生平安对象有很多，比方：代码仓库，它其实也算是一个云原生的一个对象。然而为什么咱们不针代码仓库做平安检测呢？起因很简略，那是别的产品须要去做的事件。咱们说的下层的货色都是去衍生镜像的，比方：CI/CD 它会去构建镜像；或者说代码仓库和 dockerfile 它会去 build 一个镜像。但咱们外围检测的对象其实还是镜像，而不是咱们的 CI/CD，也不是咱们的代码平台。咱们只有保障外围对象的平安就行了，比方：说针对镜像，咱们保障镜像的平安。因为镜像实质就是一个文件系统。所以这种状况，咱们只有去针对他的文件进行扫描就行了。那对于容器来说的话，除了蕴含镜像所面临的平安危险之外，还包含像网络，咱们要去做 TCP/IP 的审计，做 DNS 流量的审计，过程咱们要去做命令审计，去做容器逃逸的剖析。以及这个配置、挂载，有没有挂载一些不平安的目录，有没有开一些不应该开的 capability，或者以一个特权模式去启动。在文件网络过程之外，咱们能够把它形象起来，而后进行一个这个行为模式的学习，一些常见的容器比如说 Nginx，其实它产生的过程是十分固定的，如果某一天一个 Nginx 过程底下呈现了一个 bash 的过程，那它肯定是被黑了，以上就是容器这部分。咱们往左边看，能够看到最下面是集群相干的，集群的话它可能会关联到镜像、IAC，以及集群自身的组件，比如说 api server。针对 api server 咱们能够做审计剖析，举个例子，当初咱们用一个叫 CDK 的工具去创立一个后门，那咱们能够用 api server 的 audit 去发现有人用 CDK 去创立这么一个后门，这个更多是抛砖引玉。又比如说 IAC，它自身也是个对象，蕴含了 dockerfile、docker-compose、K8s、nomad 等等。针对 IAC 做配置检测，有没有将一些咱们认为敏感的目录挂载进去。以及最初是基础设施，我集体认为检测视角更多的须要放到主机层面的检测视角，以上就是对于平安治理的一些想法。

回馈开源社区，咱们作为开源生态拥抱者在 Github 凋谢了两个我的项目。第一个我的项目是 libVeinMind，是一个容器平安的 SDK，它能够帮忙咱们疾速实现一些平安检测，比方扫描镜像或者容器时间接应用即可，不须要本人独自写一套残缺的底座。另一个我的项目是容器平安工具集 veinmind-tools，以宿主加插件的模式运行，蕴含歹意文件扫描、敏感信息扫描等十余种插件。大家能够扫描左侧二维码退出探讨群进行具体交换。

问脉，是长亭旗下的旁路云原生平安平台。为了给用户提供零侵入以及高效的产品体验，以开源社区为生态载体，以技术积攒为驱动所打造的。相比于牧云来说，问脉最大的特点就是无需在业务宿主装置探针，以旁路模式检测云原生威逼危险。目前已凋谢收费的私有化部署版本，欢送体验试用。这次分享是从一个宏观的角度，大抵跟大家介绍和探讨了云原生平安趋势的演进，在今后的分享中，咱们会从宏观角度讲一些技术方面细节的干货！心愿营造云原生社区良好的探讨气氛，让咱们一起学习，共同进步！大家能够继续追更，敬请期待！咱们下期见！