《Kubernetes 最佳实践》第二版

第 4 章 配置、保密和 RBAC

本作品已使用人工智能进行翻译。欢迎您提供反馈和意见：[e-mail]

容器的可组合特性允许我们作为操作员在运行时将配置数据引入容器。这样，我们就可以将应用程序的功能与其运行环境解耦。通过容器运行时允许在运行时向容器传递环境变量或挂载外部卷的约定，您可以在实例化应用程序时有效地更改应用程序的配置。作为开发人员，必须考虑到这种行为的动态性质，并允许使用环境变量或从应用程序运行时用户可用的特定路径读取配置数据。

在将机密等敏感数据移入本地 Kubernetes API 对象时，了解 Kubernetes 如何确保对 API 的访问安全非常重要。Kubernetes 中最常用的安全方法是基于角色的访问控制（RBAC），它围绕特定用户或组可以对 API 采取的行动实施细粒度的权限结构。本章将介绍有关 RBAC 的一些最佳实践，并提供一个小入门。

通过配置映射和机密进行配置

Kubernetes 允许你通过 ConfigMaps 或秘密资源向我们的应用程序原生提供配置信息。两者之间的主要区别在于 pod 存储接收信息的方式和数据在 etcd 数据存储中的存储方式。

配置地图

让应用程序通过某种机制（如命令行参数、环境变量或系统可用文件）消耗配置信息是非常常见的。容器允许开发人员将这些配置信息与应用程序分离，从而实现真正的应用程序可移植性。ConfigMap API 允许注入所提供的配置信息。ConfigMap 非常适合应用程序的要求，可以提供键/值对或复杂的批量数据，如 JSON、XML 或专有配置数据。

ConfigMaps 不仅能为 pod 提供配置信息，还能为更复杂的系统服务（如控制器、CRD、操作员等）提供所需的信息。如前所述，ConfigMap API 更适用于非敏感数据的字符串数据。如果您的应用程序需要更敏感的数据，则 Secrets API 更为合适。

要让应用程序使用 ConfigMap 数据，可以将其作为安装到 pod 中的卷或环境变量注入。

秘密

的许多属性和理由都适用于秘密。主要区别在于秘密的基本性质。秘密数据的存储和处理方式应易于隐藏，如果环境配置为加密，还可能在静态时进行加密。秘密数据是以 base64 编码信息的形式表示的，而且必须明白这并没有加密。 一旦将秘密注入 pod，pod 本身就能看到纯文本的秘密数据。

秘密数据是指少量数据，Kubernetes 默认限制 base64 编码数据的大小为 1 MB，因此要确保实际数据约为 750 KB，因为编码会产生开销。Kubernetes 中有三种类型的秘密：

generic

通常只是普通的键/值对，这些键/值对是使用--from-literal= 参数从文件、目录或字符串文字中创建的，如下所示：

kubectl create secret generic mysecret --from-literal=key1=$3cr3t1
    --from-literal=key2=@3cr3t2

docker-registry

如果有imagePullsecret ，在 pod 模板中传递时，kubelet 会使用此，以提供向私有 Docker 注册表进行身份验证所需的凭据：

kubectl create secret docker-registry registryKey --docker-server
    myreg.azurecr.io --docker-username myreg --docker-password ...