A Kubernetes operator to sync secrets from AWS Secrets Manager(contentful.com) |
A Kubernetes operator to sync secrets from AWS Secrets Manager(contentful.com) |
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...
Instead, the standard solution today is custom integration, which leads to a lot of reinventing the wheel and incompatibility with extremely similar products.
People need solutions to their problems and they develop them asynchronously and in isolation from each other. Turns out that some problems are more universal than others and could benefit from a common effort.
Suddenly, solutions collide and collaboration happens. What you describe is exactly what they are trying to do now: https://github.com/godaddy/kubernetes-external-secrets/pull/...
So, rejoice! The magic of open source and internet enabled collaboration is happening right before your eyes! :)
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.
Secret-Manager docs are, ahem, limited.
I've used both solutions, and ultimately, I think itscontained/secret-manager is better than external-secrets.
Their doc was re-jiggled a few days ago and I agree its made it look like it's inexistant. There's not a _ton_ of it, but it's there[0][1]
[0]https://github.com/itscontained/secret-manager/tree/master/d...
[1]https://github.com/itscontained/secret-manager/blob/master/d...
edit: found the link in the Godaddy repo to "secret-manager": https://github.com/godaddy/kubernetes-external-secrets/issue...
I was mistaken when I said "secret-manager supplanted external-secrets". It's a Golang rewrite from a user.
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-...
[1] https://github.com/kubernetes-sigs/secrets-store-csi-driver
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.
What people want is a cluster engine they shove a bit of text into and it does the rest. Integrated k8s does a job well enough with that, as does ECS. The difference is, k8s knowledge is transferrable to a growing number of businesses, ECS knowledge is not. Something to keep in mind if you're looking for employment in that area.
k8s also has the beauty of being able to exist completely disjointed from AWS infrastructure. Nothing better than being able to lock in clueless product teams -- not every dev is interested in that whole "service ownership" idea -- into their clusters and let them bear the responsibility. ECS is way too tightly integrated with AWS, and requires changing a lot more infrastructure. This is not easy to allow in an org where the NOC assigns VPC and general network layout.
--- [1] Fargate still does not support CMK encrypted ephemeral volumes https://github.com/aws/containers-roadmap/issues/915. From which you can tell, nobody who is spending serious money with AWS is using ECS too much based on this, as they would have hopped on implementing it by now. And using AWS integrated containers without fargate is pointless IMO, as that's exactly the kind of service you'd be looking to get from paying extra for big cloud.
1. It's the exception, not the rule. Most of the time there aren't collaborative solutions. Most of the time people work in their silos and make something work for themselves. Often it's corporate-funded, and those corporations have no consideration for others being able to pick up the work once they've abandoned it. The fact that there's 10 of the same thing to integrate is proof enough. It's just gotten so ridiculous that somebody finally had to address it. Turns out it's a company that has to deal with all of those implementations anyway.
2. This is one tool figuring out how a bunch of other tools can integrate into it. It's like what I'm proposing, if you assume the least work possible to achieve maximum laziness for your own specific tool and use case.
Their solution wasn't "hey, it looks like a lot of things use secrets. maybe it'd be cool if we made one way for any system with secrets to interoperate with any other system, and try to get it adopted by existing vendors." Their solution was "hey, we just need to get all these other things to work for the one tool we're using." Rather than "how can we make this more composable, more compatible, easier to implement, for everybody... even if they're not using our tool...", it became "how can we make this easier for just us?"
That's what is always happening, has always been happening, in this space, for nearly 10 years. Either everybody latches their custom tech onto a single platform and no real open source solutions get made, or everybody spits out incompatible, overbuilt, underthought, opinionated solutions for their own problem. We don't build standard solutions in the cloud world, we build log cabins.
I mean, just read the PR. They're talking about coding into this 'standard' support for each different implementation. Like "this is a vault secret, and this is a gsm secret." That's the opposite of what I want. I want it to say, "this is what a secret looks like. now you figure out how to use it.", or, "give me your secret. I don't care who or what you are, because we all speak the same secret language." That is what an internet standard is supposed to be. Not "this is a bind9 DNS record, this is an AD DNS record, this is a RedHat DNS record, this is a Route53 DNS record".
The "container landscape" shouldn't remotely resemble what it does today. The idea of a "container" should have been standardized in an agnostic way, without requiring all the (admittedly useful, but also completely unnecessary, and often burdensome) features Docker threw into their tool. Yes, many people's lives were made easier. But a whole lot of other lives were made harder, to the point of small economies built out of badly re-implementing and custom-integrating into one precious and incompatible concept.
I would call Kubernetes the open source Active Directory, but Active Directory is literally ten times more standards compliant.
There has been talks of moving one of these solutions to https://github.com/external-secrets ownership, but nothing has happened around that yet.
That is how kubernetes secrets work so I wouldn't call it unusual
Kubernetes provides an easy-to-use abstraction for the same, which ECS does not.
It actually does. You may, if you wish, have a volume and mount it is ECS tasks [0][1]. The issue above does not seem legit.
[0] https://docs.aws.amazon.com/AmazonECS/latest/developerguide/...
[1] https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGui...
As I said, try ECS.
Yes, k8s is a complex beast - but ECS isn't as clean as it looks.
Make a Parameter that reads from Secret Manager or Parameter Store in the Cloudformation template of your ECS Service, and pass the value to TaskDefinition as an environment variable. No need for volumes at all.