-
Notifications
You must be signed in to change notification settings - Fork 402
Consider merging with aws-secret-operator #47
Comments
Doh -- just when you think you've scoured the internet. Thanks @max-lobur. Yes, we agree, we should definitely consider merging. |
There's also this :) |
....and https://github.com/cmattoon/aws-ssm :) |
Ok ok, but how should we deal with it? What would be the right approach here for considering to merge? |
I believe the right approach would be to reach out to these projects and ask them if they want to unify their efforts in a single project. Also given that all of those are written in go, but the godaddy solution is written in JavaScript might proove difficult in merging. ;) Smallest common goal IMHO would be to could come up with a standard CRD that each of these projects implement as a provider - similar to how storageclass does it. |
Hi there, and thank you for reaching out! I am one of the contributors of https://github.com/ContainerSolutions/externalsecret-operator and I think that we would definitely benefit from aligning on a common CRD spec. We deliberately wanted to keep it simple, so our CRs currently look like this: apiVersion: externalsecret-operator.container-solutions.com/v1alpha1
kind: ExternalSecret
metadata:
name: example-externalsecret
spec:
Key: example-externalsecret-key
Backend: asm-example Our project supports different backends to store secret and that what the What are your ideas on how to unify the spec? |
I played around with the idea of doing something similar to what you get with StorageClass, PersistentVolumeClaim and PersistentVolume. I wrote the idea down in a gist to start a discussion about that (maybe it's overcomplicated): |
I like the idea of using annotations. We had a very similar implementation to support multiple backends on a single operator deployment: ContainerSolutions/externalsecret-operator#6 but didn't consider using annotations. We decided to simplify this to one operator deployment, one backend. I believe it is easier to reason about and demand namespace isolation to RBACs. See:
A few questions:
|
Note that this project holds the most stars of any of the aforementioned projects, FWIW. |
Given my requirements this is the one I was looking for: |
@ecout what do you mean by automatically refresh? KES does polling by configurable interval and refreshes the kubernetes secrets with the updated values from the backend. |
@Flydiverny Yes, I just tested this one today. It generates VERY verbose logs btw. Also, regarding this issue, why merge two completely different code bases written in different languages. |
Hej everyone, i opened #477 with a first draft to continue the discussion on the CRD topic. Let's assume we've found a common CRD, what's the next step then? Actual git-merging is obviously not an option, do we want to: technology-wise i'd strongly recommend using What do you think? |
First of all, thanks for keeping this effort alive. I even tried to get things rolling together with @slamdev, but other business got in the way. I truly believe there's space to build something cool for the Kubernetes community. Channeling our efforts in one common direction has the potential to have a great tool for secret management and achieve ultimate opensource glory I believe B is the best option. I also think golang is the right choice. For the github stars, I think if we play it right we can achieve the same level of popularity in a very short time. The real difficult part is how can we coordinate our efforts in order to make this happen? |
I would love for yall to jump in and help with https://github.com/itscontained/secret-manager. The goal is to do exactly what you have stated with a single CRD. |
As someone just starting out to use KES along with our GitOps setup, I would love to this project thrive. KES has a better idea than Sealed Secrets, which is perhaps the most popular way out there to use secrets along with GitOps, since using managed k8s by cloud providers are becoming the norm and it takes away the human element present in sealed secrets. Saying that, I want to provide some of my opinions, FWIW:
Also, we should have a single issue to have this conversation, as a related conversation is also taking place in #423 |
@moolen @riccardomc Transferring an existing repo to another account can transfer over the stars too. https://docs.github.com/en/github/administering-a-repository/transferring-a-repository#whats-transferred-with-a-repository . If we decide on a new org to have this project, I would suggest transferring this repo over to that account and then rework this repo itself if a conversion to go is planned. |
I think the CRD Spec in #477 is good enough to be implemented in a PoC, let's have a meeting to discuss futher steps on how to channel our efforts, find and organization, move code etc etc. I made a agenda here for I'll drop a message in slack to find a good date and update this comment. |
Closing this as there are undergoing efforts in https://github.com/external-secrets/external-secrets :) |
https://github.com/mumoshu/aws-secret-operator is a very similar concept, consider merging two projects.
The text was updated successfully, but these errors were encountered: