Creating child resource if not exist - (Creating KeyVault secret if not exist)

[erapade]

I would like to create a child resource, in this case a KeyVault secret if not already exists, but I cant figure out how to do this

The reason for this is that SQL servers requires a admin account and admin password, but I nether need or want these since I use Azure AD authentication instead. But... For redeployment reasons I need to save/know the password, so my thinking is to save the password in a KeyVault and generate the password (create the KeyVault secret child resourse) the first time only.

Any idea how to implement a logic that only creates a resource (or maybe simplier a child resource) only if it doesn't exist without using deployment scripts

[brwilkinson]

It's a chicken or egg scenario for sure.

I always bootstrap a keyvault and then securely/manually enter the secrets ahead of time and also import certs. That way I can securely read them back during the deployment via a Template Parameter, which is a (I think the only) secure way to handle secrets as part of deployments, unless you are using list*() to read them from somewhere else.

What is your plan or do you have another (secure) way to generate a secret during the deployment which you then plan to write it into the keyvault initially?

[erapade]

Thanks @brwilkinson, Much can be said on SQL security concerning identities. MS has improved lately by adding the feature of only allowing AAD authentication, and this way we don't need to bother about an local administration accounts since MS then randomize an admin account name (and probably also the account password and hopefully throws the password in the trash).

But for situations where we still need none AAD accounts for access, we need to handle the administration account. Since we have no use for this Admin Account, we can do the same as described above, just randomize both the account name and password and then forget about them. But since they are needed for re-deployment, we need to keep them safe.

To generate a secret during development one could use custom/deployment code and [System.Web.Security.Membership]::GeneratePassword(128,10), but a much simpler way to just use the newguid() function. If newguid() isn't trusted one could maybe concatenate two newguid() or scramble then in any other way.

But as my initial question, how can my bicep code enter the secret values in the vault only when they don't exists?

[brwilkinson]

But as my initial question, how can my bicep code enter the secret values in the vault only when they don't exists?

DeployIfNotexist is not something that is supported.

--

Given your use case/specification of not wanting to use the password, you may get away with the following workaround?

Create a module with a secure string decorator

@secure()
param saPassword string

Then when you call the module, generate a new password each deployment. It will always change, however if you don't need to use it then that will not matter and you can reset it if you do need to use it.

module SQL 'SQL.bicep' = {
  name: 'dp${Deployment}-SQL'
  params: {
    saPassword: guid()
    otherSQLparam: otherValue
  }
}

With that method you would not be exposing the guid/password anywhere as part of the deployment since it will be obfuscated being a secure string value.

Do you think that scenario may work for you?

I haven't tested the code, you may have to also cast the guid to a string, I may give it a test to try it out and test the scenario further. Also test in setting the guid as the pw on the SQL server.

I don't see any pw limitations in the API docs...
https://docs.microsoft.com/en-us/azure/templates/microsoft.sql/servers?tabs=bicep#serverproperties

[erapade]

Thanks @brwilkinson,
After some modifications this works like a charm. I thought that the password used for re-deployment needed to be the same, but that is not the case, the password can change between deployments, but the account name can not.

So my final solution for this is:

@secure()
param password string = newGuid()
param account string = guid('some text')


module SQL 'SQL.bicep' = {
  name: 'TestingSQL'
  params: {
    saPassword: password
    saAccountName: account
  }
}
//output password string = password
//output account string = account

So I use newGuid() for the password, this will generate a new password for each deployment. Then I use guid() with some standard text for the account name, this will generate the same account name every time, just a bit scrambled. I will in my final solution replace "some text" with something else, maybe the name of the azure resource concatenated with something else so no one outside of the deployment process will know the seed for guid()

The best thing with this approach is that I don't need the KeyVault, everything can be handled very simple within the bicep code

And maybe maybe, as this is a open forum where we discuss security settings, I will concatenate the password with something else before sending to the SQL module, maybe saPassword: '${password} my secret' ;-)

[erapade]

And a pure sql.bicep example would then look like below. Please note that azureADOnlyAuthentication is set to true by default since this is preferred.

param sqlServerName string
param sqlLocation string = resourceGroup().location
param azureADOnlyAuthentication bool = true
param sqlAdminName string = guid(sqlServerName)
@secure()
param sqlAdminPassword string = newGuid()

resource sqlServer 'Microsoft.Sql/servers@2021-02-01-preview' = {
  name: sqlServerName
  location: sqlLocation
  properties: {
    administratorLogin : azureADOnlyAuthentication ? null : sqlAdminName
    administratorLoginPassword: azureADOnlyAuthentication ? null : sqlAdminPassword
    administrators: {
      administratorType: 'ActiveDirectory'
      azureADOnlyAuthentication: azureADOnlyAuthentication
      principalType: 'Group'
      login: 'Priviledge Access group'
      sid: '5d26da54-de7a-4cbe-aeaf-6c3d1e414085'
    }
  }
}

output sqlLocation string = sqlLocation
output azureADOnlyAuthentication bool = azureADOnlyAuthentication
output sqlAdminName string = sqlAdminName

Since I don't want the AAD Administrator role assigned to my self since this would have given me unwanted DBO access to all the data bases, I have chosen to use a security group instead. The intension is to have Privilege Access control this group so that I can evaluate my credentials when needed

[brwilkinson]

@erapade glad that you came up with a working solution for your needs.

I was thinking, if had any need, you could also write the secret back to the keyvault, that way you could keep the current password and any history of passwords in the keyvault (if you did ever need them for reference).