[BICEP] Add support for custom resource naming in FinOps Toolkit

[Copilot]

Overview

This PR adds support for custom resource naming in the FinOps Toolkit Bicep deployment, allowing organizations to follow their naming standards when deploying FinOps resources.

Changes Made

• Added new parameters to main.bicep:
  • storageAccountName: Custom name for the Storage Account
  • dataFactoryName: Custom name for the Data Factory
  • keyVaultName: Custom name for the Key Vault
• Updated the parameter chain to pass these values through hub.bicep and hub-app.bicep
• Modified the name generation logic in hub-types.bicep to use custom names when provided, falling back to the auto-generated names for backward compatibility

Example Usage

With these changes, consumers can specify their own resource names:

module finopsHub 'br/public:finops/hub:latest' = {
  name: 'finopsHub'
  params: {
    hubName: 'prod-finops'
    storageAccountName: 'companyfinopsdata001'
    dataFactoryName: 'company-finops-ingestion-001'
    keyVaultName: 'company-finops-vault-001'
  }
}

Or use a company naming module:

module finopsHub 'br/public:finops/hub:latest' = {
  name: 'finopsHub'
  params: {
    hubName: 'prod-finops'
    storageAccountName: naming.storageAccount('finops-data')
    dataFactoryName: naming.dataFactory('finops-engine')
    keyVaultName: naming.keyVault('finops-vault')
  }
}

Backward Compatibility

All parameters have empty string defaults, ensuring backward compatibility with existing deployments. When a parameter is not specified, the resource name is generated using the original logic based on the hub name.

Fixes #1105.

Warning

Firewall rules blocked me from connecting to one or more addresses

I tried to connect to the following addresses, but was blocked by firewall rules:

• aka.ms
  • Triggering command: bicep build src/templates/finops-hub/main.bicep (dns block)
  • Triggering command: bicep build src/templates/finops-hub/modules/hub-types.bicep (dns block)
  • Triggering command: bicep build src/templates/finops-hub/modules/hub-app.bicep (dns block)
• app.aladdin.microsoft.com
  • Triggering command: /usr/bin/../../opt/az/bin/python3 -Im azure.cli bicep build --file src/templates/finops-hub/main.bicep --force (dns block)
• cdn.fwupd.org
  • Triggering command: /usr/bin/fwupdmgr refresh (dns block)

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to my firewall allow list

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[MSBrett]

Closing stale Copilot draft PR after maintainer review. If any part of this is still needed, we'll bring it back as a fresh, focused PR against current dev.

[allcontributors]

@microsoft-github-policy-service[bot]

Could not find the user Copilot on github.

[MSBrett]

Thanks for picking up #1105. Flagging a correctness concern before this can move forward, based on production experience.

In hub-types.bicep, newAppInternalConfig currently does:

dataFactory: !empty(customDataFactoryName) ? customDataFactoryName : <default-with-uniqueString-suffix>
keyVault:    !empty(customKeyVaultName)    ? customKeyVaultName    : <default-with-uniqueString-suffix>
storage:     !empty(customStorageName)     ? customStorageName     : <default-with-uniqueString-suffix>

The moment a caller supplies a custom name, the uniqueString(...) suffix is dropped entirely rather than appended. Storage Account, Key Vault, and Data Factory names all need to be globally unique — without that token, two deployments (different subscriptions, different regions, or the same customer re-deploying) that pick the same custom name will collide.

We already have a live example of this exact failure mode: the existing dataExplorerName parameter for the Kusto cluster takes a fully custom name with zero uniqueness protection, and it's our #1 cause of deployment failures today. We don't want to extend that pattern to three more resources.

Ask: rework so custom names get a uniqueness token appended (not replaced), or add explicit collision handling/guidance. Also worth coordinating with #2148 and #1876, which propose overlapping/competing designs for the same problem — all tracked together on #1105.