云安全攻防 | 云原生安全及Kubernetes

随着美国、英国、日本以及欧盟各国均提出了在电子政务中引入云计算技术与服务，利用云计算成本低、可靠性及灵活性高的特点提升电子政务的应用效能。我国政府也积极跟进，《中华人民共和国国民经济和社会发展第十二个五年规划纲要》中明确指出要“大力推进国家电子政务建设，加强云计算服务平台建设，构建下一代信息基础设施”。《国家电子政务“十二五”规划》中明确要求“建设完善电子政务公共平台，全面提升电子政务技术服务能力”。工业和信息化部于2012年发布《基于云计算的电子政务公共平台顶层设计指南》，开始正式推动政务云相关工作。

因此在红蓝对抗中，传统内网攻防的手法和技巧虽然依旧可以使用，但是容器技术所构建起来的是全新的内网环境，特别是当企业政府引入服务网格等云原生技术做服务治理时，整个内网和IDC内网的差别就非常大了。对此，本系列文章将主要研究云原生安全攻防有关内容，依托Kubernetes作为实验环境，深入研究探讨有关云原生安全攻防的理论知识与实战技术。

云原生（Cloud Native）这个词汇由来已久，以致于何时出现已无据可考。云原生开始大规模出现在受众视线中，与 Pivotal 提出的云原生应用的理念有着莫大的关系。我们现在谈到云原生，更多的指的是一种文化，而不具象为哪些技术体系。

早在 2015 年 Pivotal 公司的 Matt Stine 写了一本叫做 迁移到云原生应用架构 的小册子，其中探讨了云原生应用架构的几个主要特征：

到了 2015 年 Google 主导成立了云原生计算基金会（CNCF），起初 CNCF 对云原生（Cloud Native）的定义包含以下三个方面：

到了 2018 年，随着近几年来云原生生态的不断壮大，所有主流云计算供应商都加入了该基金会，且从 Cloud Native Landscape 中可以看出云原生有意蚕食原先非云原生应用的部分。CNCF 基金会中的会员以及容纳的项目越来越多，该定义已经限制了云原生生态的发展，CNCF 为云原生进行了重新定义。

以下就是 CNCF 对云原生的重新定义（中英对照）：

云计算的发展史就是一部云原生化的历史。Kubernetes  开启了云原生的序幕，服务网格 Istio 的出现，引领了后 Kubernetes 时代的微服务，serverless  的再次兴起，使得云原生从基础设施层不断向应用架构层挺进，我们正处于一个云原生的新时代。

云原生主要包括容器、不可变基础设施（基础设施即代码）、弹性服务编排、微服务、开发运营一体化（DevOps）、CI/CD、Serverless 等技术。

云原生安全作为一种新兴的安全理念，强调以原生的思维构建云上的安全建设、部署与应用，即云客户不需要进行额外的安全部署或配置就天然具备安全能力。云原生安全主要包括容器安全、微服务安全、DevSecOps、Serverless安全等。其中容器安全又包括容器本身的安全、镜像安全、编排（如 K8s）安全、注册安全、宿主操作系统风险等。Serverless 安全的本质是应用程序安全，因此首先要关注函数本身的安全，比如函数代码漏洞、依赖库的漏洞、认证授权及访问控制等。当然 Serverless 厂商视角除了保证 Serverless 运行时及以下各层的安全以外，还需要具备识别和阻止通过 Serverless 发起攻击的恶意使用行为的能力。

图 来自TSRC《云原生——容器和应用安全运营实践思考》

Kubernetes 是 Google 于 2014 年 6 月基于其内部使用的 Borg 系统开源出来的容器编排调度引擎，Google 将其作为初始和核心项目贡献给 CNCF（云原生计算基金会），近年来逐渐发展出了云原生生态。

Kubernetes也被称作k8s 之所以简称为k8s 是因为从 k 字母到s 字母之间有8个字母，它是一个开源系统，支持在任何地方部署、扩缩和管理容器化应用，Kubernetes 是希腊语，意思是“船长”，Kuberentes 可以说是乘着 Docker 和微服务的东风，一经推出便迅速蹿红，它的很多设计思想都契合了微服务和云原生应用的设计法则，这其中最著名的就是开发了 Heroku PaaS 平台的工程师们总结的Twelve-factor App了。

