-
Notifications
You must be signed in to change notification settings - Fork 28
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
SecretTemplate supports ytt templating #70
Comments
@Samze This does raise some new scope for Secretgen-controller, because currently it does not depend on any external binaries such as Is there a way to solve the problem you're posing by using -- maybe? -- kapp controller's existing templating to output something that the secret templates could consume? We're trying to imagine how an AppCR could fit into this flow and tbh it's pretty awkward :) But it does feel appealing to imagine how else we could solve this other than by adding complexity to the sg-c build and deploy process before starting on this path. |
Apologies for the late response! @joe-kimmel-vmw if there are concerns around including an external binary, can we not just consume I'm not sure I fully understand the suggestion of using AppCR (or other carvel tools) to solve this problem. Could you elaborate further? |
sorry , yup - you're right. just consume it as a go module. |
Looking at this again, I think it maybe a bad idea to just inline the template on the Originally this: ---
apiVersion: secretgen.k14s.io/v1alpha1
kind: SecretTemplate
metadata:
name: generated-secret
spec:
serviceAccountName: my-resource-reader
inputResources:
....
ytt: |
#@ load("@ytt:data", "data") Should become this: ---
apiVersion: secretgen.k14s.io/v1alpha1
kind: SecretTemplate
metadata:
name: generated-secret
spec:
serviceAccountName: my-resource-reader
inputResources:
....
ytt:
template: |
#@ load("@ytt:data", "data") For example, perhaps we need to provide other metadata like ytt options, for example we could introduce The slight downside of this is that we already introduced jsonpath as |
@Samze take a look at ytt interface for rebase rules within kapp -- https://carvel.dev/kapp/docs/v0.51.0/config/#rebaserules. one thing that i think we need to be mindful about is that execution environment (e.g. format of well known data values, etc.) for configuration might change over time and that's why in kapp for example it's marked as V1. goal would be to avoid breaking any configurations that have been already written, but also allow to transition to newer contract version. |
In our ytt templates, we are currently creating a dockerconfigjson secret based on user-provided username/password data values file like this:
I am working to change this to allow the user to create their own generic secret containing the username and password, and then simply include the secret name and namespace in the values file. This is what I want the user-created secret to look like:
So far, my
and the user-provided values file would be:
For this to work,
I think all of this would be possible if I could define a ytt template like this:
Ideally, the user would not need to include the hostname in the secret with the username and password, but I think that would require me to be able to define an input source other than an existing resource on the cluster so that I could inject it at templating time from the data values input. |
wondering if there has been activity on this in the background? |
I don't think there has been any updates on this, @Samze is that fair? Do you think this is something you all would be prioritizing at some point? Or shall I assume that this is fairgame to any contributor and we should not expect this to be done by you all? |
Describe the problem/challenge you have
#66 Introduced the SecretTemplate API. This allows you to define arbitrary input resources that are used to generate a new Kubernetes Secret based on templating.
For a first pass, we just supported a simple jsonpath based template. However for more dynamic cases we should support a ytt templating. This would allow the entire generated secret to be templated.
Describe the solution you'd like
We should introduce an optional
ytt
block as an alternative totemplate
that loads input resources as data.values. So this might look like:Anything else you would like to add:
n/a
Vote on this request
This is an invitation to the community to vote on issues, to help us prioritize our backlog. Use the "smiley face" up to the right of this comment to vote.
👍 "I would like to see this addressed as soon as possible"
👎 "There are other more important things to focus on right now"
We are also happy to receive and review Pull Requests if you would like to work on this issue.
The text was updated successfully, but these errors were encountered: