K8S Secret最佳实践：安全存储与管理

2025-3-9

Kubernetes Secret 最佳实践：安全存储与管理

在 Kubernetes (K8s) 集群中，安全地管理和存储敏感信息（如密码、API 密钥、OAuth 令牌、SSH 密钥和 TLS 证书）至关重要。Kubernetes 提供了 Secret 资源对象来处理这些敏感数据，但仅仅使用 Secret 对象本身并不足以保证安全性。本文将深入探讨 Kubernetes Secret 的最佳实践，涵盖从创建、存储、访问到审计的整个生命周期，帮助你构建更安全的 Kubernetes 应用。

1. 理解 Kubernetes Secret

1.1 什么是 Kubernetes Secret？

Secret 是一种 Kubernetes 对象，用于存储少量敏感数据。与将敏感信息硬编码在 Pod 定义或 ConfigMap 中相比，Secret 提供了一种更安全、更灵活的方式来管理这些数据。Secret 的数据以 base64 编码存储，但这并非加密，只是简单的编码，可以轻松解码。

1.2 Secret 类型

Kubernetes 提供了几种内置的 Secret 类型：

  • Opaque: 这是最通用的类型，用于存储任意键值对数据。
  • kubernetes.io/service-account-token: 用于存储 Service Account 的令牌。
  • kubernetes.io/dockercfg: 用于存储 Docker 配置文件（已弃用，建议使用 kubernetes.io/dockerconfigjson）。
  • kubernetes.io/dockerconfigjson: 用于存储 Docker 注册表的凭据。
  • kubernetes.io/basic-auth: 用于存储基本认证的凭据（用户名和密码）。
  • kubernetes.io/ssh-auth: 用于存储 SSH 密钥。
  • kubernetes.io/tls: 用于存储 TLS 证书和私钥。
  • bootstrap.kubernetes.io/token: 用于存储启动引导的token

选择合适的 Secret 类型可以帮助你更好地组织和管理 Secret，并利用 Kubernetes 的一些内置功能（如自动注入 Service Account 令牌）。

1.3 Secret 的局限性

尽管 Secret 提供了一定的安全性改进，但它本身也存在一些局限性：

  • Base64 编码并非加密: Secret 中的数据仅经过 base64 编码，容易被解码。
  • etcd 中的明文存储: 默认情况下，Secret 数据以明文形式存储在 Kubernetes 集群的 etcd 数据库中。
  • 访问控制: 需要仔细配置 RBAC 规则来限制对 Secret 的访问。
  • 缺乏版本控制和回滚: Secret 本身不提供版本控制或回滚机制。
  • 静态 Secret: Secret通常是静态，更新不方便。

因此，仅仅依赖 Kubernetes 内置的 Secret 功能是不够的，我们需要采取额外的安全措施。

2. Secret 创建与存储最佳实践

2.1 最小化 Secret 大小

Secret 对象的大小限制为 1MB。应避免在 Secret 中存储大型文件或二进制数据。如果需要存储大型敏感数据，可以考虑使用外部密钥管理系统（KMS）或将数据存储在安全的对象存储服务中，然后在 Secret 中存储指向这些数据的引用。

2.2 使用强密码和随机生成的密钥

对于需要存储密码或密钥的场景，务必使用强密码和随机生成的密钥。可以使用密码生成器（如 openssl rand）或专门的密码管理工具来生成这些凭据。

2.3 不要将 Secret 提交到版本控制系统

绝对不要将包含敏感信息的 Secret 清单文件（YAML 或 JSON）直接提交到版本控制系统（如 Git）。这样做会将敏感信息暴露给所有有权访问代码仓库的人员。

替代方案：

  • 使用 Git 忽略文件 (.gitignore): 将包含 Secret 定义的文件添加到 .gitignore 中，防止它们被提交到仓库。
  • 使用外部密钥管理系统 (KMS): 将敏感信息存储在外部 KMS（如 HashiCorp Vault、AWS KMS、Azure Key Vault、Google Cloud KMS）中，并在 Kubernetes 中引用这些密钥。
  • 使用 Git 加密工具: 使用 git-crypt 或 BlackBox 等工具对包含敏感信息的文件进行加密，然后再提交到仓库。
  • 使用SOPS: SOPS 是一个开源工具，可与各种 KMS 提供程序集成以加密 YAML、JSON、ENV、INI 和 BINARY 文件。

2.4 使用 Imperative 命令创建 Secret

可以使用 kubectl create secret 命令以 imperative 的方式创建 Secret，避免将敏感信息直接写入 YAML 文件：

