当前位置:   article > 正文

云原生安全趋势演进大揭秘|云原生安全公开课第一期_tetragon 云原生

tetragon 云原生

在这里插入图片描述

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 等等。


接下来是第二部分“安全治理”,为什么讲这一部分呢?我个人认为云原生是一个比较新兴技术。现在很多甲方企业也好,乙方企业也好,在推进云原生过程当中,还是处于一个相当进行时的状态。不是所有业务线都能够完全涌入到这套生态里面。所以不管是甲方还是乙方的安全部门,我们要去做标准化的产品,都会发现这中间有很多很多的坑和问题。

在这里插入图片描述

其中“产品复杂度”就是最重要的一个问题。首先我们来聊一下这个事情,当我们需要去解决一家企业云原生安全问题的时候,我们希望用一个什么样的方式去解决它,一般有两种选项:

1.针对每一个问题都用一个特定的方式去解决,比如:针对镜像就拿一个服务器专门去扫描镜像;针对容器就给每一个机器单独部署一个 agent;针对仓库就拿一个专门的工具扫描远程仓库镜像。
2.通过产品去解决云原生安全的问题。

在这里插入图片描述

在面对错综复杂的云原生对象时,我们可以发现,存在着所谓技术基石的概念,这些概念支撑着整个庞大的云原生技术体系。找到基石就是找到安全的切入点。

在这里插入图片描述

以基础对象进行粒度切割之后,会发现基础对象有大量的差异化实现,比如容器运行时就有: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,以宿主加插件的模式运行,包含恶意文件扫描、敏感信息扫描等十余种插件。大家可以扫描左侧二维码加入讨论群进行详细交流。

在这里插入图片描述

问脉,是长亭旗下的旁路云原生安全平台。为了给用户提供零侵入以及高效的产品体验,以开源社区为生态载体,以技术积累为驱动所打造的。相比于牧云来说,问脉最大的特点就是无需在业务宿主安装探针,以旁路模式检测云原生威胁风险。目前已开放免费的私有化部署版本,欢迎体验试用。

这次分享是从一个宏观的角度,大致跟大家介绍和讨论了云原生安全趋势的演进,在今后的分享中,我们会从微观角度讲一些技术方面细节的干货!希望营造云原生社区良好的讨论氛围,让我们一起学习,共同进步!大家可以持续追更,敬请期待!我们下期见!


需要直播录屏、PPT的小伙伴请私信微信公众号“长亭百川云平台”: 「第一期直播录屏」、「第一期PPT」即可获取。


让我们一起学习、共同进步!若有收获,就点个赞吧~

声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/Li_阴宅/article/detail/803084
推荐阅读
相关标签
  

闽ICP备14008679号