Documentation Index
Fetch the complete documentation index at: https://docs.cube.dev/llms.txt
Use this file to discover all available pages before exploring further.
This page covers backend connectivity — Cube reaching into your network to
query data sources, auth providers, BI APIs targeted by Semantic Layer Sync,
and other upstream services. See
Backend and frontend connectivity for the full picture.
For frontend connectivity (exposing Cube’s APIs to your applications,
browsers, BI tools, and embedded analytics clients), see
Private API Connectivity on AWS; the
equivalent pattern is available on Azure on request.
Preparing the Private Link Service
There are two common scenarios for preparing the Private Link Service:- Connecting to a service in your Azure infrastructure
- Connecting to a service provided by a third party such as Snowflake, Databricks, Confluent Cloud, etc.
Configuring service visibility
Azure Private Link Service enables you to control the visibility of your private endpoint. You’ll need to configure access permissions to allow Cube to connect to your service. To allow Cube access, please go to Azure Portal → Private Link Services → Your service → Manage visibility and add the following subscription ID to the allowed list:cd69336e-c628-4a88-a56e-86900a0df732.
This is the Azure subscription ID of Cube’s Private Link consumer
subscription. Adding it authorizes Cube to discover your Private Link
Service and create a private endpoint against it; nothing else in Cube’s
Azure estate gains access to your network.
Gathering required information
To request establishing a Private Link connection, please share the following information with the Cube team:- Private Link Service Resource ID (such as
/subscriptions/abc123/resourceGroups/myResourceGroup/providers/Microsoft.Network/privateLinkServices/myservice) - Reference Name for the record (such as “Snowflake-prod” or “databricks-dev”)
- Ports: a list of ports that will be accessed through this connection
- DNS Name(s): see DNS and TLS below
- Cube Region: Private Link requires Cube to be hosted on Dedicated Infrastructure. Specify which Cube Region should host your Dedicated Infrastructure.
DNS and TLS
How your data source is addressed inside Cube depends on whether it speaks TLS:- If the service uses TLS (HTTPS, JDBC
Encrypt=true, etc.), share the DNS name(s) the certificate is issued for — typically the same hostname your in-network clients already use to reach it. Cube creates internal DNS overrides inside the Dedicated Infrastructure so that the same hostname resolves to the Private Endpoint. Keeping the original hostname is what preserves TLS validity: the certificate’s CN/SAN keeps matching what Cube dials. - If the service does not use TLS and you don’t supply a DNS name, the Cube team will share back an internal endpoint hostname (e.g. an Azure-assigned private-endpoint DNS name) that you can configure as the upstream when you wire the connection into Cube.
Approving the connection
The connection approval process depends on your visibility configuration:Manual approval
If you haven’t configured auto-approval, the Cube team will notify you once the Private Endpoint connection request is sent. You can approve it by:- Going to Azure Portal → Private Link Center → Private Link Services → Your Service → Private endpoint connections.
- Finding the pending connection from Cube.
- Clicking Approve and optionally providing an approval message.