FinOps Toolkit v0.7 Deploys Private Networking Resources When Public Networking Option Selected

[AErmie]

🐛 Problem

When deploying the latest version of the FinOps Toolkit (v0.7) using the Deploy to Azure ARM template option (via the portal), even though Public networking was selected, Private Endpoints, a VNet, and Private DNS Zones were deployed.

Additionally, the deployment itself appears to deploy the hub multiple times.

Selected parameters:

{
    "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentParameters.json#",
    "contentVersion": "1.0.0.0",
    "parameters": {
        "hubName": {
            "value": "finops-hub-forge"
        },
        "location": {
            "value": "canadacentral"
        },
        "storageSku": {
            "value": "Premium_LRS"
        },
        "enableInfrastructureEncryption": {
            "value": false
        },
        "remoteHubStorageUri": {
            "value": ""
        },
        "remoteHubStorageKey": {
            "value": null
        },
        "dataExplorerName": {
            "value": ""
        },
        "dataExplorerSku": {
            "value": "Dev(No SLA)_Standard_D11_v2"
        },
        "dataExplorerCapacity": {
            "value": 1
        },
        "tags": {
            "value": {}
        },
        "tagsByResource": {
            "value": {}
        },
        "scopesToMonitor": {
            "value": []
        },
        "exportRetentionInDays": {
            "value": 0
        },
        "ingestionRetentionInMonths": {
            "value": 13
        },
        "dataExplorerRawRetentionInDays": {
            "value": 0
        },
        "dataExplorerFinalRetentionInMonths": {
            "value": 13
        },
        "enablePublicAccess": {
            "value": true
        },
        "virtualNetworkAddressPrefix": {
            "value": "10.20.30.0/26"
        }
    }
}

👣 Repro steps

TODO: Add repro steps below:

1. Go to Deploy a FinOps toolkit template
2. Click on Deploy to Azure (under FinOps Hub / Azure Commercial)
3. Select and existing Subscription, and an existing Resource Group
4. Do not enter any value for Azure Data Explorer cluster name
5. Select Locally-redundant (LRS) - Lowest cost storage redundancy option
6. Leave the Data Explorer SKU option at default
7. Leave the Data Retention settings at default
8. Do not select Enable Infrastructure Encryption
9. Leave Networking access set to Public and leave the default Address prefix configured
10. Create/initiate deployment

🤔 Expected

I expect the FinOps Toolkit to deploy the required resources (ie. Data Factory, Deployment Scripts, Event Grid, Managed Identity, Key Vault, Storage), but not deploy a Virtual Network, Network Security Group, Private Endpoints/Network Interfaces, and Private DNS Zones.

The creation of Private DNS Zone is particularly troubling, especially in an established (and regulated/governed environment), that already has DNS Zones in-place. There should be an option to use existing DNS Zones versus forcefully create new ones.

📷 Screenshots

ℹ️ Additional context

We previously had v0.6 deployed. We manually deleted those resources (as it was just in our testing environment), and deployed v0.7 in the same Resource Group (so that the Azure Policy exceptions for Key Vault would still be applied).

Deployment Details:

Deployment name: Microsoft.Template-20241204142952
Start time: 12/4/2024, 2:29:55 PM
Correlation ID: b82ee572-1445-4bee-8027-9ebb3e34a687

We tried deleting the Resource Group and creating a new deployment, but the results were the same.

🙋‍♀️ Ask for the community

We could use your help:

1. Please vote this issue up (👍) to prioritize it.
2. Leave comments to help us solidify the vision.

[AErmie]

Interesting discovery...
Even if I manually change the ARM template that's being deployed to target v0.6 of the Toolkit, it STILL deploys all of the private networking components!

So my assumption is the issue is with the underlying Bicep code/template that's being invoked.

[MSBrett]

This is the expected behaviour for 0.7.
Our intent is for private endpoints to be the only option going forward.

The cost of running ADF behind private endpoints is a sticking point at present, but once that's resolved everything will happen within the private vNet. You'll still be able to either peer the vNet with a hub or add FW exceptions for corp firewalls/VPN Concentrators to get to ADLS/ADX, but everything hubs does will be inside the vNet.

