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

• You have an Immuta SaaS tenant.

• Your Starburst (Trino) Cluster is hosted on AWS.

• You have set up an AWS PrivateLink Service for your Starburst 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).

  • 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:

1. 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.

2. 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

1. 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

2. Authorize the service principal provided by your representative so that Immuta can complete the VPC endpoint configuration.
3. Configure the Starburst (Trino) integration.
4. Register your tables as Immuta data sources.