Using variable or parameter for output name

[kevball2]

I am looking to use a variable or parameter value to be used for an output name.

Situation: Adding secrets to a key vault in another Resource group. I have a module to add the secret to a key Vault by passing in all the related parameters. The drawback of this module is that I can't control the name of the output. This module would be used multiple times in this deployment (AppInsights, Storage account) Without being able to parameterize the output variable name I must create a module for each resource.

Is there some way I am missing for dynamically setting the output name?

[majastrz]

There is no way to set the name of the output dynamically. Would you be able to use an output of object type instead and set the properties dynamically? I don't have enough details about how you're setting this, but you can index objects by a string expression. For example, something like this would be valid:

param myParam string

module myModule '...' = {
...
}

output myOtherOutput string = myModule.outputs[myParam]

[kevball2]

param outPutName string

module myModule '...' = {
params:{
outputName: OutPutName
}
...

}

in that module the outPutName is going to be used to dynamically set the output variable name so I can use the module for resources that need it.

param outputName string

resource someResource '...' = {
...
}

output ${outPutName} string = someResource.properties.somevalue

[kevball2]

Sorry I did not read your response fully,

The goal was to set the output name dynamically so that I could re-use the module for any resource that required it. The use case now is adding connection strings to a key vault in a different resource group. Not being able to set the name mean I need to choose a more ambigous name for the output (e.g connectionString instead of appInsightsConnectionString or storageConnectionString) being able to give more descriptive names dynamically to those outputs would be helpful

[brwilkinson]

@kevball2

One comment here, is that it is not recommended to return secrets or connection strings in outputs. So you may want to consider an alternative strategy here.

If you have access you can use the list* functions or a reference to pull the value when you need them.

https://github.com/brwilkinson/AzureDeploymentFramework/blob/d4c80465358c199aaf01e2863daf315457db5870/ADF/bicep/AppServiceFunction.bicep#L125

        {
          name: 'Storage'
          value: 'DefaultEndpointsProtocol=https;AccountName=${SADiag.name};AccountKey=${SADiag.listKeys().keys[0].value}'
        }
        {
          name: 'APPINSIGHTS_INSTRUMENTATIONKEY'
          value: reference(AppInsightsID, '2015-05-01').InstrumentationKey
        }
        {
          name: 'APPLICATIONINSIGHTS_CONNECTION_STRING'
          value: 'InstrumentationKey=${reference(AppInsightsID, '2015-05-01').InstrumentationKey}'
        }

Another option can be to move towards managed identity where possible and for access to storage without using keys... althoug as shown in the example above that is not supported in all use cases.

Either way I think any API or Interface, should always have a fixed set of inputs and outputs and using generic names for those is a better design overall, which includes for Module design.

[kevball2]

thanks for the feedback @brwilkinson! I agree returning secrets or connections string is not a good option. In this case I am passing back the keyVault::secretName.properties.secretUri value to be used as a key vault reference (I wouldn't consider this secret but could be wrong). Since the key vault lives in a different resource group, I have to call it from a module to get the existing vault, then add the new secret and capture the URI to use for the app service deployment. To your point about of a fixed set of inputs and outputs , my goal was to have a generic module to call an existing keyvault and add the new secret and make it the URI available for use. Since the output variable can't be defined with a parameter that won't work. In most of our deployments there is a central key store for the application per tier (e.g. dev, test, prod). Maybe there is another way I should be looking to load new secrets to an existing Key Vault?

[brwilkinson]

I think you have most cases covered then, I would go with @majastrz suggestion above of returning an object.

@allowed([
  'dev'
  'test'
  'prod'
])
param enviro string = 'prod'

var connObject = {
    '${enviro}StringKV': 'xyz'
}

output connectionString object = connObject

However only populate the key for the environment that you are deploying?

Then when you reference it:

@allowed([
  'dev'
  'test'
  'prod'
])
param enviro string = 'prod'

var envirokv = ${enviro}StringKV

connStringModule.outputs.connectionString[envirokv]

[kevball2]

Thanks everyone for the feedback. Having a little time away from the issue and I realized I was needlessly complicating the problem.
having a generalized key Vault Secret module

param env string
param location string
param secretName string
param secretValue string

resource keyVault 'Microsoft.KeyVault/vaults@2019-09-01' existing = {
  name: 'kv-shared-${env}-${location}'
  resource secret 'secrets' = {
    name: secretName
    properties: {
    value:  secretValue
   }
  }
}

output keyVaultSecretUri string = keyVault::secret.properties.secretUri

all I need to do is name the module for the associated service secret being saved to the key vault.

module appInsightSecret 'keyvaultSecret.bicep' = {...}

[brwilkinson]

okay thanks for confirming. That looks very 'Modular' so looks like a great approach.