[feature] Ability to annotate values as defaults that should be changed

[paulczar]

It's important to give people software that just works. However its also important to encourage people to act securely. It would be great to be able to annotate values as "defaults that should be changed". ytt should list any of these defaults that aren't changed when I run it, and maybe even give me a "are you sure y/n" prompt.

This would allow me to put in default passwords and self signed certificates that work out of the box for dev situations, but can be gated on taking affect in production or other places.

[cppforlife]

note that we have some related work happening around schema proposal: https://github.com/k14s/ytt/issues/103.

"defaults that should be changed"

this is an interesting concept that ill have to think a bit more about.

This would allow me to put in default passwords and self signed certificates that work out of the box for dev situations

im on the fence about providing "default" secrets. it just seems to dangerous. even if it's loudly noted that values need to be changed to be secure, i bet it still would be too easy to not change them. i recommend taking a look at this project in secrets space: https://github.com/k14s/secretgen-controller to generate creds on cluster which moves this responsbility away from templates (we will be moving to cluster side secret generation in cf-for-k8s at some point)

[paulczar]

I think this would work well together with a secret generator controller like you mention above, you could use the same annotations to tell ytt to request secrets from the controller if it [or a flag] is present.

However if I have a simple tiered app with a web service and a database service and I want a person to be able to test it in dev easily, I don't think asking them to install a controller+crds first is very friendly.

I'm not asking you or your projects to supply default passwords, I'm asking for the freedom to do that myself as a user of ytt.

The alternative that might work though, is if I can annotate secrets that I want to be autogenerated, and have ytt generate those secrets into a values file and then use that values file to crete my manifests. That would leave me a good way to automatically generate the secrets, but also have the appropriate artifact so that I can re-deploy without needing to regenerate the secrets again.

might even be able to use the secretgen-controller as a library to create the data.

[cppforlife]

you could use the same annotations to tell ytt to request secrets from the controller if it [or a flag] is present.

when secregen-controller would be used, secrets wouldn't even be known to a templating layer. it would just be some CR sitting next to other resources.

I don't think asking them to install a controller+crds first is very friendly.

that's fair. i think solution to that might be to have CLI mode for secretgen, where you would be able to run it like so: ytt -f ... | secretgen --store ... | kapp deploy .... from a perspective of configuration nothing changes.

The alternative that might work though, is if I can annotate secrets that I want to be autogenerated

why bother asking for secrets that can be auto generated?

I'm not asking you or your projects to supply default passwords, I'm asking for the freedom to do that myself as a user of ytt.

im just trying to dig at "root use case" to brainstorm for alternative and may be even better solutions. ultimately features that ytt exposes make indicate to end users encouraged patterns hence i want to be very careful about what we encourage.

another alternative you might want to consider is to provide an optional data values file (e.g. config-optional/insecure-dev.yml) so that users can explicitly pick it to apply for insecure dev cases: ytt -f config/ -f config-optional/insecure-dev.yml

[paulczar]

another alternative you might want to consider is to provide an optional data values file (e.g. config-optional/insecure-dev.yml) so that users can explicitly pick it to apply for insecure dev cases: ytt -f config/ -f config-optional/insecure-dev.yml

Hrmmm, yeah actually something as simple as that could provide the "mean time to dopamine" for people trying out a new thing build with ytt.

why bother asking for secrets that can be auto generated?

True, what I'm thinking of could probably be solved with a if value is empty, create this secret-generator resource to have the controller generate it for me statement which ytt would already support.

[paulczar]

another alternative you might want to consider is to provide an optional data values file (e.g. config-optional/insecure-dev.yml) so that users can explicitly pick it to apply for insecure dev cases: ytt -f config/ -f config-optional/insecure-dev.yml

This would be good to add to documentation as a good practice for both supplying working ytt manifests, while remaining "secure by default".

[pivotaljohn]

Dropping a note here that this issue was considered as #561 was being drafted. The question we asked was, "how might this idea relate to introducing validations in schema over data values?"

TL;DR. for now, this is not yet in scope and not included in #561.

[pivotaljohn]

Something to add to this discussion:

What if ytt could operate in a mode where if a data value is null, then the first example is used as the default value.

#@data/values-schema
---
...
#@schema/enum ["oidc", "ldap"]
#@schema/example ("Connect with oidc", "oidc")
connector: ""

.. and then ...

$ ytt -f config/
# runs with `data.values.connector = ""`

$ ytt -f config/ --data-values-use-examples
# runs with `data.values.connector = "oidc"`