Support setting package variables about uds-cli HOT 7 CLOSED

I have a secret that needs to be passed into a specific package in the bundle as a zarf variable. I could set this in a uds-config.yaml but that is a security risk, especially in any CI, preferably I could do something like

uds bundle deploy some-bundle.zst --set=bundle.deploy.zarf-packages.needs-secret.set.secretvar=${SOME_SECRET}

It's just another way of declaring what the uds-config.yaml file does

from uds-cli.

Thanks for this @rjferguson21 ! Can you elaborate on the use case for these additional methods? Or does the current uds-config.yaml method feel weird?

from uds-cli.

My understanding is that the uds-config.yaml would not be published with the bundle artifact. If that is the case it would be impossible to publish a bundle that specified different zarf variables than the package defaults.

In my mental model the published bundle artifact is similar to the default values.yaml that come with a helm chart. They are the best effort defaults from the bundle publisher. I think uds-config.yaml is a fine solution for a customer deployment, but I think it makes sense to allow some kind of configuration to be applied to the packages by the bundler. Some of this might addressed by #19 but I think there are distinct use cases where you'd want to explicitly set package variables without using globals.

The --set=dubbd.FOO=bar might be less common but would come in handy for one offs like in CI or in places where you did not want to mutate a source controlled file like uds-config.yaml

from uds-cli.

Chatted about this @corang and @mikevanhemert . I think the direction to go is bundling the uds-config.yaml in the bundle artifact

from uds-cli.

I think the --set flag needs to be added too, that way secrets that are passed in via package variables don't need to be written to a file @UncleGedd

from uds-cli.

--set scares me a bit. Thinking of the broader UDS UX goals, ideally there is a single way to do things, including setting variables. Can you provide an example where --set is absolutely necessary?

from uds-cli.

Gotcha, deploy-time secrets is something I haven't fully thought through. I think the current method is to:

• set the secret at deploy-time in Zarf as a variable and export it in the bundle
  • for example, RDS connection info can be grabbed from TF outputs and put into a Zarf var inside a Zarf component
• if another package in the bundle needs that secret, it would import it

^^ this assumes that the secrets are generated by the underlying Zarf packages. But there are def situations where this isn't the case (ie. certs, API keys, enterprise licenses)

from uds-cli.