在传统的研发中，我们经常关注的「安全」包括代码安全、机器(运行环境)安全、网络运维安全，而随着云原生时代的到来，如果还按原有的几个维度切分的话，显然容易忽略很多云原生环境引入的新挑战，我们需要基于网络安全最佳实践——纵深防御原则，来逐步剖析「云原生的安全」，并且对不同层次的防御手段有所了解，从而建立自己的云原生安全理念，真正搭建一个内核安全的云原生系统。
注：“纵深防御”，指在计算机系统中的多个层面使用多种网络安全技术，从而减少攻击者利用关键业务资源或信息泄露到系统外部的总体可能性。在消息传递和协作环境中，纵深防御体系可以确保恶意攻击活动被阻止在基础结构内的多个检查点，降低了威胁进入内部网络的可能性。
以某IDaaS系统为例，我们把一个云原生系统安全模型分为 4 个层面，由外至内分别是：云/数据中心/网络层、集群层、容器层、代码层，如下图所示：
对于这里安全模型的每一层，都是单向依赖于外层的。也就是说，外层的云、集群、容器安全如果做得好，代码层的安全就可以受益，而反过来，我们是无法通过提高代码层的安全性来弥补外层中存在的安全漏洞或问题。基于上述这一点原理，我们的纵深防御策略是「自外而内」地进行“设防”。
一、云/数据中心/网络层安全
这一层也可以称之为基础设施安全，不管从何角度，公有或私有云或企业数据中心以及对应的网络安全，是 K8s 集群最根本的安全基础，如果这一层存在安全漏洞或者过于脆弱，则整个系统都不能在此基础上保证组件的安全。
我们除了需要防御传统的攻击，如 ARP 伪装、DDOS、网络层各类报文等攻击，应该针对 Kubernetes 集群采取以下保护措施：
不允许在 Internet 上公开对 Kubernetes 管理平台(Control Plane)的所有访问，同时仅开放部分可信 IP 可以访问 Kubernetes 管理 API。 所有节点只暴露指定的端口，包括对管理平台的内部端口和来自 NodePort 和 LoadBalancer 类型的 Kubernetes 服务的连接，并且不应该直接暴露到 Internet。 通过云提供商或机房的网络层安全组(例如 AWS 的 Security Group)对管理平台以及节点授予最小权限控制： 对etcd(Kubernetes 的基础存储)的访问进行严格控制(仅允许来自集群管理平台的访问)，应强制所有连接都使用TLS，并确保所有信息都是在持久化层被加密的(Encryption at rest)。
二、集群层
保护 Kubernetes 集群有两个主体需要关注：
集群与组件 运行的服务或应用
保护 Kubernetes 集群组件与服务或应用：
针对这两个主体的保护，我们的保护可以分为 4 大块：管理 API 的访问控制、Kubelet 的访问控制、Runtime(运行时)工作负载或用户功能的访问控制、集群组件的安全漏洞防护，如下图所示。
管理 API 的访问控制
强制 TLS 保护传输层 强制 API 认证 强制 API 授权机制(RBAC)
Kubelet 的访问控制
生产环境启用身份验证 身份授权(RBAC) 强制 TLS 保护传输层
Runtime(运行时)工作负载或用户功能的访问控制
限制使用特权容器 合理限制资源负载 防止加载非必要内核模块 限制 Pod 越权访问其他节点 基础数据凭证的访问控制
集群组件的安全漏洞防护
禁止未授权访问 etcd 启用审核日志记录 定期轮换基础架构凭证 定期升级修复漏洞
三、容器层
到了这一层，由于跟 Kubernetes 特性不是强相关，我们能提供一些通用的安全措施和建议：
四、代码层
程序代码层是最容易受攻击，但也是最可控的部分之一。虽然一般负责这块安全的人员不一定是运维开发(DevOps)，可能是专门的安全工程师(Sec Eng)，但有一些基本共性理念和建议是可以互相借鉴的。
总体来说，云原生时代的这四层架构：云/数据中心/网络层、集群层、容器层、代码层，与传统架构比起来更加细化和更易受攻击。自外而内地践行每一层的安全最佳实践，我们的纵深防御才能算是成功的，每个在云原生技术上想长期获益的团队需要对此有共识。
文章来源网络，作者：运维，如若转载，请注明出处：https://shuyeidc.com/wp/223090.html<
