Consider merging with aws-secret-operator

[max-lobur]

https://github.com/mumoshu/aws-secret-operator is a very similar concept, consider merging two projects.

[silasbw]

Doh -- just when you think you've scoured the internet. Thanks @max-lobur. Yes, we agree, we should definitely consider merging.

[lhotrifork]

There's also this :)
https://github.com/ContainerSolutions/externalsecret-operator

[silasbw]

....and https://github.com/cmattoon/aws-ssm :)

[JacopoDaeli]

Ok ok, but how should we deal with it? What would be the right approach here for considering to merge?

[reegnz]

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.
Maybe open github issues in each of those projects that links to this issue to start a discussion?

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.

[riccardomc]

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 Backend key is used for.

What are your ideas on how to unify the spec?

[reegnz]

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):
https://gist.github.com/reegnz/acc1f97fe3e78746394103e9c96d9c76

[riccardomc]

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:

• Introduce namespace restriction ContainerSolutions/externalsecret-operator#10
• Make backends configurable ContainerSolutions/externalsecret-operator#18

A few questions:

• How would you handle multiple deployments of the same operator with distinct backends?
• How do you handle configuration of secret backends? Rely entirely on IAM and AWS SDK credentials discovery?

[chtompki]

Note that this project holds the most stars of any of the aforementioned projects, FWIW.

[ecout]

Given my requirements this is the one I was looking for:
https://github.com/mumoshu/aws-secret-operator
I need the Operator to be able to automatically refresh, otherwise there's no real data decoupling and might as well do it with regular secrets and KMS.

[Flydiverny]

@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.