云原生安全概述
本概述定义了一个模型，用于在CloudNative安全性上下文中考虑Kubernetes安全性。
Warning:此容器安全模型只提供建议，而不是经过验证的信息安全策略。
云原生安全的4个C
你可以分层去考虑安全性，云原生安全的4个C分别是云（Cloud）、集群（Cluster）、容器（Container）和代码（Code）。
Note:这种分层方法增强了深度防护方法在安全性方面的防御能力，该方法被广泛认为是保护软件系统的最佳实践。
云原生安全的4C
云原生安全模型的每一层都是基于下一个最外层，代码层受益于强大的基础安全层（云、集群、容器）。你无法通过在代码层解决安全问题来为基础层中糟糕的安全标准提供保护。
云
在许多方面，云（或者位于同一位置的服务器，或者是公司数据中心）是Kubernetes集群中的可信计算基。如果云层容易受到攻击（或者被配置成了易受攻击的方式），就不能保证在此基础之上构建的组件是安全的。每个云提供商都会提出安全建议，以在其环境中安全地运行工作负载。
云提供商安全性
如果你是在你自己的硬件或者其他不同的云提供商上运行Kubernetes集群，请查阅相关文档来获取最好的安全实践。
下面是一些比较流行的云提供商的安全性文档链接：
IaaS 提供商链接
Alibaba Cloud
Amazon Web Services
Google Cloud Platform
IBM Cloud
Microsoft Azure
Oracle Cloud Infrastructure
VMWare VSphere
基础设施安全
关于在Kubernetes集群中保护你的基础设施的建议：
Kubernetes 基础架构关注领域建议
通过网络访问 API 服务（控制平面）
所有对 Kubernetes 控制平面的访问不允许在 Internet 上公开，同时应由网络访问控制列表控制，该列表包含管理集群所需的 IP 地址集。
通过网络访问 Node（节点）
节点应配置为仅能从控制平面上通过指定端口来接受（通过网络访问控制列表）连接，以及接受 NodePort 和 LoadBalancer 类型的 Kubernetes 服务连接。如果可能的话，这些节点不应完全暴露在公共互联网上。
Kubernetes 访问云提供商的 API
每个云提供商都需要向 Kubernetes 控制平面和节点授予不同的权限集。为集群提供云提供商访问权限时，最好遵循对需要管理的资源的最小特权原则。Kops 文档提供有关 IAM 策略和角色的信息。
访问 etcd
对 etcd（Kubernetes 的数据存储）的访问应仅限于控制平面。根据配置情况，你应该尝试通过 TLS 来使用 etcd。更多信息可以在etcd 文档中找到。
etcd 加密
在所有可能的情况下，最好对所有存储进行静态数据加密，并且由于 etcd 拥有整个集群的状态（包括机密信息），因此其磁盘更应该进行静态数据加密。
集群
保护Kubernetes有两个方面需要注意：
集群组件
如果想要保护集群免受意外或恶意的访问，采取良好的信息管理实践，请阅读并遵循有关保护集群的建议。
集群中的组件（你的应用）
根据你的应用程序的受攻击面，你可能需要关注安全性的特定面，比如：如果你正在运行中的一个服务（A服务）在其他资源链中很重要，并且所运行的另一工作负载（服务B）容易受到资源枯竭的攻击，则如果你不限制服务B的资源的话，损害服务A的风险就会很高。
容器
容器安全性不在本指南的探讨范围内。下面是一些探索此主题的建议和连接：