在 k8s 中使用秘密注入器而不是在我的软件中编写代码来处理我在保险库中的秘密的目的是什么 google SM

What is the purpose of using a secret injector in k8s instead of coding in my software the stuff to handle my secrets in a vault like google SM

好的..所以,我们在 GCP 上有 Google Secret Manager,在 AWS 上有 AWS Secret Manager,在 Azure 上有 Key Vault...等等。

这些服务为您提供了库,因此您可以按照您的软件访问那里的秘密的方式进行编码。它们看起来都很简单,也很容易实现。对吗?

比如使用Google 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

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

因此,当我在 interwebs 中寻找最佳实践和示例时,我发现了如下项目:

  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

但是那些项目并没有清楚地解释将我的机密作为文件安装或 env_vars..

的意义是什么

我真的很困惑,也许我在 K8S 和云世界上太新手了……这就是为什么我在这里问,也许,一个非常非常愚蠢的问题。抱歉:/

我的问题是:

  1. 上面提到的项目是否推荐用于我不想接触的旧代码?我的意思是,假设我的代码已经使用了一个名为 DBPASS=mypass 的环境变量,我想解决它,因此来自 DBPASS 环境的值将 hackinjected 来自 SM 的值.
  2. 处理秘密管理器的实现非常困难。所以建议使用上面的解决方案之一?
  3. 这种注入方式有什么优点?

非常感谢!

有许多可能的动机可以解释为什么您可能希望在本机集成上使用抽象(例如 CSI 驱动程序或 sidecar 注入器):

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

  • 本地开发 - 与之前关于可移植性的观点类似,本地开发的“假”或假数据很常见。对于本地开发人员,秘密可能都是假的,不需要连接到真正的秘密管理器。转向抽象避免了容易出错的意大利面条代码,例如:

    let secret;
    if (process.env.RAILS_ENV === 'production') {
      secret = secretmanager.access('...')
    } else { 
      secret = 'abcd1234'
    }
    
  • 降低风险 - 通过避免紧密耦合,您可以降低抽象层中上游 API 更改的风险。这在概念上类似于微服务的好处。作为一个平台团队,您向您的开发人员保证他们的秘密将保存在 process.env.FOO,并且 如何 它到达那里并不重要,只要您继续履行 API 合同。

  • 职责分离 - 在一些组织中,平台团队(k8s 团队)与安全团队分开,与开发团队分开。开发人员直接访问秘密管理器可能是不现实的。

  • Preserving identities - 根据实现的不同,访问秘密的参与者可能会有所不同。有时是 k8s 集群,有时是单个 pod。他们都有取舍。


为什么您需要这种抽象?好吧,它增加了额外的安全问题。通过环境变量或文件系统暴露秘密会使您受到一系列通用的供应链攻击。使用秘密管理器客户端库或直接 API 并不能完全阻止这种情况,但它会强制进行更有针对性的攻击(例如核心转储),而不是更通用的路径遍历或 env-dump-to-pastebin 攻击。