随着 K8s 在生产和测试环境中用的越来越多，对安全性的关注也会越来越多，所以本次演讲主要是给大家分享以下内容：
- 了解 K8s 环境面临的安全风险
- 了解 K8s 提供的安全机制
- 改善 K8s 安全状况的最佳实践
本篇目录
K8s 安全风险
这张图是 CNCF 金融用户小组总结的 K8s 信任边界图，它把在 K8s 环境中的信任边界划分成三大块儿。
我们根据不同的攻击类型划分，首先最容易规避的就是来自外部的攻击。通常情况下，来自外部的攻击会有 2 种类型。
一种是系统层面的漏洞，需要及时更新，及时跟进 K8s 社区和安全领域相关的最新消息，可以很好的规避。
第二个是应用本身带来的渗透或者是提权的风险，业务部署在 K8s 之上，应用的漏洞可能造成容器越权或者容器逃逸之类的风险。
借助恶意容器进行攻击也比较常见，在使用容器的过程种主要会面临以下风险：
K8s 集群的规模变大，运维人员与终端用户也会变多，安全凭证的泄露，会对整个集群的安全造成威胁。
即使集群保护的非常好，在安全凭证没有泄漏的情况下，来自内部成员的恶意攻击也难以规避，即使是在测试环境也需要一定程度的租户隔离，避免来自内部的攻击、对数据的恶意访问。
K8s 安全机制
在 K8s 社区，安全问题的关注度是非常高的，在 K8s 的设计中，各组件都有安全相关的特性。在 API 认证层面，控制平面中各个组件之间，需要开启 mTLS 进行组件之间的互认证。
K8s 也支持丰富的认证、访问控制的机制，通常我们会借助 RBAC 对用户的权限进行限制。
K8s 还提供了针对容器能力的限制机制，我们可以通过 Security Context 去限制容器运行时的用户、用户组，对容器特权进行限制。
K8s 中 Pod Security Policy 可以为集群应用安全策略，但是这个特性会在 1.25 之后被后面提到的 pod security admission webhook 替代。这是 K8s 提供的安全策略机制，非常建议大家去深入了解。
我们还可以用到 Resource Quota 结合 request、limit 限制容器的资源用量，尽可能的利用 linux 提供的安全特性，针对网络、cpu、内存等资源进行用量的限制。Limit Range 可以帮助我们为 Pod 设置默认的资源限制。
除此之外，还可以针对 K8s 集群网络进行划分，通过 network policy 来支持网络隔离策略，设置黑名单或者白名单，为 namespace 去分配一独立的 IP 池。
我们可以借助 K8s 节点调度策略、污点管理，node selector 等机制去限制容器能够调度的节点，实现一定程度的物理隔离。
K8s 还有一些和安全相关的内容，一个是审计日志，需要在 kube-apiserver 中进行开启。然后是 Pod Security Admission Webhook，这将是一个新的特性，帮助我们为集群应用安全策略。最后就是和数据安全相关，我们可以借助 KMS 来加密 etcd 中的数据，在容器运行时进行解密。
K8s 安全最佳实践
K8s 安全最佳实践，大部分都是来自于社区用户和我们实际生产中环境中的经验总结。
上图是 K8s 社区的对云原生安全的安全总结，在云原生中主要分四个比较重要的层级：代码安全、容器安全，K8s 集群安全和云平台、数据中心的安全。
针对这四个层面的安全问题，有不同的解决策略。
代码安全往往可以通过以下方式进行应对，比如说应用之间的通讯，尽量使用 TLS 或 mTLS，保证数据的加密传输。即使集群中大部分都是可信的环境，TLS 带来的性能损耗我认为也是在可以承受的范围之内。
针对代码安全的增强，通常需要我们在在 CI 或 CD 过程中对代码进行扫描，对容器镜像进行扫描，对应用安全进行扫描，即使很多工具会存在误报的情况，但在大规模的项目中这些步骤是必不可少的。
容器安全方面，我们建议尽可能的使用可信的基础镜像，除此之外，尽可能去删掉不必要的二进制，避免基础镜像中操作系统漏洞带来的影响。
在容器运行的过程中尽可能的使用非 root 用户，除非是有特定的数据读写要求，可能会有一些问题。
- 集群安全：K8s 集群安全层面的建议，首先我们需要整理集群中所有关键组件的通讯矩阵，要知道哪些组件会用到哪些端口，比如说 K8s 控制平面常用的 10250,6443 端口等。对系统组件所用到的端口进行合理的管控，通过防火墙来提供最基础的保障。
- 数据安全：在 K8s 集群中我们可以实现或接入已有的 KMS 服务，对 etcd 中的数据进行加密，在 etcd 数据泄漏的情况下也可以保证集群中 secret 数据的安全。
- 网络安全：在 K8s 中我们可以借助 Network Policy 实现网络隔离，常用的网络插件 calico 和 Cilium 都可以很好的支持。不要开放不必要的端口，不仅是不对外开放端口甚至对于容器内部暴露的端口也要尽可能的去屏蔽。
- 针对所部署的应用安全：尽可能的为每一个部署到 K8s 的容器配置 Security Context，限制容器内的运行用户和容器特权，禁止其直接读取或读写整个宿主机的网络和文件。再就是 K8s 针对安全策略的的增强，我们可以利用一些安全策略管理工具如 Gatekeeper，为整个集群运用一些安全策略以抵抗风险。
KubeSphere 中的安全增强
KubeSphere 是一个构建在 K8s 之上的容器管理平台，我们针对 K8s 安全问题提供了以下增强：
1、借助可观测性组件增强异常的感知能力。借助日志、监控数据结合告警策略来提高异常感知的能力，增加数据的能见度。
2、支 Network Policy 实现网络隔离，支持 IP 池的管理。
3、支持接入 Kata Containers 等更安全的运行时。
4、KubeSphere 社区中开源的 KubeEye，是一个可以实现集群自动巡检的小工具，可以帮助我们扫描集群中存在的安全风险、不合理的配置等。
5、KubeSphere 提供了 Gatekeeper 的集成，并计划提供可视化的管理界面，实现安全策略的管理。
6、在 DevOps 流水线中我们可以集成代码、镜像等安全扫描工具。