在Kubernetes中安全管理应用配置与敏感信息

题目

在Kubernetes中安全管理应用配置与敏感信息

信息

• 类型：问答
• 难度：⭐⭐

考点

ConfigMap与Secret区别,敏感信息安全管理,环境变量与卷挂载选择,安全最佳实践

快速回答

在Kubernetes中，ConfigMap用于管理非敏感配置数据，Secret用于管理敏感信息。主要区别在于：

• 数据安全：Secret内容默认Base64编码（非加密），ConfigMap明文存储
• 使用场景：数据库密码/API密钥用Secret，应用配置用ConfigMap
• 最佳实践：
  • 敏感数据必须使用Secret
  • 避免环境变量暴露Secret（优先用卷挂载）
  • 启用Secret加密（Encryption at Rest）
  • 使用RBAC限制访问权限

原理说明

ConfigMap和Secret都是Kubernetes提供的配置管理机制：

• ConfigMap：存储非敏感配置（如环境变量、配置文件），数据以明文形式存储在etcd中
• Secret：专为敏感数据设计（密码、令牌、密钥），内容默认以Base64编码存储（注意：Base64不是加密，仅避免明文暴露）

核心区别对比

代码示例

1. 创建Secret（推荐文件方式）

# 从文件创建Secret（避免命令行历史记录敏感信息）
kubectl create secret generic db-credentials \
  --from-file=username=./username.txt \
  --from-file=password=./password.txt

2. 在Pod中安全使用Secret

apiVersion: v1
kind: Pod
metadata:
  name: secure-app
spec:
  containers:
  - name: app-container
    image: myapp:1.0
    volumeMounts:
    - name: cred-volume
      mountPath: "/etc/credentials"
      readOnly: true  # 关键安全设置
  volumes:
  - name: cred-volume
    secret:
      secretName: db-credentials
      optional: false  # 确保Secret必须存在

最佳实践

• 敏感数据隔离：永远不要将密码/密钥放入ConfigMap
• 访问方式选择：
  • 优先使用卷挂载而非环境变量（防止日志泄露）
  • 挂载时设置readOnly: true
• 安全增强：
  • 启用K8s的静态加密(Encryption at Rest)
  • 通过RBAC限制Secret访问权限
  • 定期轮换Secret（结合CI/CD自动化）
• 不可变配置：设置immutable: true防止意外修改

常见错误

• 错误1：将API密钥放在ConfigMap中（高危！）
  → 正确做法：必须使用Secret
• 错误2：通过环境变量传递数据库密码
  → 风险：环境变量可能被打印到日志中
  → 改进：改用卷挂载，并确保应用不会记录敏感文件内容
• 错误3：未设置RBAC导致过度授权
  → 后果：普通用户可读取生产数据库密码
  → 修复：

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

扩展知识

• Secret加密方案：
  • KMS提供商（AWS KMS/Azure Key Vault等）
  • 本地加密密钥（需安全保管）
• 外部Secret管理：
  • HashiCorp Vault + Vault CSI Provider
  • AWS Secrets Manager + Secrets Store CSI Driver
• 安全审计：
  • 启用K8s审计日志监控Secret访问
  • 使用工具如kube-bench检查安全配置