Kubernetes 的目标不仅仅是一个编排系统，而是提供一个规范用以描述集群的架构，定义服务的最终状态，使系统自动地达到和维持该状态。Kubernetes 作为云原生应用的基石，相当于一个云原生操作系统，其重要性不言而喻。

云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。

 ——CNCF（云原生计算基金会）

此不赘述，更多Kubernetes知识推荐参考 《Kubernetes 中文指南/云原生应用架构实战手册》。

您可以通过以下方式使用本书：

以 Kubernetes  为例，容器与容器之间的架构与传统的IDC机房内网有较大差别。虽然大部分传统IDC机房内网的攻击手法依然可以使用，但是容器技术所构建起来的是全新的架构环境，如果还是刻舟求剑，依然使用传统IDC机房内网的攻击手法就会收效甚微。因此了解一下  Kubernetes  架构的大致设计是非常重要的。

K8S主体架构如下图：

图 Kubernetes架构

用户可以通过 API接口. UI界面和命令行来访问k8S 的Master, 之后Master依据接収的请求对Node上面的容器做新增,更新或者删除的操作，同时容器的镜像又依赖于镜像仓库，需要从镜像仓库拉取所需的镜像, 同时需要将自定义的镜像保存到镜像仓库供容器来使用。

Master节点是集群的控制节点,负责整个集群的管理和控制，基本上所有的控制指令都是发给Master的，并且他来负责调度Node来具体执行命令，通常生产环境Master都是部署在单独的服务器，建议使用3台以上的奇数服务器做冗余，因为’首脑’ 宕机整个集群都会崩溃。

图 Master架构

Node节点是作为K8S中的工作负载节点，Node节点接収Master节点分配的一些任务。

Node的关键组件：

kubelet：负责对pod(POD是一组  )对应容器的创建,启停等一系列的任务，kubelet时刻watch着Mater中的API Server中的资源变动，当有和自己相关的任务的时候就会调用Docker执行具体的任务。

kube-proxy：用于实现 K8S Service(需要提供的服务) 的通信和负载均衡。

Docker Engin： docker引擎，负责Node于和容器有关的操作，K8S原生支持Docker作为容器引擎，如果要使用其他容器引擎则需要使用对应接口集成。

Pod : K8S不是直接运行的容器，而是操作Pod，把Pod作为原子单元管理，一个Pod里面可能会运行多个容器，Pod里面运行的多个容器被捆绑在一起被统一调度不可分割，一个Pod的所有容器只能同时运行在一个Node 上。

图 Node架构

Pod 是可以在 Kubernetes 中创建和管理的、最小的可部署的计算单元。

Pod（就像在鲸鱼荚或者豌豆荚中）是一组（一个或多个）容器；这些容器共享存储、网络、以及怎样运行这些容器的声明。Pod中的内容总是并置（colocated）的并且一同调度，在共享的上下文中运行。Pod 所建模的是特定于应用的“逻辑主机”，其中包含一个或多个应用容器，这些容器相对紧密地耦合在一起。在非云环境中，在相同的物理机或虚拟机上运行的应用类似于在同一逻辑主机上运行的云应用。除了应用容器，Pod 还可以包含在 Pod 启动期间运行的 Init 容器。你也可以在集群中支持临时性容器的情况下，为调试的目的注入临时性容器。

图 Pod架构

pod里面有一个或者多个容器，常见的容器有docker容器，containerd容器，除了 Docker 之外，Kubernetes 支持 很多其他容器运行时， Docker 是最有名的容器运行时，使用 Docker 的术语来描述 Pod 会很有帮助。

Pod 的共享上下文包括一组 Linux 命名空间、控制组（cgroup）和可能一些其他的隔离方面， 即用来隔离 Docker 容器的技术。在 Pod 的上下文中，每个独立的应用可能会进一步实施隔离。就 Docker 概念的术语而言，Pod 类似于共享命名空间和文件系统卷的一组 Docker 容器。

1.《OReillyServerless Security》https://www.oreilly.com/library/view/serverless-security/9781492082538/

2.《Kubernetes 中文指南/云原生应用架构实战手册》https://jimmysong.io/kubernetes-handbook/

3.《Kubernetes(K8S)架构1(Master,Node和Pod)》https://blog.csdn.net/qq_21047625/article/details/90180406

4.《云原生——容器和应用安全运营实践思考》https://security.tencent.com/index.php/blog/msg/200