Skip to content

DNS and ingress

The load balancer, DNS zone, and TLS certificate that publish your runtime plane's service endpoints.

Not needed on Trust3 AI Cloud

A Trust3 AI Cloud plane runs in Trust3AICloud, so Trust3AI provides all of this. See Deployment Options.

The steps are the same on Partially Managed (D2P) and Self-Managed; only the cloud differs. Self-Managed runs on AWS only.

Ingress controller

AWS only. The AWS Load Balancer Controller is required for managing ingress traffic: it provisions Application Load Balancers based on Kubernetes Ingress resources. Install it following the AWS Load Balancer Controller guide, then verify:

Bash
1
kubectl get pods -n kube-system -l app.kubernetes.io/name=aws-load-balancer-controller

You should see the pods in Running state (typically 2 replicas).

DNS zone

Trust3 uses a DNS zone to manage records for all service endpoints (for example *.trust3.yourdomain.com). The domain name you enter in the wizard must match the zone name.

  • Automatic DNS (default): Trust3 creates, updates, and deletes the records for you. This needs the cloud identity from Cloud permissions to hold the DNS role listed in your cloud's tab below.
  • Manual DNS: you create the records yourself after deployment; Trust3 provides the required record values.

A Route 53 hosted zone. Automatic DNS needs the IAM role to have Route 53 access.

Find your hosted zone:

Bash
1
aws route53 list-hosted-zones --query "HostedZones[*].{Name:Name,Id:Id}" --output table

If you do not have a hosted zone yet, create one in Route 53 and delegate it from your parent domain's DNS — common for a subdomain like trust3.yourdomain.com.

An Azure DNS zone. Automatic DNS needs the managed identity to have the DNS Zone Contributor role.

Find your DNS zone:

Bash
1
az network dns zone list --query "[].{Name:name,ResourceGroup:resourceGroup}" --output table

If you do not have one yet, create it and delegate from your parent domain's DNS:

Bash
1
az network dns zone create --resource-group <resource-group> --name trust3.yourdomain.com

A Cloud DNS managed zone. Automatic DNS needs the service account to have the DNS Admin role.

Find your managed zone:

Bash
1
gcloud dns managed-zones list --format="table(name,dnsName,visibility)"

If you do not have one yet, create it and delegate from your parent domain's DNS:

Bash
1
2
3
4
5
gcloud dns managed-zones create trust3-zone \
  --dns-name="trust3.yourdomain.com." \
  --description="Trust3 managed zone" \
  --visibility=public \
  --project=<project-id>

TLS certificate

The certificate must cover the service endpoint domain (for example *.trust3.yourdomain.com) and be in the same AWS region as your EKS cluster. It can be a public certificate issued by ACM or an existing certificate imported into ACM. Find its ARN:

Bash
1
aws acm list-certificates --region <region>

ARN format: arn:aws:acm:<region>:<account-id>:certificate/<certificate-id>

You need a CA-signed TLS certificate and key — a single wildcard certificate (for example *.corp.example.com) covers all Trust3 service endpoints on your domain. Have the certificate and key ready before installation, then create the TLS secret in your cluster. The secret name privacera-external-tls and the runtime namespace are fixed.

Bash
1
kubectl create namespace <runtime-name>

PEM format:

Bash
1
2
3
4
kubectl create secret tls privacera-external-tls \
  --cert="<cert-path>" \
  --key="<key-path>" \
  -n <runtime-name>
PFX/P12 format

Conversion needs OpenSSL (check with openssl version; drop the -legacy flag on OpenSSL versions below 3.x):

Bash
1
2
3
4
5
6
7
openssl pkcs12 -legacy -in "<pfx-path>" \
  -nokeys -out chain.pem
openssl pkcs12 -legacy -in "<pfx-path>" \
  -nocerts -nodes -out key.pem

kubectl create secret tls privacera-external-tls \
  --cert=chain.pem --key=key.pem -n <runtime-name>
On certificate renewal

Replace the secret:

Bash
1
2
3
4
5
kubectl create secret tls privacera-external-tls \
  --cert="<cert-path>" \
  --key="<key-path>" \
  -n <runtime-name> \
  --dry-run=client -o yaml | kubectl replace -f -

Load balancer settings

AWS only.

Setting Details
ALB subnets At least two subnet IDs where the Application Load Balancers will reside.
ALB group name (optional) Ingresses in the same group share one Application Load Balancer. Defaults to trust3ai.