Immuta SaaS supports two different kinds of private networking:
Data connection private networking: Enables private connectivity from the Immuta SaaS network and a user's data platforms or private APIs over either AWS PrivateLink or Azure Private Link. This is useful for organizations with security and compliance policies that require that their data platforms and APIs are not routable over the public internet (even with a firewall in place).
Immuta SaaS private networking: Enables private connectivity from a user's network to an Immuta SaaS tenant. It will require Immuta SaaS users to connect over a private endpoint. This is useful for organizations with security and compliance policies that require that the SaaS applications they use are not publicly accessible.
A simple way to understand the difference between these two features: Data connection private networking is outbound from Immuta to an organization's data sources, where the organization creates the private service endpoint for Immuta SaaS to connect to. Immuta SaaS private networking is inbound to Immuta from an organization's network, where Immuta creates the private service endpoint for users to connect to.
Having one type of private networking enabled does not mean that the other is configured automatically. The two features perform different operations and use different networking interfaces that are configured independently.
Data connection private networking
Although AWS PrivateLink and Azure Private Link differ in their implementation details, they are fundamentally similar offerings. Organizations can expose private services on AWS or Azure networks that Immuta SaaS can establish a connection to. How this is done can vary significantly by both data platform and hosting cloud provider, which is why this documentation has been broken down into specific instructions for each combination in the support matrix below.
AWS
Azure
Over time, the breadth and depth of private networking support will continue to grow. If there are specific data platforms and/or cloud providers that you require, which are either not listed or not yet supported, please contact your Immuta representative.
Private networking across regions and global segments
Immuta SaaS's global network is divided into large geographic regions called . All Immuta SaaS tenants are deployed into an AWS region inside their chosen segment.
Occasionally, it may be required to connect to data sources outside of a specific region. To meet those needs, Immuta SaaS supports both cross-region and cross-global-segment connectivity.
Cross-region private networking
This involves connecting to data sources in a different region within a given global segment.
Examples
a tenant in us-east-1 needs to connect to a Snowflake account in AWS'sus-east-2 region.
a tenant in us-west-2 needs to connect to an Azure Databricks workspace in the westus2 region.
Cross-global-segment private networking
This involves connecting to data sources in a region outside of the tenant's global segment.
Examples
a tenant in the EU Global Segment needs to connect to a Snowflake account in us-east-2.
a tenant in the AP Global Segment needs to connect to a Starburst instance hosted in Azure's eastus2 region.
Immuta SaaS private networking
Public preview: This feature is available to select accounts. Contact your Immuta representative for details.
The fundamental mechanism that underlies Immuta SaaS private networking is an Immuta SaaS private endpoint service (e.g. an ) which organizations can establish a connection to via a private endpoint (e.g. an ).
Once the endpoint-service connection is established, organizations then configure DNS resolution in their network to resolve their governance private FQDN (e.g.<tenant>.privatelink.immutacloud.com) to their private endpoint. Organizations can continue to access their Immuta SaaS tenants using their standard governance FQDN (e.g. <tenant>.hosted.immutacloud.com), which will now automatically resolve to their private FQDN.
As with data connection private networking the specifics of configuring Immuta SaaS private networking can vary by the cloud provider the source network is hosted on. Please consult the support matrix below for specific instructions.
The Immuta SaaS platform uses Private Service Connect for all BigQuery connections through the Immuta Private Cloud Exchange. This means that all connectivity to Google APIs, including BigQuery, are over a private network connection. This functionality is enabled by default and no customer configuration is required for the private connectivity (unless you have VPC Service Controls enabled). This feature is supported in all regions across Immuta's global segments (NA, EU, and AP).
VPC Service Controls
If you have VPC Service Controls (VPC-SCs) enabled for BigQuery, contact your Immuta representative for the VPC information required to configure resource access restrictions. If you have VPC-SCs configured
Starburst (Trino) Private Connectivity
This section contains information about private connectivity options for Starburst (Trino) integrations.
Overview
The Immuta SaaS platform supports private connectivity to Starburst (Trino) clusters hosted in both AWS and Azure. This allows organizations to meet security and compliance controls by ensuring that traffic to data sources from Immuta SaaS only traverses private networks, never the public internet.
AWS PrivateLink for S3
The Immuta SaaS platform uses AWS PrivateLink for S3 to provide private connectivity for all S3 services in AWS. Immuta is utilizing S3 Gateway VPC endpoints for private connectivity from all SaaS networks, so connections to S3 connect over PrivateLink by default without any extra configuration. This feature is supported in all regions across Immuta's global segments (NA, EU, and AP).
If you have bucket policies limiting access to specific VPCs or have any questions about availability, contact your Immuta representative for more information about configuration (e.g., VPC ID) to be able to configure your bucket policy.
Support for AWS PrivateLink is available in most regions across Immuta's global segments (NA, EU, and AP); contact your Immuta representative if you have questions about availability.
Immuta's VPC information, Immuta SaaS will be unable to connect to your Google BigQuery instances.
AWS PrivateLink for Redshift
AWS PrivateLink provides private connectivity from the Immuta SaaS platform to Redshift clusters hosted on AWS. It ensures that all traffic to the configured endpoints only traverses private networks.
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.
Requirements
You have an Immuta SaaS tenant.
You have set up an for your Redshift Cluster endpoints.
When creating the service, make sure that the Require Acceptance option is checked (this does not allow anyone to connect, all connections will be blocked until the Immuta service principal is added).
Configure Redshift with AWS PrivateLink
Open a support ticket with with the following information:
AWS region
AWS subnet availability zones IDs (e.g. use1-az3; these are not the account-specific identifiers like us-east-1a
Immuta SaaS Private Networking
This section contains information about private connectivity options for Immuta SaaS applications.
Overview
Immuta SaaS applications support private connectivity from customer networks. This allows organizations to meet security and compliance controls by ensuring that no users can access these endpoints outside of their internal networks.
Support for AWS PrivateLink is available in most regions across Immuta's global segments (NA, EU, and AP); contact your Immuta representative if you have questions about availability.
Configuration guide
Snowflake Private Connectivity
This section contains information about private connectivity options for Snowflake integrations.
Overview
The Immuta SaaS platform supports private connectivity to Snowflake accounts hosted in both AWS and Azure. This allows organizations to meet security and compliance controls by ensuring that traffic to data sources from Immuta SaaS only traverses private networks, never the public internet.
Support for AWS PrivateLink is available in most regions across Immuta's global segments (NA, EU, and AP); contact your Immuta representative if you have questions about availability.
Support for Azure Private Link is available in .
Configuration guides
AWS PrivateLink for Starburst (Trino)
AWS PrivateLink provides private connectivity from the Immuta SaaS platform to Starburst (Trino) Clusters hosted on AWS. It ensures that all traffic to the configured endpoints only traverses private networks.
This feature is supported in most regions across Immuta's global segments (NA, EU, and AP); contact your Immuta account manager if you have questions about availability.
Requirements
Databricks Private Connectivity
This section contains information about private connectivity options for Databricks integrations.
Overview
The Immuta SaaS platform supports private connectivity to and the . This allows organizations to meet security and compliance controls by ensuring that traffic to data sources from Immuta SaaS only traverses private networks, never the public internet.
Azure Private Link for Snowflake
provides private connectivity from the Immuta SaaS platform, hosted on AWS, to Snowflake Accounts on Azure. It ensures that all traffic to the configured endpoints only traverses private networks over the Immuta Private Cloud Exchange.
Support for AWS PrivateLink is available in most regions across Immuta's global segments (NA, EU, and AP); contact your Immuta representative if you have questions about availability.
When creating the service, make sure that the Require Acceptance option is checked (this does not allow anyone to connect; all connections will be blocked until the Immuta Service Principal is added).
Only TCP connections over IPv4 are supported.
Your Starburst (Trino) cluster endpoints are secured with TLS certificates for encryption in-transit.
The presented certificate must have the Fully-Qualified Domain Name (FQDN) of your cluster hostname as a Subject Alternative Name (SAN). This can either be a wildcard (e.g. *.example.com) or specific to the host (e.g. starburst.example.com)
The presented certificate must be issued from a publicly-trusted certificate authority (CA). Private CAs and/or internal top-level domains (TLDs) are not supported.
Why are private top-level domains (TLDs) not supported?
Private TLDs are not allowed for two reasons:
A private TLD cannot have a publicly-trusted certificate authority (CA), which means that Immuta SaaS systems could not verify the certificate and would refuse to send traffic to the PrivateLink endpoint.
Immuta SaaS cannot accept private CAs for private TLDs because there are no means of verifying domain ownership and preventing overlap between an organization's private DNS. For example, if Company A uses a .localTLD, Immuta cannot verify that they own it because it's impossible to have exclusive ownership over a private TLD. If Company B also uses a .local TLD, it becomes impossible to determine what the canonical trust chain for either company's private CA is.
Immuta also cannot prevent DNS overlap between different tenants. If both companies use starburst-prod.local only one endpoint can be routable from that DNS hostname.
Configure Starburst (Trino) with AWS PrivateLink
Open a support ticket with Immuta Support with the following information:
AWS region
AWS subnet availability zones IDs (e.g. use1-az3; these are not the account-specific identifiers like us-east-1a or eu-west-2c)
VPC endpoint service ID (e.g., com.amazonaws.vpce.us-east-1.vpce-svc-0471015b106ad1d47)
DNS hostname
This is the hostname of the cluster that will be used to ingest data sources. It must match the Common Name (CN) or a Subject Alternative Name (SAN) on your cluster's TLS certificate.
Ports used
provided by your representative so that Immuta can complete the VPC endpoint configuration.
You have ACCOUNTADMIN role on your Snowflake account to configure the Private Link connection.
Configure Snowflake with Azure Private Link
Snowflake requires that an Azure temporary access token be used when configuring the Azure Private Link connection. Due to the constraint imposed by the 1-hour token expiration, your Immuta representative will ask for a time window in which you can accept the connection in your Snowflake account. During this window, the token will be generated by Immuta and provided to you when you're ready to run the following SQL query.
In your Snowflake environment, run the following SQL query, which will return a JSON object with the connection information you will need to include in your support ticket:
Copy the returned JSON object into a support ticket with Immuta Support to request for the feature to be enabled on your Immuta SaaS tenant.
Your Immuta representative will work with you to schedule a time in which to accept the connection in your Snowflake account. They will provide you with a SQL query to run using the ACCOUNTADMIN role. The SQL query will be in this format:
The query should return the following response: Private link access authorized.
using the privatelink-account-url from the JSON object in step one as the Host.
AWS PrivateLink provides private connectivity from the Immuta SaaS platform to PostgreSQL database engines hosted on Amazon Aurora and Amazon RDS. It ensures that all traffic to the configured endpoints only traverses private networks.
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.
Requirements
You have an Immuta SaaS tenant.
You have set up an for your Amazon Aurora/Amazon RDS endpoints.
When creating the service, make sure that the Require Acceptance option is checked (this does not allow anyone to connect, all connections will be blocked until the Immuta service principal is added).
Like all data connection private networking integrations that Immuta offers for AWS, the Amazon Aurora/Amazon RDS PrivateLink integration relies on a Network Load Balancer (NLB) that targets a private IP address - in this case, the private IP address of the Aurora/RDS instance. In a Multi-AZ configuration, the primary instance's private IP address changes during a failover event.
The NLB will not automatically detect this new IP address. Consequently, after an RDS failover, Immuta will be unable to connect to the database until the NLB's target group is updated with the new primary instance's private IP address.
To avoid the need for manual updates to your NLB configuration, you must implement an automated solution. A common approach is to use an AWS Lambda function that listens for RDS failover events and automatically updates the NLB target group with the new IP address. For a detailed guide on this automation, refer to the AWS blog post:
Configure PostgreSQL with AWS PrivateLink
Open a support ticket with with the following information:
AWS region
AWS subnet availability zones IDs (e.g. use1-az3; these are not the account-specific identifiers like us-east-1a
Azure Private Link for Databricks
Azure Private Link provides private connectivity from the Immuta SaaS platform, hosted on AWS, to Azure Databricks accounts. It ensures that all traffic to the configured endpoints only traverses private networks over the Immuta Private Cloud Exchange.
This front-end Private Link connection allows users to connect to the Databricks web application, REST API, and Databricks Connect API over an Azure Private Endpoint. For details about Azure Private Link for Databricks and the network flow in a typical implementation, explore the Databricks documentation.
Ensure that your accounts meet the following requirements:
You have an Immuta SaaS tenant.
Your Azure Databricks workspace must be on the .
has been configured and enabled.
Configure Databricks with Azure Private Link
Contact your Immuta representative, and provide the following information for each Azure Databricks Workspace you wish to connect to:
Azure region
Azure Databricks hostname
AWS PrivateLink for API Gateway
Private preview: This feature is available to select accounts. Contact your Immuta representative for details.
AWS PrivateLink provides private connectivity from the Immuta SaaS platform to API gateway endpoints hosted on AWS. It ensures that all traffic to the configured endpoints only traverses private networks.
This feature is supported in all regions across Immuta's global segments (NA, EU, and AP); contact your Immuta representative if you have questions about availability.
Azure Private Link for Starburst (Trino)
Azure Private Link provides private connectivity from the Immuta SaaS platform, hosted on AWS, to Starburst (Trino) clusters on Azure. It ensures that all traffic to the configured endpoints only traverses private networks over the Immuta Private Cloud Exchange.
You have your Databricks account ID from the account console.
Azure Databricks resource ID or alias
Your representative will inform you when the two Azure Private Link connections have been made available. Accept them in your Azure Databricks workspace configuration.
Configure Databricks depending on your integration type:
Update your API gateway resource policy to allow for access from the Immuta VPC endpoint in the applicable AWS region. The Immuta VPC endpoint IDs are listed in the table below.
AWS region
VPC endpoint ID
ap-northeast-1
Asia Pacific (Tokyo)
vpce-09b3a20743b64ecc9
ap-south-1
Asia Pacific (Mumbai)
vpce-00620d5f59239fa03
ap-southeast-1
Asia Pacific (Singapore)
vpce-0b470f0df2b0e03f3
ap-southeast-2
Asia Pacific (Sydney)
vpce-0afc6a24f0959847c
ca-central-1
Canada (Central)
vpce-07dfc91c761a8f2f9
eu-central-1
Europe (Frankfurt)
vpce-04bc9a3cd6020a865
Here is an example resource policy:
Once you have made changes to your resource policy, you mustdeploy your APIfor the updates to take effect.
You should now be able to connect to your private API from your Immuta SaaS tenant using your API endpoint, i.e. <api-gateway-id>.execute-api.<region>.amazonaws.com/<stage>/<endpoint>.
Troubleshooting
Issue: I received a permissions error when trying to invoke my private API from Immuta
If you get an error similar to the following:
Check to make sure that the following is true:
You have authorized the correct VPC endpoint for the region you are targeting in your resource policy.
Your resource policy allows for execute-api:Invoke privileges on the endpoint you are making requests to from Immuta.
You have deployed your API after making changes to your resource policy.
You have an Immuta SaaS tenant.
Your Starburst (Trino) cluster is hosted on Azure.
AWS PrivateLink provides private connectivity from the Immuta SaaS platform to Databricks accounts hosted on AWS. It ensures that all traffic to the configured endpoints only traverses private networks.
This front-end PrivateLink connection allows users to connect to the Databricks web application, REST API, and Databricks Connect API over a VPC interface endpoint. For details about AWS PrivateLink in Databricks and the network flow in a typical implementation, explore the Databricks documentation.
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.
Requirements
Databricks
Ensure that your accounts meet the following requirements:
Your Databricks account is on the E2 version of the platform.
Your Databricks account is on the .
You have your Databricks account ID from the .
Databricks workspace
Ensure that your workspace meets the following requirements:
Your workspace must be in an .
Your Databricks workspace must use a to add any PrivateLink connection.
Your workspaces must be .
You cannot configure a connection to your workspace over the public internet if PrivateLink is enabled.
If you have PrivateLink configured on your workspace, Databricks will update the DNS records for that workspace URL to resolve to <region>.privatelink.cloud.databricks.com. Immuta SaaS uses these publicly-resolvable records to direct traffic to a PrivateLink endpoint on our network.
This means that if you have PrivateLink enabled on your workspace, you must follow these instructions to configure your integration.
Enablement
Contact your Databricks representative to enable AWS PrivateLink on your account.
Configure Databricks with AWS PrivateLink
for the applicable AWS region with your Databricks workspaces. The Immuta VPC endpoint IDs are listed in the table below.
AWS region
VPC endpoint ID
Identify your (either ACCOUNT or ENDPOINT) and configure your Databricks workspace accordingly.
If the private_access_level on your private_access_settings object is set to ACCOUNT, no additional configuration is required.
Configure Databricks depending on your integration type:
using your standard cloud.databricks.com workspace URL as the Host.
Configure the using your standard cloud.databricks.com
AWS PrivateLink for Snowflake
provides private connectivity from the Immuta SaaS platform to Snowflake accounts hosted on AWS. It ensures that all traffic to the configured endpoints only traverses private networks.
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.
{"Message":"User: anonymous is not authorized to perform: execute-api:Invoke on resource: arn:aws:execute-api:us-east-1:****************/foo/GET/bar with an explicit deny"}
Even if your workspace is also publicly-routable, Databricks's DNS resolution forces the traffic over PrivateLink.
The two supported configurations are
A workspace with no PrivateLink configuration, which resolves to public IP addresses.
A workspace with PrivateLink configuration, which allows access from the Immuta SaaS regional endpoint (listed below).
eu-central-1
Europe (Frankfurt)
vpce-0048e36edfb27d0aa
eu-west-1
Europe (Ireland)
vpce-0783d9412b046df1f
eu-west-2
Europe (London)
vpce-0f546cc413bf70baa
us-east-1
US East (Virginia)
vpce-0c6e8f337e0753aa9
us-east-2
US East (Ohio)
vpce-00ba42c4e2be20721
us-west-2
US West (Oregon)
vpce-029306c6a510f7b79
If the private_access_level on your private_access_settings object is set to ENDPOINT, using the table above, you will need to add it to the allowed_vpc_endpoint_ids list inside your private_access_settings object in Databricks. For example,
URL. And
using the cloud.databricks.com as the Server when registering data sources.
Using Snowflake network policies with AWS PrivateLink
Snowflake network policies allow you to limit access to your Snowflake service endpoints. Network rules can be used with those network policies to define the specific IP CIDR blocks or AWS VPC endpoints that are allowed. Immuta supports both, but we highly recommend that you configure your network rules to reference our VPC endpoints and not our CIDR block.
VPC endpoint network rule
With a network rule type of AWSVPCEID, you can use the following table of Immuta's VPC endpoints by AWS region to configure access from Immuta SaaS to your Snowflake service:
AWS region
VPC endpoint ID
ap-northeast-1
Asia Pacific (Tokyo)
vpce-0c738d241aa0bfde7
ap-northeast-2
Asia Pacific (Seoul)
vpce-00daddfa7477666eb
ap-south-1
Asia Pacific (Mumbai)
vpce-08a6d075ddd92df58
ap-southeast-1
Asia Pacific (Singapore)
vpce-030933ffc228d94ac
ap-southeast-2
Asia Pacific (Sydney)
vpce-0803dc2285d0d695f
ca-central-1
Canada (Central)
vpce-0ebff3192617126c9
IPv4 network rule
With a network rule type of IPV4, you must configure an IP address block of 10.0.0.0/8.
This size of block is required because traffic could come from anywhere in Immuta's network. Immuta has globally distributed compute and does not assign static IP addresses to any workloads. This is why you should use VPC endpoint network rules instead.
Configure Snowflake with AWS PrivateLink
In your Snowflake environment, run the following SQL query, which will return a JSON object with the connection information you will need to include in your support ticket:
Copy the returned JSON object into a support ticket with Immuta Support to request for the feature to be enabled on your Immuta SaaS tenant.
Immuta SaaS Private Networking Over AWS PrivateLink
Immuta SaaS hosts AWS PrivateLink services that organizations can configure Amazon VPC endpoint connections to, which ensures that all traffic to Immuta SaaS only traverses private networks.
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.
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.
Overview of Immuta SaaS Private Networking over AWS PrivateLink
Configuring AWS PrivateLink connections to the Governance app
Requirements
You have an Immuta SaaS tenant.
You have an Amazon VPC in one of the supported regions listed in the below.
Clients (users or services) can access the Amazon VPC network where the AWS PrivateLink endpoint will be created.
Create PrivateLink endpoint
You will need to create an AWS PrivateLink endpoint to connect directly to your tenant over the Immuta SaaS network. Please refer to the for instructions on creating an endpoint.
Please note that the documentation uses connecting to an AWS service as an example, but you will want to configure your endpoint to connect to one of the PrivateLink service endpoints in the tables below.
Immuta has a set of that you can connect to in different global segments. When creating your endpoint, please choose the service in the same region as your tenant. If you do not know what region your tenant is in, please contact your Immuta representative.
NA global segment
Region
Endpoint service name
Availability zones
EU global segment
Region
Endpoint service name
Availability zones
AP global segment
Region
Endpoint service name
Availability zones
Configuring security group access
VPC endpoints must be associated with at least one security group upon creation. Please ensure that traffic from your clients to port 443 is allowed.
Configure privatelink.immutacloud.com DNS
In order to direct traffic to your PrivateLink endpoint for your tenant hostname, you will need to set up DNS resolution in your network for the privatelink.immutacloud.com domain. For instructions on how to do this, please refer to your internal DNS provider's documentation.
Once you have resolution for the domain configured, you will need to create a CNAME DNS record that resolves <tenant name>.privatelink.immutacloud.com to your newly-created VPC endpoint's DNS name.
For example, if your tenant's hostname is example.hosted.immutacloud.com and your VPC endpoint DNS name is vpce-0d363d9ea82658bec-e4wo04x9.vpce-svc-0d12345ddd89101112.us-east-1.vpce.amazonaws.com, you should create a CNAME record that resolves example.privatelink.immutacloud.com to your VPC endpoint DNS name.
The end result should be that, inside your network, DNS resolution for your tenant hostname will direct traffic to your VPC Endpoint.
Have your connection request accepted
Once you have configured DNS, you will need to contact your Immuta representative with the following information in order to have your VPC endpoint connection request accepted and PrivateLink enabled for your tenant:
Tenant name
AWS region
VPC endpoint ID
After the request is completed, please 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 PrivateLink hostname (e.g. example.privatelink.immutacloud.com).
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 PrivateLink hostname (e.g. example.privatelink.immutacloud.com).
Any services or data platforms that make requests to the Governance app API will need to route their traffic over your VPC endpoint as well. The integrations that require this connectivity are:
Configuring SCIM integrations that require public endpoints
Identity providers that support SCIM often require that the endpoints that they interact with are publicly accessible. In order 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
If you have multiple Immuta SaaS tenants that you need to enable Immuta SaaS private networking for, you only need to configure one endpoint per global segment. For example, if all your tenants are in the EU global segment, you only need to create a VPC endpoint in one of the EU regions from the table above.
While having at least one is required, it is possible to configure multiple endpoints, either for redundancy or to support traffic to your tenants from distinct, isolated networks. If you do create multiple VPC endpoints, please provide all the VPC endpoint IDs from your connection requests to your Immuta representative.
You will still need to create a privatelink.immutacloud.com CNAME record for each tenant. Please ensure that, if you've created separate VPC endpoints per tenant, the CNAME record references the correct VPC endpoint DNS name.
Configuring AWS PrivateLink connections to the Request app
Requirements
You have an Immuta SaaS tenant.
You have an Amazon VPC in one of the supported regions listed in the above.
Clients (users or services) can access the Amazon VPC network where the AWS PrivateLink endpoint will be created.
PrivateLink for the Request app is only supported if all your tenants reside in a single global segment. Having tenants in multiple global segments is very uncommon, so you are unlikely to be affected by this limitation.
Configure Request app DNS
Immuta SaaS Private Networking for the Request app will use the same VPC endpoint as the one created for the Governance app, so the only required additional configuration is DNS-related.
In order to direct traffic to your PrivateLink 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.
Once you have resolution for the domain configured, you will need to create a CNAME DNS record that resolves those domains to your PrivateLink VPC endpoint's DNS name (the same endpoints used for the Governance PrivateLink).
For example, if your VPC endpoint DNS name is vpce-0d363d9ea82658bec-e4wo04x9.vpce-svc-0d12345ddd89101112.us-east-1.vpce.amazonaws.com, you should create CNAME records that resolve app.immutacloud.com and marketplace-fe.immutacloud.com to your VPC endpoint DNS name.
The end result should be that, inside your network, DNS resolution to app.immutacloud.com and marketplace-fe.immutacloud.com will direct traffic to your VPC endpoint, and the Request app should be accessible along with your tenant.
If your Identity Provider only supports public SCIM endpoints, please see .
In order to prevent these integrations from becoming degraded, please ensure that they can send traffic to your PrivateLink endpoint.
