Thanks for clarifying! In that case, you may want to consider the following ideas. There’s certainly still parts there that can be improved (suggestions or PRs welcome, of course!), but hopefully they’ll at least get you started…
If you’re already using Helm for other services and have found a way to handle sensitive input to Helm charts that you’re happy with, you may want to look at the lastest Spinnaker Helm chart, which uses Halyard internally.
Otherwise, you could:
- Keep your halconfig in a code repository, using password files rather than passwords to avoid leaking credentials
- A small number of Spinnaker account types don’t support password files as yet; that’s being worked on. A workaround for now is “patch” the halconfig just before it’s applied - see below
- Optionally, configure a build job to run on pull requests that runs “hal config” against the proposed halconfig, with (potentially dummy) password files at the locations referenced in halconfig
- On merge to master, a build job runs “hal deploy apply” using the updated halconfig, this time using password files containing the correct values, mounted at the locations referenced in the halconfig
- You may still want to consider making a backup TAR of the halconfig after it’s successfully applied, since that archive is not dependent on any external files (such as the password files) and is thus slightly safer for emergency restores and audit purposes. The backup should be stored in a locked-down location.
- The repository containing your halconfig could also include definitions of Applications, or other configuration items in Spinnaker that are part of your standard setup
- You can use the spin CLI to create or update these in the same build job that runs on merge to master, after “hal deploy apply”
- If you’re using Fiat, we recommend that you create a robot account for this, store its credentials in a password file as for Halyard, and mount this file as “~/.spin/config” when running the build job