Azure

Ensure all of the following are configured before linking your Azure account in Onehouse.

Networking

VNet

Create a VNet with a /16 address space (e.g. 10.0.0.0/16).

Subnets

Type	CIDR	Purpose
Node subnet	/20	AKS nodes run here. Must have Microsoft.Storage service endpoint enabled.

Pod and Service CIDRs

Azure AKS uses Azure CNI Overlay mode — pods get IPs from a dedicated CIDR separate from the node subnet, similar to GCP's secondary ranges.

Range	CIDR	Example
Pod CIDR	/16	10.244.0.0/16
Service CIDR	/16	10.1.0.0/16
DNS Service IP	Single IP within service CIDR	10.1.0.10

NAT Gateway

Deploy a NAT Gateway for outbound internet access from the node subnet. All outbound traffic to the Onehouse control plane routes through this gateway on port 443.

AKS Cluster Endpoint Access

The AKS cluster API endpoint is private. The Onehouse control plane connects to it from its NAT IP — you must ensure this is not blocked by your VNet or NSG rules:

• 54.153.81.1/32

VNet Peering

If your data sources (Kafka clusters, databases) live in a separate VNet or subscription, configure VNet peering between that VNet and your Onehouse VNet so the AKS cluster can reach them. See Azure docs.

Domain Allowlist

Required only if your environment has an egress firewall.

Azure differs from AWS

Because Azure is a Bring Your Own Kubernetes deployment, the cluster pulls some images and reaches some endpoints over domains that an AWS deployment never touches (e.g. production.cloudfront.docker.com, login.microsoftonline.com, *.core.windows.net). Allowlist the full Required set below — a partial list will fail image pulls (Helm/kubectl) or workload-identity token exchange.

Required — allowlist for every Azure deployment

Shared across all clouds (image registries, tooling, control plane):

• .onehouse.ai — control plane APIs, gateway, telemetry, image distribution
• .docker.io — Docker Hub registry
• production.cloudflare.docker.com — Docker Hub blob CDN (Cloudflare)
• production.cloudfront.docker.com — Docker Hub blob CDN (AWS CloudFront)
• docker-images-prod.6aa30f8b08e16409b46e0173d6de2f56.r2.cloudflarestorage.com
• docker-registry-production.d24a988e385e0074d717b6bdaea58f0d.r2.cloudflarestorage.com
• auth.docker.io.cdn.cloudflare.net
• .cloudfront.net — registry / image blob delivery
• .gcr.io — Google Container Registry image pulls
• .pkg.dev — Google Artifact Registry image pulls
• .googleapis.com — gcr.io / pkg.dev blob storage backend
• .k8s.io — Kubernetes registry (registry.k8s.io)
• ghcr.io — spark-operator and flink-operator images
• .quay.io — Strimzi, Prometheus, and Calico images
• registry.terraform.io — Terraform provider/module registry
• releases.hashicorp.com — Terraform binaries
• get.helm.sh — Helm binary downloads
• github.com — Terraform providers and modules
• .github.com
• .githubusercontent.com
• .github.io
• .strimzi.io — Strimzi Kafka operator
• .pagerduty.com — Onehouse operational alerting

Azure-specific:

• .azure.com — Azure Resource Manager (management.azure.com)
• .microsoft.com
• login.microsoftonline.com — Entra ID / workload-identity token exchange
• .azurecr.io — Onehouse Azure Container Registry image pulls
• .blob.core.windows.net — Azure Blob (Terraform state + Onehouse storage)
• .dfs.core.windows.net — ADLS Gen2 lakehouse storage
• .onehouse-frp.ai — control-plane FRP tunnel endpoint

Conditional — only if the corresponding feature or connector is enabled

• .confluent.cloud — Confluent / Kafka sources
• .jupyter.org — notebooks
• .debezium.io — Debezium CDC connectors
• .amazonaws.com — Debezium CDC image (Onehouse ECR) and S3 artifacts
• public.ecr.aws — Datadog agent images
• datadoghq.com — Datadog telemetry (site-specific, e.g. us5.datadoghq.com)
• docker.elastic.co — Elasticsearch images
• docker-auth.elastic.co
• .snowflakecomputing.com — Snowflake source/sink
• .databricks.com — Databricks source/sink
• .splunkcloud.com — Splunk log sink
• .slack.com — Slack notifications
• api.honeycomb.io — Honeycomb telemetry
• .openai.com — AI features
• apachesuperset.docker.scarf.sh — Superset dashboards image

Azure Subscription

You need an active Azure subscription with permissions to:

• Create and manage User-Assigned Managed Identities
• Create Role Assignments (RBAC) on storage accounts
• Create Resource Groups (or use an existing one)
• Register Federated Identity Credentials on managed identities

Resource Group

The resource group is required and must already exist in your subscription before you run the Terraform stack. Onehouse does not create it. Your AKS cluster and the storage account below must live in this resource group. You will pass its name as the resourceGroupName variable.

Storage

Nothing is pre-provisioned in your subscription

Onehouse does not create any storage in your subscription ahead of time. You create a single storage account yourself before running the customer stack. That one account serves both the Terraform state backend and the "Onehouse-managed" storage account — they are the same account, not two.

Create the storage account

The account and container names are derived from the first 8 characters of your request ID (the <prefix>), and must match exactly — the platform addresses them by convention. Create the account with hierarchical namespace enabled (ADLS Gen2), then create the filesystem/container:

az storage account create \
  --name storage1house<prefix> \
  --resource-group <your-resource-group> \
  --location <your-region> \
  --sku Standard_LRS --kind StorageV2 \
  --enable-hierarchical-namespace true

az storage fs create -n onehouse-customer-bucket-<prefix> \
  --account-name storage1house<prefix> --auth-mode login

Onehouse Storage Account ID

Pass the Azure resource ID of the account you just created as the onehouseStorageAccountId variable:

/subscriptions/<subscription-id>/resourceGroups/<your-resource-group>/providers/Microsoft.Storage/storageAccounts/storage1house<prefix>

Lakehouse Storage (optional)

If you want Onehouse to read data from additional Azure storage accounts of your own, pass their resource ID(s) as customerStorageAccountIds. The customer stack configures the appropriate RBAC role assignments for read access.

Workload Identity Federation

Onehouse's Azure deployment uses Workload Identity Federation — no client secrets or passwords are stored. The managed identities created by the customer stack are assumed by Onehouse's control plane using a federated credential that trusts Google's OIDC issuer (https://accounts.google.com), with audience api://AzureADTokenExchange.

This means:

• No credentials stored in Onehouse systems
• Token exchange happens via Google's token endpoint and Azure AD (Entra ID)
• Supports both production and staging Onehouse environments

Tooling

Tool	Version	Purpose
Terraform	≥ 1.11.0	Infrastructure deployment
Azure CLI	Any recent	Azure authentication

Ensure you are authenticated to the correct Azure subscription before running Terraform:

az login
az account set --subscription "<subscription-id>"