-
-
Notifications
You must be signed in to change notification settings - Fork 812
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support pushing secrets' metadata to providers #3353
Comments
.spec.template.metadata
Greetings @Skarlso @shuheiktgw, it seems that using PushSecret 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. |
We are facing the same issue with annotations. |
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.
No, we still have to update each provider to push the metadata.
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 🙂 |
.spec.template.metadata
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? |
@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 As mentioned above, do you think it makes sense to implement this feature in the k8s provider next? |
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.
The text was updated successfully, but these errors were encountered: