Is your feature request related to a problem? Please describe.
When deploying a package or helm chart, quite often a default username or password is needed. Right now in order to ensure a secure password is chosen, users can opt to prompt the deployer for a value for these variables. To ensure that deployments are secure, we could instead have the default value for certain variables generated by zarf according to some cryptographic logic and with parameters the package builder lays out.
Describe the behavior you'd like
- Given a state
Given a variable that is intended to populate a password field
- When an action is taken
When the user deploys that package with that variable but does not populate it
- Then something happens
The the field is auto populated by a cryptographically secure value
Describe alternatives you've considered
The current prompting method is fine however it does mean the user has to generate, provide, and track the values themselves.
An alternative could be to deploy a secret generator into the cluster and use that, but that gets complicated with config and overrides.
Additional context
Care would need to be taken to ensure that future updates to the package don't inadvertently change the secrets and break the deployed application being upgraded
Is your feature request related to a problem? Please describe.
When deploying a package or helm chart, quite often a default username or password is needed. Right now in order to ensure a secure password is chosen, users can opt to prompt the deployer for a value for these variables. To ensure that deployments are secure, we could instead have the default value for certain variables generated by zarf according to some cryptographic logic and with parameters the package builder lays out.
Describe the behavior you'd like
Given a variable that is intended to populate a password field
When the user deploys that package with that variable but does not populate it
The the field is auto populated by a cryptographically secure value
Describe alternatives you've considered
The current prompting method is fine however it does mean the user has to generate, provide, and track the values themselves.
An alternative could be to deploy a secret generator into the cluster and use that, but that gets complicated with config and overrides.
Additional context
Care would need to be taken to ensure that future updates to the package don't inadvertently change the secrets and break the deployed application being upgraded