```bash

创建一个通用 Secret

kubectl create secret generic my-secret --from-literal=username=myuser --from-literal=password=mypassword

从文件创建 Secret

kubectl create secret generic db-secret --from-file=db-password.txt

创建 Docker 注册表凭据 Secret

kubectl create secret docker-registry regcred --docker-server= --docker-username= --docker-password= --docker-email=
```

2.5 使用 Secret 生成器 (Secret Generator)

Kustomize 提供了一个 SecretGenerator，可以从字面值、文件或环境变量生成 Secret。这可以帮助你更方便地管理 Secret，并与 Kustomize 的其他功能集成。

```yaml

kustomization.yaml

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
secretGenerator:
- name: db-secret
literals:
- username=dbuser
- password=dbpassword
files:
- db-config.txt
```

3. Secret 访问控制最佳实践

3.1 使用 RBAC 限制 Secret 访问

Kubernetes 的基于角色的访问控制 (RBAC) 机制可以用来限制对 Secret 的访问。应该遵循最小权限原则，只授予用户或 Service Account 所需的最小权限。

示例：

```yaml

创建一个 Role，只允许读取名为 my-secret 的 Secret

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: my-namespace
name: secret-reader
rules:
- apiGroups: [""]
resources: ["secrets"]
resourceNames: ["my-secret"]
verbs: ["get", "watch"]

将 Role 绑定到 Service Account

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: secret-reader-binding
namespace: my-namespace
subjects:
- kind: ServiceAccount
name: my-service-account
namespace: my-namespace
roleRef:
kind: Role
name: secret-reader
apiGroup: rbac.authorization.k8s.io
```

3.2 使用命名空间隔离 Secret

使用命名空间（Namespace）来隔离不同应用程序或团队的 Secret。这样可以限制 Secret 的可见性，并降低未经授权访问的风险。

3.3 限制对 etcd 的访问

etcd 是 Kubernetes 集群的键值存储，用于存储包括 Secret 在内的所有集群数据。应限制对 etcd 的直接访问，只允许授权的管理员或系统组件访问。

建议：

  • 使用 TLS 加密 etcd 通信: 配置 etcd 使用 TLS 证书进行客户端和服务器之间的加密通信。
  • 启用 etcd 认证: 配置 etcd 使用用户名和密码或客户端证书进行认证。
  • 限制网络访问: 使用网络策略或防火墙规则限制对 etcd 端口（默认为 2379）的访问。
  • 开启etcd 数据加密

3.4 审计 Secret 访问

启用 Kubernetes 审计日志，记录对 Secret 的所有访问和修改操作。这可以帮助你跟踪 Secret 的使用情况，并在发生安全事件时进行调查。

建议：

  • 配置审计策略: 定义一个审计策略，指定要记录的事件类型、资源和用户。
  • 将审计日志发送到外部存储: 将审计日志发送到安全的外部存储（如 SIEM 系统），以便长期保存和分析。

4. Secret 使用最佳实践

4.1 将 Secret 作为环境变量或卷挂载到容器

可以通过两种方式将 Secret 中的数据暴露给容器：

  • 环境变量: 将 Secret 中的键值对作为环境变量注入到容器中。
  • 卷挂载: 将 Secret 作为一个卷挂载到容器的文件系统中。

示例：

yaml
apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
containers:
- name: my-container
image: my-image
env:
- name: DB_USERNAME
valueFrom:
secretKeyRef:
name: db-secret
key: username
volumeMounts:
- name: db-config-volume
mountPath: /etc/db-config
readOnly: true
volumes:
- name: db-config-volume
secret:
secretName: db-secret
优先使用卷挂载，避免敏感信息出现在进程命令行中。

4.2 避免在容器日志中暴露 Secret

应用程序应避免将 Secret 中的敏感信息输出到日志中。如果需要记录与 Secret 相关的信息，应进行脱敏处理。

4.3 定期轮换 Secret

定期轮换（更改）Secret 中的凭据，以降低凭据泄露的风险。轮换周期应根据凭据的敏感程度和安全策略来确定。

建议：

  • 自动化轮换: 使用工具或脚本自动化 Secret 的轮换过程。
  • 无缝轮换: 在轮换过程中，确保应用程序可以无缝地切换到新的凭据，避免服务中断。

4.4 使用不可变 Secret

从 Kubernetes 1.21 版本开始，你可以将 Secret 标记为不可变（Immutable）。不可变的 Secret 一旦创建，就无法修改其内容。这可以防止意外或恶意的修改，提高安全性。

yaml
apiVersion: v1
kind: Secret
metadata:
name: my-immutable-secret
immutable: true
data:
...

