云原生安全模型与实践

Posted 2021-04-03 玉符科技

在传统的研发中，我们经常关注的「安全」包括代码安全、机器（运行环境）安全、网络运维安全，而随着云原生时代的到来，如果还按原有的几个维度切分的话，显然容易忽略很多云原生环境引入的新挑战，我们需要基于网络安全最佳实践—— 纵深防御原则，来逐步剖析「云原生的安全」，并且对不同层次的防御手段有所了解，从而建立自己的云原生安全理念，真正搭建一个内核安全的云原生系统。

注：“纵深防御”，指在计算机系统中的多个层面使用多种网络安全技术，从而减少攻击者利用关键业务资源或信息泄露到系统外部的总体可能性。在消息传递和协作环境中，纵深防御体系可以确保恶意攻击活动被阻止在基础结构内的多个检查点，降低了威胁进入内部网络的可能性。

以    系统为例，我们把一个云原生系统安全模型分为 4 个层面，由外至内分别是：云/数据中心/网络层、集群层、容器层、代码层，如下图所示：

 

对于这里安全模型的每一层，都是单向依赖于外层的。也就是说，外层的云、集群、容器安全如果做得好，代码层的安全就可以受益，而反过来，我们是无法通过提高代码层的安全性来弥补外层中存在的安全漏洞或问题。

基于上述这一点原理，我们的纵深防御策略是「自外而内」地进行“设防”。

一、云/数据中心/网络层安全

这一层也可以称之为基础设施安全，不管从何角度，公有或私有云或企业数据中心以及对应的网络安全，是 K8s 集群最根本的安全基础，如果这一层存在安全漏洞或者过于脆弱，则整个系统都不能在此基础上保证组件的安全。

我们除了需要防御传统的攻击，如 ARP 伪装、DDOS、网络层各类报文等攻击，应该针对 Kubernetes 集群采取以下保护措施：

1. 不允许在 Internet 上公开对 Kubernetes 管理平台（Control Plane）的所有访问，同时仅开放部分可信 IP 可以访问 Kubernetes 管理 API。

2. 所有节点只暴露指定的端口，包括对管理平台的内部端口和来自 NodePort 和 LoadBalancer 类型的 Kubernetes 服务的连接，并且不应该直接暴露到 Internet。

3. 通过云提供商或机房的网络层安全组（例如 AWS 的 Security Group）对管理平台以及节点授予最小权限控制：

4. 对etcd（Kubernetes 的基础存储）的访问进行严格控制（仅允许来自集群管理平台的访问），应强制所有连接都使用TLS，并确保所有信息都是在持久化层被加密的（Encryption at rest）。

 

二、集群层

保护 Kubernetes 集群有两个主体需要关注：

• 集群与组件

• 运行的服务或应用

保护 Kubernetes 集群组件与服务或应用

针对这两个主体的保护，我们的保护可以分为 4 大块：管理 API 的访问控制、Kubelet 的访问控制、Runtime（运行时）工作负载或用户功能的访问控制、集群组件的安全漏洞防护，如下图所示。

1.  管理 API 的访问控制

     a.      强制 TLS 保护传输层

     b.      强制 API 认证

     c.       强制 API 授权机制（RBAC）

2. Kubelet 的访问控制

     a.      生产环境启用身份验证

     b.      身份授权(RBAC)

     c.       强制 TLS 保护传输层

3. Runtime（运行时）工作负载或用户功能的访问控制

     a.      限制使用特权容器                

     b.      合理限制资源负载

     c.       防止加载非必要内核模块

     d.      限制 Pod 越权访问其他节点

     e.      基础数据凭证的访问控制            

4. 集群组件的安全漏洞防护

     a.      禁止未授权访问 etcd 

     b.      启用审核日志记录

     c.       定期轮换基础架构凭证

     d.      定期升级修复漏洞

三、容器层

到了这一层，由于跟 Kubernetes 特性不是强相关，我们能提供一些通用的安全措施和建议：

容器安全的关注领域	安全策略或措施
容器漏洞扫描和操作系统相关安全性	在持续集成（Continuous Integration）的容器构建过程，必须进行容器漏洞的安全扫描。
容器 Image 镜像的签名	对所有 repo 的 Image 镜像进行签名，防止镜像（源、实例）被篡改。
特权用户（例如 root）的禁用	最小权限原则在容器内部创建用户。

 

四、代码层

程序代码层是最容易受攻击，但也是最可控的部分之一。虽然一般负责这块安全的人员不一定是运维开发（DevOps），可能是专门的安全工程师（Sec Eng），但有一些基本共性理念和建议是可以互相借鉴的。

代码安全的关注领域	安全策略或措施
TLS 访问加密	所有 TCP 通信，需要提前进行 TLS 握手。可以通过istio的安全模块来确保所有 pod 之间的通讯都是 mTLS（服务器间双向验证）。
第三方依赖相关安全性	定期扫描应用程序的第三方库以了解已知的安全漏洞。每种编程语言都有一个自动执行此检查的工具。
静态代码分析	分析代码段中是否存在任何潜在的不安全编码实践。只要有可能，就应该使用可以扫描代码库的常见安全错误的自动化工具进行检查。
动态探测攻击	对服务持续自动化地进行一些常见服务攻击（包括 SQL 注入，CSRF 和 XSS）。

 

总体来说，云原生时代的这四层架构：云/数据中心/网络层、集群层、容器层、代码层，与传统架构比起来更加细化和更易受攻击。自外而内地践行每一层的安全最佳实践，我们的纵深防御才能算是成功的，每个在云原生技术上想长期获益的团队需要对此有共识。

 

参考资料：

[1]https://baike.baidu.com/item/%E7%BA%B5%E6%B7%B1%E9%98%B2%E5%BE%A1/8282191?fr=aladdin

[2]https://kubernetes.io/docs/concepts/security/overview/

[3]https://www.stackrox.com/post/2020/09/protecting-against-kubernetes-threats-chapter-8-lateral-movement/

作者介绍：陈伟嘉，毕业于加州大学尔湾分校，曾就职于Facebook、Splunk，现任玉符科技 CTO，负责玉符 IDaaS 技术架构设计和实现，带领研发团队从 0 到 1 实现产品自主研发，搭建无状态化支持、轻量化容器打包、运维自动化等微服务架构。