With respect to DNS, if the vNet is going to be peered to a hub and there are already DNS zones in place bound to a hub or resolver vNet, only the DFS endpoint for the data lake (not the script storage account) and the Kusto private endpoint DNS entries need to be replicated to those zones. The rest of the DNS entries are internal to hubs.

[AErmie]

Thanks for sharing that @MSBrett.

Unfortunately, the intent of using private endpoints only, was not mentioned anywhere in the release notes, so that will cause confusion. Especially since there is an option for public networking!

❓Can you please explain what this networking option actually does then when "public" is selected?

❓Could you also please elaborate on "the cost of running ADF behind private endpoints is a sticking point at present" and what's being done about that?

The client I'm assisting with implementing this, are using the Cloud Adoption Framework (CAF) model, so there is a central hub (via vWAN), and a centralized DNS (via Private DNS Resolvers). Using this Microsoft recommended approach, means that we cannot link Private DNS Zones with individual VNets, as all DNS traffic is forced through the Azure Firewall > Private DNS Resolver. It also includes Azure Policies to automatically create DNS A-Records for private endpoints that are created.

In a regulated/government-based environment, a more "Enterprise ready" approach, would be to support pre-existing VNets and DNS Zones, instead of forcefully creating these for the solution.

❓If the intent is for everything to be done within the VNet, what is the recommended approach to publishing the PowerBI reports to the PowerBI.com service? Would an instance of PowerBI Embedded, or Fabric (including a private endpoint within the environment) be required?

📚 Honestly, it feels like we need some additional documentation provided on the FinOps Toolkit, it's architecture, the components, how they interact, how data flows, etc. Is there plans to provide an Azure Architectures type of documentation, with diagrams, and lower-level details?

Thanks.

[flanakin]

Our intent is for private endpoints to be the only option going forward

@MSBrett I think you mean deploying within a dedicated VNet will be the only option, right? We're not forcing everyone to use private endpoints.

[flanakin]

❓If the intent is for everything to be done within the VNet, what is the recommended approach to publishing the PowerBI reports to the PowerBI.com service? Would an instance of PowerBI Embedded, or Fabric (including a private endpoint within the environment) be required?

Yes, private endpoints will need to be configured in PBI/Fabric, if private endpoints are used. But that's only if they are used. Private endpoints are not required today and, while Microsoft does recommend them for a more secure environment, I personally don't think we should force them on everyone. This should be their decision and we should support public or private access.

📚 Honestly, it feels like we need some additional documentation provided on the FinOps Toolkit, it's architecture, the components, how they interact, how data flows, etc. Is there plans to provide an Azure Architectures type of documentation, with diagrams, and lower-level details?

We do document our data flows @ https://learn.microsoft.com/cloud-computing/finops/toolkit/hubs/data-processing

We're also working on adding a doc to the Azure Architecture Center. That's been pending for a month, but now we need to update it for the latest architecture. (@MSBrett we should chat about that.)

[AErmie]

@flanakin
However, even when choosing the "public" networking option in the deployment, Private Endpoints are still/automatically deployed. It's like that option is completely ignored.

Our intent is for private endpoints to be the only option going forward

@MSBrett I think you mean deploying within a dedicated VNet will be the only option, right? We're not forcing everyone to use private endpoints.

[lundejd]

I too was not prepared for all the networking components to be deployed, and the deployment immediately failed because we have a policy against private dns zones.

Wanting to press on I temporarily disabled our policy and let it run only to find objects like "privatelink.blob.core.windows.net" which is way too generic. We have naming standards and would really prefer to have the ability to at least prepend the data explorer name we provide to things to keep them unique.

[variables('hubDataExplorerName')].blob.core.windows.net (?)

We also have multiple instances of the FinOps toolkit so we can roll changes and test - I have to think it will fail if I attempted to deploy to a second and it found these to already exist.

We also have a special Azure subscription for "island" networks so now I'm faced with having to re-create everything from scratch again but will have to get an exception approved for the dns and also be approved to use a private network.

I ended up deleting all the networking components manually to get back to just the storage as it was in .6 but will wait for any further deployments and hope there are some changes with .8 or I'm going to have to start modifying the template and hope it all works.

[profmamba]

I'll add to this in saying we already have our own private DNS zones configured. For 0.7 to forcefully deploy new zones does not seem right, and without any option to disable. I'll be rolling back to 0.6 for the time being.