Support pushing secrets' metadata to providers

[ron1]

Describe the bug
PushSecret fails to push .spec.template.metadata.

To Reproduce
Steps to reproduce the behavior:
With ESO v0.9.13 installed on kubernetes 1.26.5, add an annotation and label to the sample PushSecret in the docs modified to use the k8s provider. Note that the target Secret does not have the added annotation or label.

Expected behavior
The provided metadata annotations and labels are added to the target Secret.

[ron1]

Greetings @Skarlso @shuheiktgw, it seems that using PushSecret .spec.template.metadata to push metadata competes a bit with the use of .spec.data[0].metadata previously implemented in PR #2600. Am I correct that GCP is currently the only provider that implements the .spec.data[0].metadata approach? Also, am I correct that only one approach should be used at a time?

The template-based solution is nice in that it aspires to work across all providers. Given this bug, it is unclear whether this is a possibility or not.

The template-based solution might also allow setting templated metadata values using variables. When cloning a Secret using the Kubernetes provider, this would allow propagation of metadata from the source secret to the target secret. Let me know if I should open a separate issue for this feature.

[FullyScaled]

We are facing the same issue with annotations.

[shuheiktgw]

Hi, thanks for reporting the issue. I briefly read the code around push secret templating, so let me share what I found about it. First of all, push secret templating is like a filter applied to the original secret before pushing it to the target provider. Therefore, changes to the source secret metadata are simply ignored right now, since no provider pushes the metadata. We may be able to think of some ways to map the secret metadata to the upstream metadata, but note some providers do not have annotations or labels so the mapping is not that simple.

The template-based solution is nice in that it aspires to work across all providers. Given this bug, it is unclear whether this is a possibility or not.

No, we still have to update each provider to push the metadata.

The template-based solution might also allow setting templated metadata values using variables. When cloning a Secret using the Kubernetes provider, this would allow propagation of metadata from the source secret to the target secret.

This is a valid argument, even though as I commented above, we still need to think of an interface to the secret's metadata to provide-specific secret metadata.

Overall, this looks like not a bug, but more like a feature request to me, so I'll change the label so 🙂

[ron1]

Hi @shuheiktgw, thanks for getting back to me.

Since the PushSecret templating example in the docs includes the metadata annotations and labels fields, the PushSecret schema includes them, and since the unit test populates the fields, I would lean more towards categorizing the issue as a bug.

As far as provider prioritization is concerned, I would suggest making the k8s provider a top priority.

Also, do you think it makes sense to preserve both approaches since templating is more about filtering? If so, any thoughts about how to reference the source metadata as template variables?

[ron1]

@Skarlso @shuheiktgw, for now, WDYT about removing references to the non-functional metadata templating feature from the docs/schemas and focusing on propagating to non-GCP providers the solution already implemented in PR #2600 that leverages .spec.data[0].metadata?

As mentioned above, do you think it makes sense to implement this feature in the k8s provider next?