How to define eJSON Secret labels?

[zedtux]

I'm using the ejson gem in order to encrypt the secrets, and I'd like to set labels.

I tried the following, but it didn't work:

{
  "_public_key": "xxxxxxxxxxxxxxxx",
  "kubernetes_secrets": {
    "redis-auth": {
      "_type": "Opaque",
      "_labels": {
        "_label1": "value1"
      },
      "data": {
        "password": "EJ[1:kFpfbHmpwOmDEaNjU9F0ThZg...Cc+A9+uEepPiN4=]"
      }
    }
  }

Can you please guide me on how to add labels to secrets using ejson?

[dturn]

Hi @zedtux we don't currently support setting arbitrary labels. The code you're looking for is here. Assuming your example above is valid ejson (I haven't looked), is this a feature you'd be interested in adding? If so can you tell us a bit more about your use case?

[zedtux]

Thank you @dturn for your answer.

Thank you for providing a link to the right peace of code 👍.

I would use those labels to filter the output of the commands to list the content of a given namespace for a given selector, for example everything about MongoDB and it would list the secrets, services, and so on.

It doesn't look to hard to implement, but I'm too busy right now to implement it by myself. No promises, but I will try to do it.

[dturn]

In case you missed it in the code snippet, any selectors used in the deploy commands are turned labels on the secrets generated.

[zedtux]

You are very right, I missed it and thank you!

[breunigs]

My use case is to set standard Kubernetes labels that tie a deployed resource to a service catalog. Namely, the well known labels app.kubernetes.io/name, instance, and version. Especially version makes re-using the pruning selector non-viable, but this is also the case for the others on identifier/name changes.

I patched this in locally to assess "upstream mergability", and it's not a lot of SLOC for the approach "extra CLI param looped through to Krane::EjsonSecretProvisioner / Krane::KubernetesResource, which does the patching". The patch can be even smaller if making this specific to ejson secrets. It'd be convenient to be able to set the mentioned labels from a single place, though, instead of having to set it sometimes on the templates, and sometimes through the CLI. No strong opinion on that one, though. Same for if labels set on CLI win over the ones in templates, vice-versa, or error.

If you'd be generally willing to support this use case, please let me know and I can go through my org's CLA signing process and clean up the patch.