I am the founder of a very similar project that supports both AWS Secrets Manager and Google Secrets Manager which actually predates this and GoDaddy's solutions[1].

The proliferation of these type of projects clearly shows the need for secret handling. While I think that more solutions for the same problem is not a bad thing, I also believe that we could benefit from a coordinated effort.

My colleagues are actively working with GoDaddy's maintainers to find a common way forward by standardizing the "ExternalSecret" CRD and eventually merging the projects[2].

[1]https://github.com/ContainerSolutions/externalsecret-operato...

[2]https://github.com/godaddy/kubernetes-external-secrets/issue...

It's worth noting that the "Kubernetes External Secrets"[0] project from Godaddy is now supplanted by "Secret-Manager"[1].

I've been using Secret-Manager and it works very well.

The authors of "kube-secret-syncer" mention "[other solutions] lack either in security, caching or flexibility".

When it comes to "secret-manager", although I can not vouch for its security, the codebase is very small and probably easily auditable.

It's also very flexible. It supports "SecretStores", currently AWS, GCP and Vault out of the box, and it's easy to add more.

Not sure why "caching" is mentioned in the mix.

I'm surprised they decided to re-invent the wheel instead of improving secret-manager.

[0]: https://github.com/godaddy/kubernetes-external-secrets

[1]: https://github.com/itscontained/secret-manager

Kind of a different problem, but I've had really good experience with using Hashicorp's vault, which is excellent, paired with the vault-secrets-operator for kubernetes to do my secrets management. It will sync secrets from a vault path and create a kubernetes secret that you can use like any other secret. At least this way I feel like there's less lockin to a cloud provider (and some of the places I run this have on-prem kubernetes, so I have to have something that works outside of the cloud, and sometimes without internet).

https://www.vaultproject.io/

https://github.com/ricoberger/vault-secrets-operator

The entire Kubernetes secret space is a bit immature with no standard solutions. Many of the larger solutions are vendor specific and don't solve the problem in a generic way, see AWS[1] or Vault[2][3].

I've been discussing the problem-space with the Godaddy External Secret maintainers and they seem a bit burnt-out. There is work on standardization here https://github.com/godaddy/kubernetes-external-secrets/pull/..., but this more covers creating Kubernetes Secrets from external sources, work still remains around a generic pod injector solution.

A few of us have started work on what the implementation of this would look like over at https://github.com/itscontained/secret-manager.

[1] https://github.com/mumoshu/aws-secret-operator

[2] https://github.com/hashicorp/vault-k8s

[3] https://banzaicloud.com/blog/inject-secrets-into-pods-vault-...

I'm looking into this myself and ran across what looks to be a more "official" tool for this [1]. Kubernetes is a fast moving ecosystem and using random OSS operators has bit us in the past.

[1] https://github.com/kubernetes-sigs/secrets-store-csi-driver

If you're looking for a gitops alternative that can make use of AWS KMS, Azure KeyVault and Google Cloud KMS, would highly recommend kamus (https://kamus.soluto.io/). Allows secrets to be safely managed in source control and also has an AES mode ideal for local development.

I wrote this[1] operator over one year ago to learn some Go lang.

The project is a Kubernetes operator that automatically creates and updates Kubernetes secrets according to what is stored in AWS Secrets Manager (SM). A custom resource, named AWSSecret, maps an AWS SM entry to a K8S Secret resource.

[1] https://github.com/acamillo/aws-secret-operator

Interesting, wondering if it's portable to make work with Google Secrets Manager

Just switch from kube to ECS already, if you're in AWS. Much better integration and support.