Forum Discussion
Data Connectors Storage Account and Function App
Several data connectors downloaded via Content Hub has ARM deployment templates which is default OOB experience. If we need to customize we could however I wanted to ask community how do you go about addressing some of the infrastructure issues where these connectors deploy storage accounts with insecure configurations like infrastructure key requirement, vnet intergration, cmk, front door etc...
Storage and Function Apps. It appears default configuration basically provisions all required services to get streams going but posture configuration seems to be dismissing security standards around hardening these services.
1 Reply
I’d treat the Content Hub template as a starting point, not the final security baseline. Export the ARM template, identify which resources and settings are parameterized, then deploy the Storage account and Function App through your own Bicep/ARM modules. Apply private endpoints, restricted public access, managed identity, CMK, TLS, and diagnostic settings there, and pass the resource names or IDs back to the connector template where it supports that.
The compatibility check matters. Azure Functions requires its runtime Storage account to remain reachable, and some connector packages still expect connection strings or Shared Key. Disabling public access or Shared Key before validating the connector can leave a successful deployment that fails at runtime. Test private DNS, VNet routing, required Blob/Queue/Table/File endpoints, RBAC, and scaling in a non-production workspace.
If the package hard-codes insecure settings, fork it and accept ownership of future updates. Add Azure Policy as a guardrail and regression-test every Content Hub upgrade before promotion.
