近年来，云原生的发展可谓迅猛，据Gartner分析，到2025年，超过85%的企业将接受云优先原则，超过95%的新数字工作负载将被部署在云原生平台上。但其实，云原生不仅是一项技术，也是一种服务、一种思维方式。就国内企业而言，云原生目前的接受程度如何？全新的架构体系带来了哪些新的安全风险？本期话题就围绕云原生下的安全威胁与挑战，就相关问题展开讨论。

1.无论是容器、微服务架构、持续性交付等方面，现有技术条件下的云原生带来了哪些新的攻击面？构建云原生应当遵顼哪些安全原则？

A1：

其实题干上也说了一部分，容器运行时、容器编排平台、微服务架构Web应用、服务网格、Serverless，这些都是比较主要的攻击面。

A2：

云原生因面向微服务架构、基于API的特点，决定了传统以终端或主机层安全防护策略需要向以容器为主要载体的微服务转移，成为安全防护的重点；应用风险威胁或者数据泄漏需要关注API安全。

云原生注重敏捷持续交付，在DevOps过程中每一个环节都要考虑安全因素，对安全的需求和要求也提高了，安全左移的成熟度直接决定了云原生下能否具有安全属性的业务。

A3：

引入的应用或者系统越多，出现漏洞的可能性越大的，不管是配置错误还是应用漏洞。上云呢运维便捷了很多，但是配置不当的话造成的影响也会更大，因为相当于一个核心系统。

安全部门的工作一方面是维持正常运转，另一方面就是发现潜在风险点。像前面说到的配置错误更像是潜在风险点，发不发现完全看攻击者能力。

Q：云原生内以Docker为例进行容器运行时存在哪些安全问题？

A1：

容器安全的风险点主要从几个方面去考虑吧：镜像安全风险、镜像仓库安全风险、编排工具安全风险、容器运行安全风险、容器主机安全风险。

A2：

之前在FreeBuf看到过一篇讲Docker容器安全性分析的文章，把可能存在的技术性安全风险分为镜像安全风险、容器虚拟化安全风险、网络安全风险等类型，可以参考一下。

A3：

说到镜像，使用Docker的新手很可能会创建不安全的镜像，攻击者很容易借此接管容器，一个是用了过时或者不安全的基础镜像，里面往往一堆漏洞；一个是启动的应用程序以 root 用户身份运行，这样攻击者一旦利用漏洞取得Shell 权限，就可以接管 Docker 守护程序所运行的主机；一个是如果镜像包含CURL、APT等工具，一旦攻击者获得了某种访问权，就可以通过这些工具加载恶意软件。

Q: 云原生编排组件为何存在非管理员账户提权风险?

A：

首先要明确，是编排工具自身漏洞导致非管理员账户提权，举个例子：CVE-2018-1002105，这是一个Kubernetes的权限提升漏洞，攻击者可在拥有集群内低权限的情况下提升至Kubernetes API Server权限；通过构造一个对Kubernetes API Server的特殊请求，攻击者能够借助其作为代理，建立一个到后端服务器的连接，攻击者就能以Kubernetes API Server的身份向后端服务器发送任意请求，实现权限提升。

2. 现在不少企业在云原生上落地还存在一定难度，这个难点在哪？云原生对技术能力提出了哪些新要求？

A1：

根据CNCF的云原生定义：云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中构建和运行可弹性扩展的应用，代表性的技术：容器、服务网格、微服务、不可变基础设施和声明式API。

A2：

现阶段，大多数组织的人力架构，配不上Devops，配不上微服务，也配不上云原生。别的不说，单元测试和自动化测试的覆盖率有多少？从需求到研发到上线能在pineline里全完成可追溯吗？

A3：

现在云原生总的说来还是一个很新的概念，内含技术庞杂，对于传统企业学习成本过高，要招到熟练这一块的人才又很难，不太容易因地制宜、规模地应用。

A4：

说到人才，其实思路转变才是难点，因为很多开发人员掌握的架构模型知识都是以前传统的那一套，云原生的技术理念还是太新了，过去传统的开发流程惯性对运用云原生阻力较大。现在云原生的相关概念倒是提的不少，但是一套相对系统完善的培训体系还是太少。

A5：

还有一个就是长期的迁移过程，比如很多企业仍然采用传统 IDC 做基础设施，为了实现云原生的微服务化，整合云端后台这些优势服务，需要对系统进行重构。但大规模的系统迁移过程会比较漫长，期间系统是处在一种混合状态，既有运行在容器中的微服务，也有在容器外运行的，甚至是运行在传统非云基础设施上的服务。这种混合状态会对开发和维护提出更高的挑战，新迁移系统和遗留系统的互通，分布的迁移过程都要通过精心的设计。

A6：

云原生是一种构建和运行应用程序的方法，是一套技术体系和方法论。云原生（CloudNative）是一个组合词，Cloud+Native。Cloud表示应用程序位于云中，而不是传统的数据中心；Native表示应用程序从设计之初即考虑到云的环境，原生为云而设计，在云上以最佳姿势运行，充分利用和发挥云平台的弹性+分布式优势。

总而言之，符合云原生架构的应用程序应该是：采用开源堆栈（K8S+Docker）进行容器化，基于微服务架构提高灵活性和可维护性，借助敏捷方法、DevOps支持持续迭代和运维自动化，利用云平台设施实现弹性伸缩、动态调度、优化资源利用率。

3.如何判断企业是否真的需要云原生？现阶段云原生、微服务是概念营销，还是能真正实现业务价值？

A1：

云原生注定了必须是面向云环境，以持续敏捷交付的业务才具有适用性，适合自己的方案才是最好的，传统架构和业务并不适配云原生。

A2：

国内现在这个阶段，用处还比较有限。如果你用的是非常好的一个公有云服务，那么云原生可能还是不错的。自建的话不要自找苦吃，云原生会成为公司后续往公有云迅速迁移的一个梯子。

我有个做云原生安全的朋友，他的苦恼在于，愿意为安全买单的客户都没有云原生。当然可能海外会有一些客户，但是这个比例跟用云原生但是不想买单，和愿意为安全买单但是不用云原生的海外群体比，比例肯定还是很小的。

A3：

原生云的出现，其实是为了解决运维难的痛点，云技术发展之后，才出现了原生云安全的概念，其实主要就是云的宿主这部分的安全。对企业来说，上不上云，一是看自己需求，二是看有没有监管要求。

A4：

现在云内安全是重点需要解决的。

A5：

云内，根据我司的使用情况，好多手段不好用，比如全流量无法实现，比如网络拓扑无法改变，全靠厂商。某些云上的拓扑环境并不合理，但无法改变。既然企业要选择上云 那就应该把云上安全的预算列出来，因为云上的运维确实比自建 IDC 是要方便。

——————————————————

本期精彩观点到此结束啦~此外，FreeBuf会定期开展不同的精彩话题讨论，想了解更多话题和观点，快来扫码免费申请加入FreeBuf甲方群吧！

加入即可获得FreeBuf月刊专辑，还有更多精彩内容尽在FreeBuf甲方会员专属社群，小助手周周送福利，社群周周有惊喜，还不赶快行动？

申请流程：扫码申请-后台审核（2-5个工作日）-邮件通知-加入会员俱乐部

如有疑问，也可扫码添加小助手微信哦！