从0到1使用Kubernetes系列（八）：安全

Kubernetes 的安全是一个相当广泛的主题，涉及很多高度相关的内容。和探讨大部分安全性相关的问题一样，首先需要考虑威胁模型——谁可能攻击你的系统，以及他们如何做到这一点。这可以帮你确定安全工作的优先级。对于大多数 Kubernetes 应用有三类主要的攻击者：

1. 外部攻击者：当你在内部或云上部署应用时，你可能面临来自集群外的攻击。这类攻击者没有系统权限，所以会专注于公开的服务，会尝试获取访问权限并提升权限。
2. 泄露的容器：Kubernetes 集群通常运行着各种工作负载。攻击者也可能利用集群中运行的容器的漏洞进行攻击，在这种时候，要最大程度降低漏洞攻击影响到整个集群的风险。攻击者可以访问单个容器的资源，因此限制容器权限至关重要。
3. 恶意用户：Kubernetes 是一个多用户系统。攻击者可能拥有某用户的账户，并企图获得更多权限，这种情况比较复杂，要具体分析，需要限制不同用户的访问权限。

围绕云原生基础概念构建的模型可以帮你建立对 Kubernetes 安全的总体认识。下图将安全划分为四个层级，被称为云原生安全的4C模型。管理员将在不同的层次上应对三类攻击者。

4C 指的是云（Cloud）、集群（Cluster），容器（Containers）和代码（Code）

正如你在图中所看见的，4C 模型中每部分的安全性都是相互包含的。只依靠增强代码层次安全来预防云、集群和容器中安全漏洞是几乎不可能的。适当提高其他层的安全能力，就已经为你的代码提供强大的基础安全保障。下面将详细介绍这四部分内容。

Cloud

大多数情况下，云为 Kubernetes 集群提供可信的计算资源。如果云的基础设置是不可靠的（或以易受到攻击的方式配置），那就没有办法保证在这个基础上构建的 Kubernetes 集群的安全性。每一个云服务提供商都向他们的客户提供大量如何在其环境安全运行负载的建议。下面提供常用云服务厂商的安全文档链接，并且提供了构建安全 Kubernetes 集群的建议。

云服务提供商安全文档列表

云服务厂商	链接
阿里云	https://www.alibabacloud.com/trust-center
AWS	https://aws.amazon.com/security/
Google Cloud Platform	https://cloud.google.com/security/
Microsoft Azure	https://docs.microsoft.com/en-us/azure/security/azure-security

如果你运行在自己的硬件上或者其他云服务提供商，请查阅文档获取最佳安全实践。

通用的安全建议

• 理想情况下，不开放 Kubernetes Master 节点公网访问，并且限制能够访问集群 Master 节点的 IP 地址。

• 通过网络安全组等配置工作节点只接受 Master 节点上指定端口的连接，并且接受 Kubernetes 中服务类型为 NodePort 和 LoadBalancer 的连接。如果可能，这些节点也不应该暴露在公网中。

• Kubernetes 访问云服务提供商的 API，每一个云服务提供商都赋予 Kubernetes 的 Master 和 Node 不同的权限。该访问权限遵循其管理资源所需资源的最小权限原则。

• 访问 etcd， 只有在 master 节点中通过 TLS 可以访问 etcd。

• 在所有可能情况下，对停用状态的的驱动设备加密。ectd 拥有整个集群的状态（包括密钥信息），因此对其磁盘要在其停用的时候加密。

Cluster

Kubernetes 是一个复杂的系统，下图展示了一个集群不同的组成部分，为了保证集群整体的安全，需要仔细保护每一个组件。

将需要注意保护的集群组件划分成两个部分：

1. 保护组成集群的可配置组件
2. 保护运行在集群中的应用

集群的组件

1. 控制对 Kubernetes API 的访问

   使用 TLS 进行安全通讯。Kubernetes 期望默认情况下使用 TLS 对集群中所有 API 通信进行加密，大多数安装方式都会创建必要的证书并分发给集群组件。

   API 认证。在安装集群时，为API服务器选择与通用访问模式匹配的身份验证机制。例如，小型单用户集群可能希望使用简单的证书或静态Bearer令牌方法。较大的群集可能希望集成现有的OIDC或LDAP服务器，以将用户细分为多个组。更多有信息请参考认证。

   API 授权。一旦通过身份验证，每个API调用也都有望通过授权检查。Kubernetes 附带了一个集成的基于角色的访问控制（RBAC）组件，该组件将传入的用户或组与捆绑到角色中的一组权限进行匹配。这些权限将动词（get，create，delete）与资源（pods，service，nodes）结合在一起，并且可以是命名空间或集群作用域。提供了一组现成的角色，这些角色根据客户端可能要执行的操作提供合理的默认责任分离。更多有关信息请参考授权

2. 控制对 Kubelet 的访问。

   Kubelet 在端口10250和10255上提供小型 REST API。端口10250是读/写端口，而10255是具有API端点子集的只读端口。这些端点授予对节点和容器的强大控制权。默认情况下，Kubelets允许未经身份验证对此API进行访问。生产集群应启用 Kubelet 身份验证和授权，可以通过设置 --read-only-port=0 来禁用只读端口，但是10250 端口用于系统指标收集和其他重要功能，所