Source from secret

[immesys]

There are many cases where the secret data is generated by a third party tool that you cannot alter to make use of this CRD. Is there a way to have the contents be "the contents of X secret in Y namespace" ? The operator would then watch the source secret for changes and sync it to all the namespaces that the ClusterSecret crd specifies?

[zakkg3]

It's an interesting use case.
We can address this including an optative field source (instead of data)
On ClusterSecret object creation, the operator will sync the secret to the matching namespaces and add an annotation with the Clustersecret's ns/name on the source secret in order to then watch for secret events filtering by this annotation (exist).

apiVersion: clustersecret.io/v1
kind: ClusterSecret
metadata:
  name: imported-secret
source: namespace/secret

[immesys]

Would you be interested in a PR for this functionality?

[immesys]

Incidentally, can we avoid relying on an annotation placed on the source secret? That secret might be "owned" by some other operator (which is true in my case) which may overwrite any additional annotations placed on it. Presumably the operator, after taking stock of the existing ClusterSecrets, can maintain an internal list of source secrets and have independent watches for each of them?

[zakkg3]

Sorry for the delay, I dont think maintaining an internal list its a good idea, this should be idem potent and fault tolerant, if I delete de pod it should come back and have the same state. We could save data in etcd. But the general approach seems to be with annotations (which at the end is etcd too). Why another operator will may overwrite an annotation?

[Arano-kai]

You can use same approach as OpenShift/k8s secrets linkage to ServiceAccount:

kind: Secret
  annotations:
    kubernetes.io/service-account.name: my-sa
    kubernetes.io/service-account.uid: 5b67889b-d262-11ea-a590-0050569736de
...

So, use annotation in ClusterSecret like clustersecret.io/source-secret-name: my-secret and clustersecret.io/source-secret-namespace: my-ns

[zakkg3]

After the latests PR merged. now we have a much stable version.
So back to this.
@Arano-kai thanks for your imput, the problem here is not how to store the source on the Clustersecret object it is about how to watch for changes on all the source secrets, how do we keep a list of secrets to watch for?

If we have to avoid using annotations on the source secret:
We have to watch for secret modification in general and then if this secret matches a list of secrets sources, then react to this. For Keeping in memory a list of sources secrets, we need to be sure what is in memory matches what is in etcd (this is anyway needed and it is in the to-do list).

But, watching for all secrets modifications and iterating through all the clustersecrets doesn't seems to be the most efficient. Imagine if we have 10k clustersecrets, lets say users keys or something like... this would not scale :/

@immesys I still have the question, how a 3th party will overwrite an annotation, why? and in case of overwriting / modification / deletion the operator will receive this event as its watching for this secret, so we can hanadle :)

And... of course PR are always welcome :)

[rustysys-dev]

@zakkg3 Something like what is done in this operator could be accomplished.

https://github.com/IBM-Cloud/kube-samples/tree/master/secret-sync-operator

[jbianquetti-nami]

Another approach can be using a notation similar to this one, which is inspired by k8s secrets, so it enables more granularity

apiVersion: clustersecret.io/v1
avoidNamespaces:
- default
data:
  .dockerconfigjson:
  valueFrom:
    secretKeyRef:
      key: .dockerconfig.json
      name: github-dockerconfig
kind: ClusterSecret
matchNamespace:
- .*
metadata:
  annotations: {}
  labels:
    name: github-dockerconfig
  name: github-dockerconfig
  namespace: clustersecret
type: kubernetes.io/dockerconfigjson

[djboboch]

Hi, what is the status on adding this feature. As I have searched this is the only project with such proposal.

[zakkg3]

Source from Secrets (reference an existing secret) is ready to be tested in branch 0.8 . (#34)

Update the deployment:

curl https://raw.githubusercontent.com/zakkg3/ClusterSecret/0.8/yaml/02_deployment.yaml | kubectl apply -f -

Try with an example object:

curl https://raw.githubusercontent.com/zakkg3/ClusterSecret/0.8/yaml/Object_example/value-from-obj.yaml | kubectl apply -f -

I would appreciate if someone can test this.
It's tested on k8s 1.21.4 so far.

[CryptoNeutron]

LGTM @1.21.2

[zakkg3]

Tested on 1.23.4 too.
going to merge and close.

[MarkCupitt]

Using this, so far no issues Kubernetes V 1.24