什么是秘密？
Kubernetes Secret 是一个对象，它使我们能够存储和管理敏感信息。 Secret 可以包含诸如 SSH 密钥、OAuth 数据或其他用户身份验证信息（如密码）之类的数据。 它通常以 Kubernetes 原生的方式存储在集群中。 使用 Secret 对象可以更精细地控制如何使用高度敏感的数据。 它还降低了数据暴露给未授权方的风险。
预防措施
默认情况下，任何有权访问 Kubernetes 中的 API 或 etcd（底层数据存储）的人都可以查看 Secrets。 当我们创建 Secrets 资源时，API 服务器以 base64 编码形式将数据存储在 etcd 中。 Base64 不是加密！ 要安全地使用 Secrets，请立即调整最小推荐值。
- 为 Secrets 启用“静态加密”。
- 快速启用或重新配置限制 Secret 读写的 RBAC 规则。 请注意，任何有权创建 Pod 的人都可以隐式获取机密。
为什么要保护秘密？
通常，Kubernetes 默认是不安全的。 所有 pod 都使用 CAP_NET_RAW 权限级别。 默认情况下允许将原始数据包注入网络的能力是完成特定启动任务的有用且有效的工具。 但是，由于所有 pod 都可以打开原始套接字，因此强烈建议不要在配置后启用此状态。
允许这些默认设置保持比必要时间更长的时间允许攻击者接管单个 pod，可能将恶意数据包注入整个 Kubernetes 集群。 应快速使用机密的初始权限级别，然后修改以锁定系统。
一个快速 etcd 搜索 揭示了数千个可公开访问的 etcd 服务器，突出了提高安全性的需求。 etcd 是一个开源的分布式键值存储，用于存放和管理 Kubernetes 的配置数据、状态数据和元数据。
秘密如何运作？
Secret 可以作为卷挂载或作为环境变量公开给 Kubernetes Pod 内的容器。 有两种类型的秘密：
- 内置秘密：Kubernetes 服务帐户会自动创建机密并使用 API 凭据将它们附加到容器。 如果引发其他安全问题，可以覆盖或禁用此方法。
- 自定义机密：在这里我们可以定义我们的敏感或私有数据并创建一个 Secret 来存储它。
这些机密可以放置在 YAML 文件或其他指定位置，并用于验证访问、确定权限级别或用于其他验证目的。
如何保护秘密
我们通过假设会发生妥协来开始保护秘密的过程。 这个概念是零信任安全的基本原则之一。 此外，我们应该对所有传输中的 Secret 使用 TLS 加密。 这种编码应该发生在应用层。
定期更改 Secrets，就像密码一样，也是一种很好的做法。 使用隔离将秘密与所有其他对象分开只会进一步减少攻击平面。 最后，在所有访问门户、日志和其他服务网关中采用可靠的审计实践可以提高安全性。 这些步骤提供了更精细的安全控制流程，可以保护您的机密。
用于获取我们的秘密的三种方法可以分类如下：
- 彻底的攻击：黑客、入侵者或其他渗透者经常扫描或设计进入集群以获取信息。
- 意外暴露：秘密可能会从存储在存储桶中或位于存储库中的文件中意外泄露。
- 权限配置错误：如果权限设置太低或组用户被授予额外权限，则会出现安全问题。
信封加密
信封加密是 Kubernetes 使用另一个密钥加密密钥的一种方法。 它位于 Kubernetes API 和 etcd 服务器之间，并对通过它的数据进行加密，因此没有未加密的信息存储在 etcd 上。 Kubernetes 1.7 将此功能合并到核心 Kubernetes 系统中。
Kubernetes 使用的另一个工具是密封的秘密。 密封的秘密 是一个开源工具，用于管理将敏感信息部署到 Kubernetes 集群。 它还可以将机密安全地存储在 Git 存储库中，从而可以集成到 CI/CD 管道中。
创建秘密
我们可以使用以下方法之一创建 Secret 对象。
自动地
我们可以使用 kubectl create secret 命令。 这是创建 Secret 的格式。
[email protected] [~]# kubectl create secret (type) (name) (data)- 类型：类型定义为泛型、TLS 或 docker-registry 元素。
- 姓名: 这是秘密的名字。
- 数据：这是目录路径或键值对。
手动
我们可以通过多种方式手动创建机密。 我们可以将 Secret 信息添加到 JSON 或 YAML 文件中并使用 kubectl apply 命令。 此调用将文件中包含的对象定义为 Secret。 然后使用以下命令部署对象。
[email protected] [~]# kubectl create -f filename.yaml 此外，可以使用以下标志 –from-file 或 –from-env-file 从一个或多个文件生成 Secret。 使用 –from-file 标志创建 Secret 时，文件的全部内容就是 Secret 本身。 如果 Secret 的值包含多个键值对，我们将改用 –from-env-file 标志。 使用这些标志，我们可以传递单个文件或多个文件。
[email protected] [~]# kubectl create secret type name --from-file /path/to/file --from-file /path/to/file2 可以按照这种格式使用包含多个文件的目录。
[email protected] [~]# kubectl create secret type name --from-file /path/to/directory. 以下命令分别使用两个文件（user.txt 和 pass.txt）创建 Secret。 以下命令根据这些文件中的数据设置键。
[email protected] [~]# kubectl create secret generic authme --from-file ./user.txt --from-file ./pass.txt 自定义
最后，我们可以使用创建 Secrets 自定义. 此工具是一种独立方法，用于通过 kustomization 文件自定义 Kubernetes 中的对象。 它允许用户自定义原始 YAML 文件，同时保持原始 YAML 文件不受干扰。
编辑秘密
可以使用以下命令编辑当前 Secret。
[email protected] [~]#kubectl edit secrets authme此命令打开默认配置编辑器，它允许我们更新数据字段中包含的 base64 编码的 Secret 参数。
使用秘密
要使用 Secret，Pod 需要对 Secret 的引用。 Pod 以三种方式使用秘密：
- 作为包含文件或驻留在一个或多个容器上的挂载卷。
- 作为容器的环境变量。
- 使用 kubelet 为 Pod 拉取镜像时。
注意：Secret 对象的名称必须是完全限定域名 (FQDN) 的子域。
系统的不同部分也可以在不直接暴露给 Pod 的情况下使用机密。 关于如何使用机密的完整描述将填充另一篇文章，所以我们到此结束。
结论
Secrets 是包含敏感数据（如密码、SSH 密钥或 OAuth 令牌）的对象。 与将这些机密信息存储在 Pod 的定义或容器映像中相比，将这些机密信息存储在 Secret 中要安全得多，并且在更大程度上是一种更灵活的方法。 保持我们的集群安全是使用 Secrets 的主要目标，同时允许轻松访问那些需要访问的用户和服务。
CTA
我们的解决方案团队由知识渊博且经验丰富的托管顾问组成，他们对本文中讨论的技术有深入的了解。 如果您对此信息有任何疑问，我们将一年 365 天、每周 7 天、每天 24 小时回答与本文相关的任何问题。
我们将解释您如何使用我们的托管平台来利用这些平台 Cloud 或私人 Cloud 由 VMware 和 NetApp 提供支持！ 如果您使用的是完全托管的 VPS 服务器， Cloud 专用、私有父服务器或专用服务器所有者并希望对这些平台之一进行更改，请拨打 800.580.4985 给我们打电话，或与我们打开聊天或票证以了解如何操作！
