在传统研发中，我们往往关注的“安全”包括代码安全、机器（运行环境）安全、网络运维安全。如果把原来的几个维度分开，显然很容易忽略云原生环境引入的很多新挑战。我们需要根据网络安全的最佳实践——纵深防御原则，逐步分析“云原生安全”。构建云原生安全理念，真正构建内核安全的云原生系统。注：“纵深防御”是指在计算机系统的多个层次上采用多种网络安全技术，从而整体降低攻击者利用关键业务资源或向系统外泄露信息的可能性。在消息传递和协作环境中，纵深防御架构可以确保在基础设施内的多个检查点阻止恶意活动，从而降低威胁进入内部网络的可能性。以IDaaS系统为例，我们将一个云原生系统安全模型分为四层，从外到内分别为：云/数据中心/网络层、集群层、容器层、代码层，如下图所示：对于这个安全模型的每一层，都存在对外层的单向依赖。也就是说，外层的云、集群、容器的安全做好了，代码层的安全才能受益。相反，我们无法通过提高代码层或问题的安全性来弥补外层的安全漏洞。基于以上原则，我们的纵深防御策略是从外到内“设防”。1.云/数据中心/网络层安全这一层也可以称为基础设施安全。无论从哪个角度，公有云或者私有云或者企业数据中心以及相应的网络安全都是K8s集群最根本的安全基础。如果这一层存在安全漏洞或者过于脆弱，整个系统就无法保证在此基础上的组件安全。除了防御ARP伪装、DDOS、各类网络层攻击等传统攻击方式外，我们还应该对Kubernetes集群采取如下防护措施：互联网，同时只开放部分可信IP访问Kubernetes管理API。所有节点只暴露特定的端口，包括管理平台的内部端口和来自NodePort和LoadBalancer类型的Kubernetes服务的连接，不应该直接暴露在互联网上。通过云提供商或机房的网络层安全组（如AWS的安全组），对管理平台和节点进行最小权限控制：严格控制对etcd（Kubernetes的基础存储）的访问（只能从clustermanagementplatformisallowed），应强制所有连接使用TLS，并确保所有信息在持久层加密（Encryptionatrest）。2、集群层保护Kubernetes集群有两个主体需要注意：集群运行的服务或应用和组件保护Kubernetes集群组件和服务或应用：针对这两个主体的保护，我们的保护可以分为四大方面：管理API访问控制、Kubelet访问控制、Runtime（运行时）工作负载或用户功能访问控制、集群组件安全漏洞防护，如下图所示。（1）管理API的访问控制强制TLS保护传输层强制API认证强制API授权机制（RBAC）（2）Kubelet访问控制生产环境启用AuthenticationAuthenticationAuthorization（RBAC）强制TLS保护传输层（3）运行时（Runtime）对工作负载或用户功能的访问控制限制使用特权容器合理限制资源负载防止加载不必要的内核模块限制Pod对其他节点的非授权访问基础数据凭证的访问控制(4)集群组件安全漏洞防护禁止非授权访问etcd启用审计日志定期轮换基础设施凭证定期升级和修复漏洞3.容器层已经到了这一层。由于与Kubernetes特性没有强相关，我们可以提供一些通用的安全措施和建议：4.代码层程序代码层是最脆弱的，也是最可控的部分之一。虽然负责这方面安全的人不一定是DevOps，但可能是专门的安全工程师（SecEng），有一些基本的通用概念和建议可以参考。总的来说，云原生时代的四层架构：云/数据中心/网络层、集群层、容器层、代码层，比传统架构更加细化和脆弱。只有从外到内在每一层都实践最佳安全实践，我们的纵深防御才能被认为是成功的。从长远来看，每个想要从云原生技术中获益的团队都需要对此达成共识。参考：https://baike.baidu.com/item/%E7%BA%B5%E6%B7%B1%E9%98%B2%E5%BE%A1/8282191?fr=aladdinhttps://kubernetes。io/docs/concepts/security/overview/https://www.stackrox.com/post/2020/09/protecting-against-kubernetes-threats-chapter-8-lateral-movement/
