Skip to content

Deployment exposes a secret in output#

Security · Deployment · Rule · 2022_06 · Critical

Outputting a sensitive value from deployment may leak secrets into deployment history or logs.

Description#

This rule checks for cases when a sensitive value is insecurely output from a deployment or module. For example, if a parameter is marked as secure and then assigned to an output value; or a list* function is used to retrieve an account key and then assigned to an output value.

When deploying Azure resources across multiple deployments it is often helpful to pass values between them as outputs. By default, outputs are recorded as clear text within deployment history and logs. These values can be retrieved by anyone with read access to the deployment history and logs. Logs are often exposed at multiple levels including CI pipeline logs, Azure Activity Logs, and SIEM systems.

For passing sensitive values such as keys or tokens use secure outputs. Secure outputs use the @secure decorator in Bicep or the secureString / secureObject type. Outputs that are marked as secure are not recorded in ARM deployment history or logs.

Additionally, it is often unnecessary to output sensitive values from a deployment since Azure provides, multiple ways to retrieve sensitive values from resources at runtime such list* functions. Avoid unnecessarily outputting and handling sensitive values from a deployment.

Secret rotation — SE:09 Application secrets

If a secret has already been exposed by a previous insecure deployment, rotate it immediately to prevent unauthorized access to your resources.

Rotating a secret involves changing or regenerating the secret value and updating all dependent resources with the new value. This process should be done in a secure manner to prevent the new secret from being exposed.

Recommendation#

Consider removing any deployment output values that return secret values or use secure outputs.

Examples#

Configure with Bicep#

To configure deployments that pass this rule:

  • Add the @secure() decorators on parameters or outputs that contain sensitive information.

Example using @secure() annotation on a parameter:

Azure Bicep snippet
@secure()
@description('Local administrator password for virtual machine.')
param adminPassword string

Example using @secure() annotation on an output:

Azure Bicep snippet
@secure()
output accountKey string = storage.listKeys().keys[0].value

Configure with Azure template#

To configure deployments that pass this rule:

  • Use the secureString or secureObject type on parameters or outputs that contain sensitive information.

Example using secureString type on a parameter:

Azure Template snippet
{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "adminPassword": {
      "type": "secureString",
      "metadata": {
        "description": "Local administrator password for virtual machine."
      }
    }
  },
  "resources": []
}

Example using secureString type on an output:

Azure Template snippet
{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [],
  "outputs": {
    "accountKey": {
      "type": "secureString",
      "value": "[listKeys('storage', '2021-09-01').keys[0].value]"
    }
  }
}

Notes#

When using Bicep, the built-in linter will also automatically check for common cases when secrets are output from a deployment.

Comments