在k8s中使用秘密注入器，而不是在我的软件中编写代码，在像谷歌SM这样的金库中处理我的秘密，目的是什么

Question

好啊所以，我们在GCP上有Google Secret Manager，在AWS上有AWS Secret Manager，在Azure上有密钥库。。。等等

这些服务为您提供LIB，这样您就可以编写软件访问机密的方式。它们看起来都很简单，而且很容易实现。正当

例如，使用谷歌SM，你可以喜欢：

from google.cloud import secretmanager
client = secretmanager.SecretManagerServiceClient()
request = {"name": f"projects/<proj-id>/secrets/mysecret/versions/1"}
response = client.access_secret_version(request)
payload = response.payload.data.decode("UTF-8")

你完了。

我的意思是，如果我们谈论K8S，你可以通过从一个配置图中读取变量来改进上面的代码，在这个配置图中，你可能拥有你秘密的所有资源，比如：

apiVersion: v1
kind: ConfigMap
metadata:
  name: myms
  namespace: myns
data:
  DBPASS: projects/<proj-id>/secrets/mysecretdb/versions/1
  APIKEY: projects/<proj-id>/secrets/myapikey/versions/1
  DIRTYSECRET: projects/<proj-id>/secrets/mydirtysecret/versions/1

然后使用上面的部分代码加载vars并从SM获取秘密。

因此，当我在互联网上寻找最佳实践和示例时，我发现了如下项目：

1. https://github.com/GoogleCloudPlatform/secrets-store-csi-driver-provider-gcp
2. https://github.com/doitintl/secrets-init
3. https://github.com/doitintl/kube-secrets-init
4. https://github.com/aws-samples/aws-secret-sidecar-injector
5. https://github.com/aws/secrets-store-csi-driver-provider-aws

但这些项目并没有清楚地解释将我的秘密作为文件或环境变量的意义。。

我真的很困惑，也许我对K8S和云世界太陌生了。。。这就是为什么我在这里问，也许，一个非常非常愚蠢的问题。抱歉：/

我的问题是：

1. 上面提到的这些项目是针对我不想接触的旧代码而推荐的吗？我的意思是，假设我的代码已经使用了一个名为DBPASS=mypass的env变量，我想解决这个问题，这样来自DBPASS env的值就会被来自SM的值注入

非常感谢！

Answer 1

在本机集成上使用抽象（如CSI驱动程序或侧车注入器）有许多可能的动机：

>

可移植性——如果你是多云或多目标，你可能有多种秘密管理解决方案。或者，对于本地开发和生产，您可能有不同的秘密经理目标。将机密投射到虚拟文件系统或环境变量中提供了一种“最小公分母”方法，可以将应用程序与其机密管理提供者分离。

本地开发——与前面关于可移植性的观点相似，为本地开发提供“虚假”或虚假的数据是很常见的。对于本地开发人员来说，秘密可能都是假的，不需要连接到真正的秘密管理器。转移到抽象可以避免容易出错的意大利面条代码，比如：

let secret;
if (process.env.RAILS_ENV === 'production') {
  secret = secretmanager.access('...')
} else { 
  secret = 'abcd1234'
}

降低风险-通过避免紧密耦合，您可以降低抽象层中上游API更改的风险。这在概念上类似于微服务的好处。作为一个平台团队，你向你的开发人员保证他们的秘密将存在于process.env.FOO，只要你继续履行那个应用编程接口合同，它是如何到达那里的并不重要。

职责分离——在一些组织中，平台团队（k8s团队）独立于安全团队，独立于开发团队。对于开发人员来说，直接访问秘密管理器可能并不现实。

保存身份-根据实现，访问秘密的参与者可能会有所不同。有时是k8s集群，有时是单个pod。他们都有权衡。

为什么你不想要这种抽象？这增加了额外的安全问题。通过环境变量或文件系统暴露机密会使您遭受一系列通用的供应链攻击。直接使用秘密管理器客户端库或应用编程接口并不能完全阻止这种情况，但它会强制进行更有针对性的攻击（例如核心转储），而不是更通用的路径穿越或env转储到pastebin攻击。