liquidware-ninjaSecond brain & toolkit
Personal project. Research and learning only. Not for production. No warranty.Not for production
  • Built on my own time for research and learning. Not affiliated with, endorsed by or supported by my employer, Liquidware or Microsoft.
  • Bring your own Liquidware licenses. Don't run any of it in production or against tenants and subscriptions that matter. Test in a dedicated lab first.
  • Provided "as is", without warranty of any kind, under each repository's license. You use it at your own risk and own the Azure charges it incurs.
  • Contributions and forks are welcome and encouraged on public repos. See Contribute.

0006. Generated credentials go to Key Vault, and reruns reuse them

proposedReviewed 2026-10-18Source: decisions/0006-credentials-in-key-vault.md

Context and Problem Statement

Azure sets each appliance's admin password at creation, and the appliance keeps it. A rerun that generated a new password would no longer match. Operators shouldn't have to remember or paste secrets. Where does the password live?

Considered Options

  • Generate it once, store it in a Key Vault in the environment, read it back on every rerun
  • Ask the operator for a password on each run
  • Store it in a parameters file

Decision Outcome

Chosen option: "Generate once, keep in Key Vault", because nobody has to remember it, it never passes through chat or the repo, and reruns stay consistent with the appliances.

Consequences

  • Good, because secrets never leave Azure.
  • Bad, because the deployer needs rights to grant themselves Key Vault read access (Owner, or Contributor plus User Access Administrator).
  • Bad, because a lost vault means a lost password; the deploy script stops rather than generate a new one, and a soft-deleted vault is recovered.
Linked from 2 pages