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

Question

Ok.. so, we have Google Secret Manager on GCP, AWS Secret Manager in AWS, Key Vault in Azure... and so on.

Those services give you libs so you can code the way your software will access the secrets there. They all look straightforward and sort of easy to implement. Right?

For instance, using Google SM you can like:

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")

and you're done.

I mean, if we talk about K8S, you can improve the code above by reading the vars from a configmap where you may have all the resources of your secrets, like:

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

And then use part of the code above to load the vars and get the secrets from the SM.

So, when I was looking the interwebs for best practices and examples, I found projects like the below:

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

But those projects don't clearly explain what's the point of mounting my secrets as files or env_vars..

I got really confused, maybe I'm too newbie on the K8S and cloud world... and that's why I'm here asking, maybe, a really really dumb questions. Sorry :/

My questions are:

1. Are the projects, mentioned above, recommended for old code that I do not want to touch? I mean, let's say that my code already use a env var called DBPASS=mypass and I would like to workaround it so the value from the DBPASS env would be hackinjected by a value from a SM.
2. The implementation to handle a secret manager is very hard. So it is recommended to use one of the solutions above?
3. What are the advantages of such injection approach?

Thx a lot!

Answer 1

There are many possible motivations why you may want to use an abstraction (such as the CSI driver or sidecar injector) over a native integration:

• Portability - If you're multi-cloud or multi-target, you may have multiple secret management solutions. Or you might have a different secret manager target for local development versus production. Projecting secrets onto a virtual filesystem or into environment variables provides a "least common denominator" approach that decouples the application from its secrets management provider.

• Local development - Similar to the previous point on portability, it's common to have "fake" or fakeish data for local development. For local dev, secrets might all be fake and not need to connect to a real secret manager. Moving to an abstraction avoids error-prone spaghetti code like:

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

• De-risking - By avoiding a tight coupling, you can de-risk upstream API changes in an abstraction layer. This is conceptual similar to the benefits of microservices. As a platform team, you make a guarantee to your developers that their secret will live at process.env.FOO, and it doesn't matter how it gets there, so long as you continue to fulfill that API contract.

• Separate of duties - In some organizations, the platform team (k8s team) is separate from the security team, is separate from development teams. It might not be realistic for a developer to ever have direct access to a secret manager.

• Preserving identities - Depending on the implementation, it's possible that the actor which accesses the secret varies. Sometimes it's the k8s cluster, sometimes it's the individual pod. They both had trade-offs.

---

Why might you not want this abstraction? Well, it adds additional security concerns. Exposing secrets via environment variables or via the filesystem makes you subject to a generic series of supply chain attacks. Using a secret manager client library or API directly doesn't entirely prevent this, but it forces a more targeted attack (e.g. core dump) instead of a more generic path traversal or env-dump-to-pastebin attack.