linter rule: outputs-should-not-contain-secrets

[StephenWeatherford]

Parity with TTK: https://docs.microsoft.com/en-us/azure/azure-resource-manager/templates/template-test-cases#outputs-cant-include-secrets

Fixes #3973

Proposed documentation

Outputs should not contain secrets

Code: outputs-should-not-contain-secrets

Description: Don't include any values in an output that could potentially expose secrets. For example, secure parameters of type secureString or secureObject, or list* functions such as listKeys.

The output from a template is stored in the deployment history, so a malicious user could find that information.

The following example fails because it includes a secure parameter in an output value.

@secure()
param secureParam string

output badResult string = 'this is the value ${secureParam}'

The following example fails because it uses a list* member function in an output.

param storageName string
resource stg 'Microsoft.Storage/storageAccounts@2021-04-01' existing = {
  name: storageName
}

output badResult object = {
  value: stg.listKeys().keys[0].value
}

The following example fails because it uses a list* function in an output.

param storageName string
resource stg 'Microsoft.Storage/storageAccounts@2021-04-01' existing = {
  name: storageName
}

output badResult object = {
  value: listKeys(resourceId('Microsoft.Storage/storageAccounts', stg.name), '2021-02-01')
}

The following example fails because the output name contains 'password', indicating that it may contains a secret

output accountPassword string = '...'

[anthony-c-martin]

This needs discussion - currently we have no mechanism in Bicep to return secure outputs from modules. It feels like we ought to prioritize #2163, otherwise it'll be difficult to practically action any fix for this linter rule without significant restructuring of the deployment and additional verbosity.

[alex-frankel]

I'm all for prioritizing #2163, but until that is done, I think this is an important linter check. You are right that refactoring this is not a quick change, but it is an important one.

[StephenWeatherford]

I had asked Brian:

What do people do do fix this? It would think this type thing would be common, especially from a nested template? (Or are nested templates excepted?)

his answer:

nested templates are not excepted... you would pass the resourceId of the resource you need and then list inline where it's used.

[StephenWeatherford]

@ucheNkadiCode Added you as reviewer. The new strings are here: https://github.com/Azure/bicep/pull/4716/files#diff-79c99ca30f6a204d8d88d4804da49247990c9ddeb32282ad424763d739ee0ec3. You can also see the proposed documentation above, but there will be a separate review for that.

Example errors:

[StephenWeatherford]

@ucheNkadiCode Ready for string review

[ucheNkadiCode]

@ucheNkadiCode Uche Nkadi FTE Ready for string review

This looks good! Thanks for changing the "don't" statements to should not

[majastrz]