1.4.3　微服务安全

Kubernetes被设计为用于运行大型关键系统，在这些系统中，安全性至关重要。微服务的安全性通常比单体系统更具挑战性，因为前者有很多跨边界的内部通信。同样，微服务鼓励敏捷开发，这会导致系统将持续不断地变化。你无法确保仅实施一次安全策略就使系统一直处于稳定状态，必须不断地使系统的安全性适应这些变化。Kubernetes内置了一些了用于安全开发、部署和操作微服务的概念和机制，但仍然需要采用安全最佳实践，例如最小特权原则、深度安全以及最小化影响范围。下面会介绍Kubernetes的一些安全功能。

1.命名空间

命名空间可以将集群的不同部分相互隔离，你可以根据需要创建任意数量的命名空间，并将资源和操作范围限定到命名空间，例如限制和配额。在命名空间中运行的Pod只能直接访问其所在的命名空间。要想访问其他命名空间，必须通过公有API。

2.服务账户

服务账户为你的微服务提供身份，每个服务账户将具有与其账户关联的某些特权和访问权限。服务账户使用起来非常简单：

你可以将服务账户与Pod相关联（例如在部署的Pod的spec中），在Pod中运行的微服务将具有该身份以及与该账户相关联的所有特权和限制。如果你未分配服务账户，则Pod会使用其命名空间的默认服务账户。每个服务账户都与用于对其进行身份验证的密钥关联。

3.密钥

Kubernetes为所有微服务提供密钥管理功能。你可以在etcd（自Kubernetes 1.7开始）中对密钥进行加密，并且始终在网络上对其进行加密传输（通过HTTPS）。密钥是按命名空间管理的，并作为文件挂载（密钥卷）或环境变量保存在Pod中。创建密钥的方法有很多种。密钥包含两种映射：data和stringData。data映射中的值类型可以是任意的，但必须是base64编码的，例如以下内容：

以下是Pod如何将密钥作为卷进行加载：

最终结果是，由Kubernetes在Pod外部管理的数据库密钥将显示为Pod内部的普通文件，通过/etc/db_creds路径访问。

4.通信安全

Kubernetes利用客户端证书对任何外部通信（例如kubectl）进行双向认证。从外部到Kubernetes API的所有通信都通过HTTPS进行。API服务器与工作节点上的kubelet之间的集群内部通信也是通过HTTPS（kubelet端点）进行的。但是，默认情况下它不使用客户端证书（你可以启用它）。

默认情况下，API服务器与节点、Pod和服务之间的通信是通过HTTP进行的，并且未经身份验证。你可以将它们升级到HTTPS，但是这会验证客户端证书，所以不要在公共网络上运行工作节点。

5.网络策略

在分布式系统中，除了需要保护每个容器、Pod和节点之外，控制网络上的通信也至关重要。Kubernetes支持网络策略，它可以提供充分的灵活性来定义和调整集群中的网络流量和访问。