> For the complete documentation index, see [llms.txt](https://documentation.immuta.com/saas/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://documentation.immuta.com/saas/configuration/application-configuration/how-to-guides/private-networking-support/governance-private-networking/immuta-saas-private-networking-over-azure-private-link.md).
# Immuta SaaS Private Networking Over Azure Private Link
Set up Azure private endpoint connections to Immuta applications from your organization's network.
Immuta SaaS hosts Azure Private Link entry points that organizations can use to connect Azure private endpoints. This ensures that all traffic to Immuta SaaS traverses private networks only.
Each entry point is an Immuta-managed Azure Application Gateway in an Azure region paired with one Immuta SaaS region. The gateway forwards traffic to your tenant over a dedicated private interconnect, so traffic between your network and your tenant never traverses the public internet.
This feature is supported in most regions across Immuta's global segments (NA, EU, and AP); contact your Immuta representative if you have questions about availability.
{% hint style="warning" %}
This documentation is for configuring access *to* an Immuta SaaS tenant from an organization's network, not for configuring access *from* a tenant to an organization's data sources or APIs. For that, please see the documentation on [Data connection private networking](/saas/configuration/application-configuration/how-to-guides/private-networking-support.md#data-connection-private-networking).
{% endhint %}
## Configuring Azure Private Link connections to the Govern app
### Requirements
Ensure that you meet the following requirements:
* You have an Immuta SaaS tenant in one of the Immuta SaaS regions listed in the [global segment tables below](#na-global-segment).
* You have an Azure virtual network (VNet) with a subnet where the private endpoint will be created. The VNet can be in any Azure region and any Microsoft Entra tenant.
* Clients (users or services) can access the Azure VNet where the private endpoint will be created.
* You have permission to create private endpoints in that VNet and to manage DNS for the clients that will use it.
### Create private endpoint
You will need to create an Azure private endpoint to connect directly to your tenant over the Immuta SaaS network. Refer to the [Azure Private Link documentation](https://learn.microsoft.com/en-us/azure/private-link/create-private-endpoint-portal) for general instructions on creating a private endpoint.
Immuta's Azure Private Link entry points are Azure Application Gateways. Application Gateway does not expose a Private Link alias, so you must connect to the gateway by its **resource ID** and specify the **target sub-resource** from the tables below. When creating your private endpoint, choose the entry point paired with the Immuta SaaS region of your tenant. If you do not know what region your tenant is in, contact your Immuta representative.
{% hint style="info" %}
The Azure region of the entry point does not need to match the Azure region of your VNet. Azure supports private endpoint connections across regions. For the lowest latency, create the private endpoint in a VNet close to the entry point's Azure region.
{% endhint %}
#### NA global segment
| Immuta SaaS region | Azure region | Resource ID | Target sub-resource |
| -------------------------------------------------------------------- | --------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------------------------- |
|
| `/subscriptions/dd862bdf-e8c9-4ed3-8b48-1e2449086d2d/resourceGroups/inbound-privatelink/providers/Microsoft.Network/applicationGateways/immuta-inbound-pl-australiaeast` | `appGwPrivateFrontendIpIPv4` |
#### Create the private endpoint in the Azure portal
1. In the Azure portal, search for and select **Private endpoints**, and then select **+ Create**.
2. On the **Basics** tab, select the subscription and resource group, enter a name for the private endpoint, and select the **Region** of the VNet where you want to create it.
3. On the **Resource** tab, configure the following settings:
* **Connection method**: Select **Connect to an Azure resource by resource ID or alias**.
* **Resource ID or alias**: Enter the resource ID from the tables above.
* **Target sub-resource**: Enter `appGwPrivateFrontendIpIPv4`.
* **Request message**: Enter your tenant hostname (for example, `example.hosted.immutacloud.com`). This helps Immuta identify your connection request.
4. On the **Virtual Network** tab, select the VNet and subnet for the private endpoint.
5. On the **DNS** tab, do not configure private DNS zone integration. You will configure DNS in the [next section](#configure-privatelink.immutacloud.com-dns).
6. Select **Review + create**, and then select **Create**.
After the private endpoint is created, its connection status is **Pending**. It stays pending until Immuta accepts the request. See [Have your connection request accepted](#have-your-connection-request-accepted) for details.
You will need the private endpoint's IP address to configure DNS. To find it, open the private endpoint, select its network interface, and copy the **Private IP address**.
{% hint style="info" %}
To create the private endpoint with the Azure CLI instead, see [`az network private-endpoint create`](https://learn.microsoft.com/en-us/cli/azure/network/private-endpoint#az-network-private-endpoint-create). Use the resource ID from the tables above for `--private-connection-resource-id`, set `--group-id` to `appGwPrivateFrontendIpIPv4`, and set `--manual-request true`, because the Application Gateway is in a Microsoft Entra tenant that you do not manage.
{% endhint %}
#### Configuring network security group access
Azure applies network security group (NSG) rules to private endpoints only when network policies for private endpoints are enabled on the subnet. If you enable these network policies, or if traffic to the private endpoint passes through a firewall or network virtual appliance, ensure that traffic from your clients to port `443` on the private endpoint's IP address is allowed.
### Configure `privatelink.immutacloud.com` DNS
To direct traffic to your private endpoint for your tenant hostname, you will need to set up DNS resolution in your network for the `privatelink.immutacloud.com` domain. For instructions, refer to your internal DNS provider's documentation.
Unlike private endpoints for Azure services, a private endpoint for an Application Gateway does not create a DNS record or a private DNS zone. You must create the records yourself. In Azure, you can do this with an [Azure Private DNS zone](https://learn.microsoft.com/en-us/azure/dns/private-dns-privatednszone) named `privatelink.immutacloud.com` that is linked to each VNet where clients resolve DNS.
Once you have resolution for the domain configured, you will need to create an **A record** that resolves `.privatelink.immutacloud.com` to your private endpoint's private IP address. For example, if your tenant's hostname is `example.hosted.immutacloud.com` and your private endpoint's IP address is `10.0.1.17`, you should create an A record that resolves `example.privatelink.immutacloud.com` to `10.0.1.17`. The end result should be that, inside your network, DNS resolution for your tenant hostname will direct traffic to your private endpoint.
### Have your connection request accepted
Once you have configured DNS, you will need to contact your Immuta representative with the following information to have your private endpoint connection request accepted and Azure Private Link enabled for your tenant:
* Tenant name
* Immuta SaaS region and Azure region of the entry point you connected to
* Private endpoint resource ID (for example, `/subscriptions//resourceGroups//providers/Microsoft.Network/privateEndpoints/immuta-privatelink`)
After the request is completed, the private endpoint's connection status changes to **Approved**. **Continue to use your standard hostname** (e.g., `example.hosted.immutacloud.com`) to access your tenant. An Immuta-managed CNAME record will direct that traffic to your Azure Private Link hostname (e.g., `example.privatelink.immutacloud.com`).
{% hint style="warning" %}
When Immuta completes this request, your tenant will no longer be publicly accessible. Traffic bound for your tenant hostname (e.g., `example.hosted.immutacloud.com`) will be directed to your Azure Private Link hostname (e.g., `example.privatelink.immutacloud.com`).
{% endhint %}
### Verify connectivity
From a client in your network, confirm that your tenant hostname resolves to your private endpoint's IP address through the `privatelink.immutacloud.com` record:
```bash
nslookup example.hosted.immutacloud.com
```
The output should show `example.privatelink.immutacloud.com` and your private endpoint's IP address. Then confirm that the tenant responds:
```bash
curl -sS -o /dev/null -w '%{http_code}\n' https://example.hosted.immutacloud.com/
```
If the request does not succeed, check the following:
* **The hostname resolves to a public IP address**: This could happen if `privatelink.immutacloud.com` zone is not linked to the client's VNet, the A record is missing, or the client's DNS server does not resolve the `privatelink.immutacloud.com` domain.
* **The connection times out**: This could happen if the private endpoint connection is still **Pending**, or an NSG, firewall, or route blocks port `443` to the private endpoint.
### Configuring SCIM integrations that require public endpoints
Identity providers that support SCIM often require that the endpoints they interact with are publicly accessible. To accommodate this traffic, Immuta can configure a separate, SCIM-only public traffic ingress for your tenant.
If needed, request a **public SCIM ingress** when you contact your Immuta representative to have Immuta SaaS private networking enabled.
### Configuring private networking for multiple tenants
Each Azure Private Link entry point serves only the tenants in its paired Immuta SaaS region.
* If you have multiple Immuta SaaS tenants, you need **one private endpoint for each Immuta SaaS region where you have tenants**. For example, if you have tenants in `us-east-1` and `us-west-2`, create one private endpoint connected to the `eastus2` entry point and another connected to the `westus2` entry point.
* Tenants in the same Immuta SaaS region can share one private endpoint.
* You can create more than one private endpoint for the same region, either for redundancy or to support traffic to your tenants from distinct, isolated networks. **If you create multiple private endpoints, provide all the private endpoint resource IDs** to your Immuta representative.
You will still need to create a [`privatelink.immutacloud.com` A record for each tenant](#configure-privatelink.immutacloud.com-dns). Ensure that each A record resolves to the IP address of a private endpoint connected to the entry point for that tenant's Immuta SaaS region.
## Configuring Azure Private Link connections to the Request app
### Requirements
* You have an Immuta SaaS tenant in one of the Immuta SaaS regions listed in the [global segment tables below](#na-global-segment).
* You have an Azure virtual network (VNet) with a subnet where the private endpoint will be created. The VNet can be in any Azure region and any Microsoft Entra tenant.
* Clients (users or services) can access the Azure VNet where the private endpoint will be created.
* You have permission to create private endpoints in that VNet and to manage DNS for the clients that will use it.
* You have successfully configured [Immuta Azure Private Link for the Govern app](#configuring-azure-private-link-connections-to-the-govern-app).
### Configure Request app DNS
Immuta SaaS Private Networking for the Request app will use the same private endpoint as the one created for the Govern app, so the only required additional configuration is DNS-related.
In order to direct traffic to your private endpoint for the Request app, you will need to set up DNS resolution in your network for the following domains:
* `app.immutacloud.com`
* `marketplace-fe.immutacloud.com`
For instructions on how to do this, refer to your internal DNS provider's documentation. In Azure, you can create an [Azure Private DNS zone](https://learn.microsoft.com/en-us/azure/dns/private-dns-privatednszone) named after each domain and link both zones to each VNet where clients resolve DNS.
{% hint style="warning" %}
Create zones for these exact domain names, not for `immutacloud.com`. A zone for `immutacloud.com` would take over DNS resolution for every Immuta hostname in your network.
{% endhint %}
Once you have resolution for the domains configured, you will need to create an **A record** for each domain that resolves to your private endpoint's private IP address (the same private endpoint used for the Govern app). In an Azure Private DNS zone named after the domain, this is an A record at the zone apex (`@`).
For example, if your private endpoint's IP address is `10.0.1.17`, you should create A records that resolve `app.immutacloud.com` and `marketplace-fe.immutacloud.com` to `10.0.1.17`.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://documentation.immuta.com/saas/configuration/application-configuration/how-to-guides/private-networking-support/governance-private-networking/immuta-saas-private-networking-over-azure-private-link.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