5. 使用外部密钥管理系统 (KMS)

对于高安全要求的场景，建议使用外部密钥管理系统 (KMS) 来管理 Secret。KMS 提供了更强大的加密、访问控制、审计和密钥管理功能。

5.1 常见的 KMS 解决方案

  • HashiCorp Vault: 一个开源的密钥管理和数据保护工具，支持多种存储后端和认证方法。
  • AWS Key Management Service (KMS): AWS 提供的托管密钥管理服务。
  • Azure Key Vault: Azure 提供的云密钥管理服务。
  • Google Cloud Key Management Service (KMS): Google Cloud 提供的密钥管理服务。

5.2 集成 KMS 与 Kubernetes

可以使用 Kubernetes 的外部密钥管理服务插件（KMS Plugin）或第三方工具（如 Vault Agent Injector）将 KMS 与 Kubernetes 集成。

示例 (使用 HashiCorp Vault):

  1. 部署 Vault: 在 Kubernetes 集群中或外部部署 Vault。
  2. 配置 Vault: 配置 Vault 的存储后端、认证方法和策略。
  3. 启用 Kubernetes 认证方法: 在 Vault 中启用 Kubernetes 认证方法，允许 Kubernetes Service Account 向 Vault 进行认证。
  4. 使用 Vault Agent Injector: 部署 Vault Agent Injector，它可以自动将 Vault 中的密钥注入到 Pod 中。
  5. 在 Pod 中使用注解: 在 Pod 的注解中指定要注入的密钥路径。

yaml
apiVersion: v1
kind: Pod
metadata:
name: my-pod
annotations:
vault.hashicorp.com/agent-inject: "true"
vault.hashicorp.com/role: "my-app-role"
vault.hashicorp.com/agent-inject-secret-db-password: "secret/data/my-app/db-password"
spec:
containers:
- name: my-container
image: my-image
# 密钥将作为文件挂载到 /vault/secrets/ 目录下

6. 其他安全考虑

6.1 网络策略

使用 Kubernetes 网络策略（Network Policy）来限制 Pod 之间的网络通信。只允许 Pod 访问其所需的 Secret 所在的命名空间。

6.2 容器安全

  • 使用最小权限的基础镜像: 选择包含最少必要组件的基础镜像，减少攻击面。
  • 定期扫描容器镜像: 使用容器镜像扫描工具（如 Trivy、Clair）扫描镜像中的漏洞，并及时修复。
  • 以非 root 用户运行容器: 避免以 root 用户身份运行容器，降低容器逃逸的风险。
  • 使用安全上下文 (Security Context): 配置容器的安全上下文，限制容器的权限和能力。

6.3 集群安全

  • 启用 RBAC: 始终启用 Kubernetes 的 RBAC 机制。
  • 限制对 Kubernetes API 的访问: 使用防火墙或安全组限制对 Kubernetes API 服务器的访问。
  • 定期更新 Kubernetes: 及时更新 Kubernetes 到最新版本，修复已知的安全漏洞。
  • 监控集群活动: 使用监控工具（如 Prometheus、Grafana）监控集群的活动，及时发现异常行为。

总结

Kubernetes Secret 的安全管理是一个多方面的任务，需要综合考虑创建、存储、访问、使用和审计等各个环节。通过遵循本文介绍的最佳实践，结合使用外部密钥管理系统和 Kubernetes 的安全特性，你可以显著提高 Kubernetes 集群中敏感信息的安全性，构建更安全可靠的应用程序。记住，安全是一个持续的过程，需要不断地评估和改进你的安全策略。

版权声明：
作者：admin
链接：https://hostlocvps.com/2025/03/09/k8s-secret%e6%9c%80%e4%bd%b3%e5%ae%9e%e8%b7%b5%ef%bc%9a%e5%ae%89%e5%85%a8%e5%ad%98%e5%82%a8%e4%b8%8e%e7%ae%a1%e7%90%86/
文章版权归作者所有，未经允许请勿转载。
THE END
f to c转换计算器
<<上一篇
深度解析Jupyter Notebook：代码与文本结合的数据分析工具
下一篇>>
相关推荐
人工智能与翻译服务
立即更新到 macOS Ventura 15.3.1
SVN: 哪个版本控制系统更适合你？ (英文版)
iPhone 屏幕镜像设置指南
Redis开发指南
Rtools: 解决Windows R开发环境难题
PHP在线测试工具：验证代码功能
Java 55：值得升级吗？
DeepL：你的翻译伴侣
免费使用 PyCharm: Python 开发者的利器