Skip to main content

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

TypeCIDRPurpose
Node subnet/20AKS 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.

RangeCIDRExample
Pod CIDR/1610.244.0.0/16
Service CIDR/1610.1.0.0/16
DNS Service IPSingle IP within service CIDR10.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:

Domains to allowlist
  • .onehouse.ai
  • .azure.com
  • .microsoft.com
  • .azurecr.io
  • .docker.io
  • .gcr.io
  • .pkg.dev
  • .k8s.io
  • production.cloudflare.docker.com
  • d5l0dvt14r5h8.cloudfront.net
  • registry.terraform.io
  • releases.hashicorp.com
  • .confluent.cloud
  • .github.com
  • .githubusercontent.com
  • .github.io
  • .pagerduty.com
  • docker-images-prod.6aa30f8b08e16409b46e0173d6de2f56.r2.cloudflarestorage.com
  • get.helm.sh
  • auth.docker.io.cdn.cloudflare.net
  • docker-registry-production.d24a988e385e0074d717b6bdaea58f0d.r2.cloudflarestorage.com
  • .strimzi.io
  • .jupyter.org
  • 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

    You can either provide an existing resource group or allow Onehouse to create one. If providing your own, it must already exist in your subscription before running the Terraform stack.

    Storage

    Terraform State

    The Onehouse customer stack uses Azure Blob Storage for Terraform state. A storage account and container are provisioned by Onehouse — you will receive the storage account details along with your request ID. No manual bucket creation is required.

    Onehouse Storage Account

    A storage account managed by Onehouse will be pre-created in your subscription region. You will need its Azure resource ID before running the customer stack — this is provided by the Onehouse team.

    Lakehouse Storage (optional)

    If you want Onehouse to read data from your own Azure Blob Storage accounts, provide the resource ID(s) of those storage accounts. The customer stack will configure 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 can be assumed by Onehouse's existing AWS and GCP infrastructure using federated credentials.

    This means:

    • No credentials stored in Onehouse systems
    • Token exchange happens via Azure AD, AWS STS, and Google token endpoints
    • Supports both production and staging Onehouse environments

    Tooling

    ToolVersionPurpose
    Terraform≥ 1.11.0Infrastructure deployment
    Azure CLIAny recentAzure authentication

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

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