azure marketplace deployment is rejected due to marking outputs as secure

Hello Rick Huebner,

Thank you for posting your question in the Microsoft Q&A forum. 

This rejection highlights a critical conflict between Azure Marketplace's strict validation policies and legitimate infrastructure-as-code security practices. Your approach of marking sensitive outputs as secureString is technically correct in Bicep and ARM to prevent credential exposure in logs.

However, the Marketplace's validation scripts appear to interpret any secure output as a prohibited secret, regardless of its actual necessity or context. To resolve this, you must explicitly demonstrate that these outputs are essential runtime identifiers like resource names or connection strings rather than concealed credentials.

You may engage directly with the Marketplace onboarding team to clarify the requirement, providing a justification for each secure output explaining its operational necessity. They may require you to refactor, potentially moving these values into a child resource or adjusting their sensitivity designation, even if less ideal, to comply with their automated checks while maintaining security through alternative means like managed identities. 

Please, let me know the response helps answer your question? If the above answer helped, please do not forget to "Accept Answer" as this may help other community members to refer the info if facing a similar issue. 🙂 

Hi Rick Huebner,

Thank you for sharing your question in the Microsoft Q&A

In Azure Marketplace, when submitting ARM templates for your offerings, it's crucial to adhere to specific guidelines to ensure acceptance. One such guideline is that outputs in ARM templates must not contain secrets. This is to prevent the accidental exposure of sensitive information.

Using Bicep’s @secure() feature or compiling with LangVersion=2 automatically marks outputs as securestring. Marketplace validation engines flag those outputs as disallowed secrets, rejecting the offer.

Recommended steps to resolve the issue

1.Avoid outputting sensitive values (secrets) directly via outputs in ARM templates or Bicep modules used in Marketplace offers, as Marketplace validation forbids that.

Locate all Bicep outputs marked with @secure(), remove the @secure() decorator, and change their type from securestring back to string.

2.Instead, store secrets in Azure Key Vault. This approach allows you to keep sensitive data secure while still making it accessible to other resources or templates.

Refer document: https://learn.microsoft.com/en-us/azure/key-vault/general/overview

For example:

"resources": [
  {
    "type": "Microsoft.KeyVault/vaults",
    "apiVersion": "2021-11-01-preview",
    "name": "[parameters('keyVaultName')]",
    "location": "[parameters('location')]",
    "properties": {
      "enabledForDeployment": "[parameters('enabledForDeployment')]",
      "enabledForDiskEncryption": "[parameters('enabledForDiskEncryption')]",
      "enabledForTemplateDeployment": "[parameters('enabledForTemplateDeployment')]"
    }
  }
]

This configuration creates a Key Vault and enables it for template deployments.

3.Test with ARM Template Toolkit before submitting your templates, use the ARM Template Test Toolkit to validate them. This toolkit can help identify potential issues, including the use of secure outputs, and provide guidance on how to address them

4.At deployment runtime, have your application or a post-deployment script fetch secrets from Key Vault under managed identity, rather than outputting them.

5.Use secure parameters (like secureString) for input secrets rather than outputs.

Refer document: https://learn.microsoft.com/en-us/azure/azure-resource-manager/bicep/linter-rule-outputs-should-not-contain-secrets

I hope the provided answer is helpful, do let me know if you have any further questions on this Please accept as Yes and upvote if the answer is helpful so that it can help others in the community.