Problem
I have experience with Terraform and AWS. Please bear with me as I experiment with Bicep and Azure:)
The random password resource in Terraform is used to generate random passwords. This was then saved in the AWS Systems Manager Parameter Store as a value. This allowed us to create and store secure (enough…) passwords in a secure database without having to enter or even remember the password. It would be logged if someone needed to know the password. Beautiful 😉
Now…
I’m not sure how I’d go about doing anything like this using Bicep. I’ve only been able to locate the uniqueString() function. However, this only generates 13-character random strings with no “special” characters such as!@#$ percent &*()- =+[]>:? and so forth.
I don’t want any form of line in my code that sets the secret to some easily accessible value for obvious reasons. That’s why in Terraform, we used random password.
What is the best way to tackle this problem in Bicep?
I found Vivien Chevallier’s blog post “Automatically construct a password for an Azure SQL database with ARM template,” however it’s not good, in my opinion. The user adds a constand prefix of “P” and a suffix of “x!” to the password to get around the uniqueString() function’s flaws and make it conform with the password complexity criteria. This lowers the password’s quality because there are now three known characters. Out of a total of 16,
Asked by Alexander Skwar
Solution #1
uniqueString() isn’t designed to generate passwords; instead, it’s designed to generate resource names.
There is no purpose-built technique to generate a password in a Bicep/ARM template that I am aware of. We used a password generator to produce passwords of adequate length and complexity, which we then stored as secrets in Azure DevOps variable groups. Then we provide them as secure string arguments to the template, so they don’t get logged anywhere. We also don’t save those generated passwords anywhere else; after generating and storing them in Azure DevOps, they’re thrown away.
Answered by juunas
Solution #2
Bicep does not support this, and there are no such intentions in their repo based on a request.
Answered by DreadedFrost
Solution #3
The goal of Bicep is to produce fully idempotent templates, which means you should get the same result every time you try to deploy something. As a result, both randomString and newGuid accept parameters that can be used to seed the result, but the new values you enter will always produce the same result.
For the reasons stated above, you should use your own generated password to start template deployment outside so that the Bicep template does not change from one deployment to the next. Furthermore, because output values are all logged indefinitely, it’s not a good idea to disclose the password in an output value, thus I highly advocate writing out the value to a Key Vault secret, as seen below.
@secure() //Prevents it from being logged, but also removes it from output
param password string = newGuid() //Can only be used as the default value for a param
@description('The name of the Key Vault to save the secret to')
param KeyVaultName string
@description('The name of the secret in Key Vault')
param KeyVaultSecretName string
//Save as Key Vault secret
resource KeyVault 'Microsoft.KeyVault/vaults@2021-06-01-preview' existing = {
name: KeyVaultName
}
resource KVSecret 'Microsoft.KeyVault/vaults/secrets@2021-06-01-preview' = {
name: replace(replace(SecretName, '.', '-'), ' ', '-')
parent: KeyVault
properties: {
contentType: 'text/plain'
attributes: {
enabled: true
}
value: password
}
}
output PasswordSecretUri string = KVSecret.properties.secretUri
Then, knowing that the GUID output will be different every time you run the Bicep deployment, you may use it as your password for your use-case.
Answered by Whit Waldo
Post is based on https://stackoverflow.com/questions/68063937/bicep-creating-random-string