Question

管理单个Kubernetes部署的3或4个机密的最佳实践。

我们有一个部署，在所有命名空间中都重复了一些秘密，其他部分则是特定于环境的。

我们正在尝试在一个秘密文件和仅更改需要的文件之间做出决定，或者运行2个以上的秘密，其中一个是foo-dev-secrets，另一个是foo-universal-secrets。

我们找不到任何在这些情况下应该做些什么的例子，更具体地说是如何管理这些秘密，我们知道你只能“每卷一个秘密”，但老实说我们不确定那是什么手段。

随意回答，好像我们是愚蠢的孩子。 ^ _ ^

Answer 1

运行2+秘密，其中一个是foo-dev-secrets，另一个是foo-universal-secrets

作为一个考虑因素，一个构造良好的RBAC策略将确保只有具有正确权限的帐户才能在分解时读取秘密，如果它们全部（当然）会更难集中在一个＆＃34;所有的秘密＆＃34;桶

我们知道你每卷只能拥有一个秘密＆＃34;但是老实说我们不确定这意味着什么。

然后你就是一个好公司，因为我不知道这意味着什么，或者:-D如果你的意思是有全局秘密，但是开发秘密被命名为相同但更具体，我认为 docker -v会容忍：

containers:
- name: foo
  volumeMounts:
  - name: global-secrets
    mountPoint: /run/secrets/global
    readOnly: true
  - name: foo-secret-override
    mountPoint: /run/secrets/global/no-really
    readOnly: true

...缺点是你的volumes:和volumeMounts:会变得非常健谈

那就是说，我敢打赌，更普遍的，更少思维弯曲的解决方案是将它们作为对等体安装，然后使用相当于find /run/secrets/ -not -type d的应用程序来扼杀它们：

  volumeMounts:
  - name: global-secrets
    mountPoint: /run/secrets/0-global
    readOnly: true
  - name: foo-secrets
    mountPoint: /run/secrets/1-foo
    readOnly: true

或者，如果可能的话，让应用程序从环境变量或ConfigMap的情况中读取路径，这意味着可以将它们作为对等项（仍然）进行投影，但是向应用程序指出这两个值中的哪一个它应该使用。

当然，细节中有魔鬼，所以如果你能够分享关于你遇到的障碍的更多细节，请随时加入

kubernetes的多个秘密

1 个答案: