云原生已然成为当今时代潮流，当下许多业务都是构建在云原生之上。而不断恶劣的网络环境又给云原生带来了威胁，许多大厂应国家号召每年需要进行红蓝对抗，开展护网行动，然而作为开发者又能在当前环境下做些什么呢？
官方提倡 k8s 云原生安全模型方案 - 4C 云原生安全模型(The 4C's of Cloud Native security)。该模型划分了4个层级，每一层都基于下一层。四个层级分别是 云提供商， 集群，容器，代码。
要求 Cloud 层提供基础设施级别的安全性保证，包括 API Server 的网络访问控制、节点的网络访问控制、K8S 访问云提供商 API 的限制(最小权限集合)，ETCD 的访问限和加密存储。实际上，ETCD 基本都是托管云服务商，开发者能做的就是设置好 IP 白名单和安全组。
集群层关注两个方面，首先是集群支撑组件的安全性。更多的是认证和授权方面，集中体现在 API Server 的访问。K8S 采用 RBAC 管理不同身份间对资源的访问权限。提倡最小化权限来为不同的应用提供不同的 Service Account。关闭API Server 的匿名访问和取消挂载 Service Account Token 到容器内部，是防止从集群内部攻击集群的重要手段。其次，就是集群中的应用的安全性。这点可以关注 Pod 安全策略和网络安全策略以及集群的服务质量限制。Pod 的安全限制更多是特权方面。这里涉及到容器运行时的原理。容器本身是宿主机上的受限制的进程，使用不当，容易造成逃逸。一来需要关注是否有特权，特别是特权容器，该类型容器内的 Root 拥有外部物理机的 Root 权限，可以对宿主机造成灾难性的后果；二来关注挂载路径；三来关注使用的网络模式，Host 模式则非常危险。网络策略方面则由 Network Policy 来提供保障，需要 CNI 插件。通常用来配合封禁容器对云主机元数据的访问，阿里云有对该情况给出指引。
容器层面，更多的是保障供应链的安全性。结合云厂商提供的容器镜像扫描来发现镜像的安全漏洞,结合镜像签名来保证镜像的完整性和安全性。当然也可以采用更强有力的隔离手段。例如容器运行时类。
代码层面则不展开，无非是代码扫描 + 模拟攻击。
