让我们快速了解一下 ConfigMaps 和 Secrets 是什么：

  • ConfigMaps：可以把它们看作是应用程序的私人助理，保存所有非敏感的配置数据。
  • Secrets：这是你存放所有机密信息的地方。密码、API 密钥，等等。

现在，你可能会想，“Secrets 不是应该是秘密吗？” 稍安勿躁，我们马上就会讨论这个有趣的部分！

创建 ConfigMaps 和 Secrets：操作指南

让我们卷起袖子，动手写一些 YAML 文件吧。

ConfigMaps：你的配置伙伴

创建一个 ConfigMap 简单得像吃蛋糕。以下是一个 YAML 片段，帮助你入门：


apiVersion: v1
kind: ConfigMap
metadata:
  name: my-awesome-config
data:
  APP_COLOR: blue
  APP_MODE: production

或者，如果你更喜欢命令行：


kubectl create configmap my-awesome-config --from-literal=APP_COLOR=blue --from-literal=APP_MODE=production

Secrets：不一般的秘密

现在，来看看主角——Secrets！以下是创建一个 Secret 的方法：


apiVersion: v1
kind: Secret
metadata:
  name: my-super-secret
type: Opaque
data:
  DB_PASSWORD: cGFzc3dvcmQxMjM=  # base64 编码的 "password123"

或者通过命令行：


kubectl create secret generic my-super-secret --from-literal=DB_PASSWORD=password123

但是，注意这里有个陷阱！你注意到 Secret 的数据只是 base64 编码了吗？稍后我们会详细讨论。

陷阱：不要掉进这些坑！

现在我们已经了解了基础知识，让我们来谈谈一些常见的错误，即使是经验丰富的开发者也会犯。相信我，我也曾经犯过这些错误。

1. “秘密”并不那么秘密

还记得我提到 Secrets 只是 base64 编码吗？这就是我们的第一个陷阱。许多开发者认为 Secrets 是加密的。剧透：它们不是！

“等等，”你可能会说，“base64 编码不够安全吗？” 如果你认为这很安全，那我有座桥要卖给你！

要真正保护你的 Secrets，你需要启用静态加密。以下是一个快速示例：


apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources:
      - secrets
    providers:
      - aescbc:
          keys:
            - name: key1
              secret: c2VjcmV0LWtleS1oZXJl
      - identity: {}

2. 环境变量陷阱

使用环境变量存储秘密？这就像把你的房门钥匙放在门垫下。任何获得你 pod 访问权限的人都可以通过一个简单的命令查看所有环境变量：


kubectl exec -it my-pod -- env

相反，考虑将秘密挂载为文件。这不是万无一失的，但比之前好一些：


volumeMounts:
  - name: secret-volume
    mountPath: /etc/secrets
    readOnly: true
volumes:
  - name: secret-volume
    secret:
      secretName: my-super-secret

3. 'kubectl describe' 困境

你知道 kubectl describe secret 会显示 base64 编码的秘密数据吗？是的，暴露你的秘密就是这么简单。为了解决这个问题，使用 RBAC 限制谁可以描述秘密：


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

最佳实践：让你的 Kubernetes 集群像金库一样安全

现在我们已经讨论了不该做的事情，让我们来谈谈一些最佳实践，以确保你的 ConfigMaps 和 Secrets 比冬天松鼠的坚果储藏更安全。

1. 把 Secrets 当作真正的秘密

永远，绝对不要在你的应用程序代码中硬编码秘密。即使是为了在生产环境中进行“快速测试”。我们都经历过，但要抵制这种冲动！

2. 使用秘密管理器

考虑将 Kubernetes 与专用的秘密管理器集成，如 HashiCorp Vault 或 AWS Secrets Manager。这些工具专为安全处理秘密而设计，并且可以无缝集成到 Kubernetes 中。

3. 定期轮换秘密

像对待你的内衣一样对待你的秘密——定期更换！设置一个自动轮换秘密的流程。你的未来自我会感谢你。

4. 监控泄漏

设置监控以检测秘密是否意外暴露。像 GitGuardian 这样的工具可以帮助你在秘密进入生产环境之前捕获它们。

何时使用 ConfigMaps 和 Secrets

现在我们已经讨论了如何和什么，让我们来谈谈何时使用。

使用 ConfigMaps：

  • 非敏感的配置数据
  • 特定环境的设置
  • 配置文件

使用 Secrets：

  • 密码
  • OAuth 令牌
  • SSH 密钥
  • 任何你不想让好奇的同事看到的数据

总结

ConfigMaps 和 Secrets 是 Kubernetes 生态系统中的强大工具，但强大的能力伴随着巨大的责任。明智地使用它们，妥善保护它们，你的应用程序将感谢你保持安全和可配置。

记住，在 Kubernetes 的世界里，多一点点偏执是有好处的。总是假设有人试图访问你的秘密，因为在互联网的狂野世界中，他们可能确实在这样做！

现在，去安全地配置吧，我的 Kubernetes 冒险者们！

“唯一真正安全的系统是一个关闭电源、浇筑在混凝土块中并用武装警卫封闭在铅衬房间中的系统。” - Gene Spafford

附言：如果你觉得这篇文章有帮助，考虑与团队分享。谁知道呢，你可能会拯救某人免于深夜“哎呀，我暴露了我们的生产数据库密码”的事件！