我们经常关注传统的研发「安全」包括代码安全、机器（运行环境）安全、网络运行维护安全，随着云原始时代的到来，如果仍按原始维度划分，显然很容易忽视云原始环境引入的许多新挑战，我们需要基于网络安全的最佳实践——深度防御原则逐步分析「云原生安全」，并且对不同层次的防御手段有所了解，从而建立自己的云原生安全理念，真正搭建一个内核安全的云原生系统。
这里安全模型的每一层都单向依赖于外层。也就是说，如果外层的云、集群和容器安全做得好，代码层的安全就会受益。相反，我们无法通过提高代码层的安全性来弥补外层的安全漏洞或问题。基于上述原则，我们的深度防御策略是「自外而内」地进行“设防”。
1.云/数据中心/网络层安全
这一层也可以称为基础设施安全。无论从哪个角度来看，公共或私有云或企业数据中心及相应的网络安全都是 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 集群有两个主体需要注意:
- 集群与组件
- 运营服务或应用
针对这两个主体的保护，我们的保护可以分为 4 大块：管理 API 的访问控制，Kubelet 的访问控制，Runtime(运行时)工作负载或用户功能访问控制，集群组件安全漏洞保护，如下图所示。
(1) 管理 API 访问控制
- 强制 TLS 保护传输层
- 强制 API 认证
- 强制 API 授权机制(RBAC)
- 生产环境启用身份验证
- 身份授权(RBAC)
- 强制 TLS 保护传输层
- 限制使用特权容器
- 合理限制资源负荷
- 防止不必要的内核模块加载
- 限制 Pod 越权访问其他节点
- 访问控制基本数据凭证的访问
- 禁止未经授权的访问 etcd
- 启用审核日志记录
- 定期轮换基础架构证书
- 定期升级修复漏洞
到了这一层，因为跟 Kubernetes 特性不相关。我们可以提供一些通用的安全措施和建议：
四、代码层
程序代码层是最容易受到攻击的部分，但也是最可控的部分之一。虽然一般负责这种安全的人员不一定是运维开发(DevOps)，可能是专门的安全工程师(Sec Eng)，但是有一些基本的共同想法和建议可以互相借鉴。
一般来说，与传统架构相比，云原生时代的四层架构：云/数据中心/网络层、集群层、容器层和代码层更详细，更容易受到攻击。只有从外到内地实践每一层的最佳安全实践，我们的深度防御才能成功。每个想从云原生技术中长期受益的团队都需要达成共识。
参考资料：
- https://baike.baidu.com/item/纵深防御/8282191fr=aladdin
- https://kubernetes.io/docs/concepts/security/overview/
- https://www.stackrox.com/post/2020/09/protecting-against-kubernetes-threats-chapter-8-lateral-movement/