TLS certificates

How TLS certificates work for e6data endpoints - Serverless (managed by e6data) vs In-VPC (managed by you).

All e6data endpoints are TLS-protected. How the certificate is managed depends on your deployment model.

Serverless

For Serverless workspaces, e6data manages TLS certificates automatically:

Certificates are issued by a public CA and rotated before expiry
No action is required from you
The certificate covers the workspace endpoint provisioned by e6data

If you want a custom hostname (e.g., analytics.acme.com) instead of the default e6data-provided hostname, contact your e6data CSM - this is supported as a paid add-on.

In Your VPC

For In-VPC deployments, you manage the certificate. The certificate covers your custom endpoint hostname (e.g., e6data.acme.com).

Initial certificate

During workspace deployment, you create a Kubernetes TLS secret with your certificate:

kubectl create secret tls envoy-tls \
  -n <WORKSPACE_NAME> \
  --cert=fullchain.pem \
  --key=privkey.pem

A single certificate covering the workspace's specific hostname is sufficient. No wildcard required.

Using Let's Encrypt with cert-manager

cert-manager is installed as part of the base cluster setup. To use Let's Encrypt:

Create a ClusterIssuer pointing to Let's Encrypt's production server
Create a Certificate resource targeting your workspace's hostname
cert-manager fetches and renews the certificate automatically

See the cert-manager documentation for the exact resource specs.

The Certificate resource must produce a secret named envoy-tls - the name the QueryRouter references in spec.auth.tls.secretName.

Using your own CA

If your organization runs an internal CA:

Generate a CSR for your workspace's hostname
Submit to your CA
Receive the certificate and chain
Create the Kubernetes TLS secret as shown above

Certificate rotation is on you - set up a reminder to renew before expiry, or automate with cert-manager pointing at your internal CA's ACME endpoint (if supported).

Certificate rotation

To rotate the certificate:

Generate or fetch a new certificate

Update the TLS secret:

kubectl create secret tls envoy-tls \
  -n <WORKSPACE_NAME> \
  --cert=new-fullchain.pem \
  --key=new-privkey.pem \
  --dry-run=client -o yaml | kubectl apply -f -

Envoy automatically picks up the new certificate - typically within a minute, depending on how quickly kubelet syncs the updated secret to the pod; no pod restart needed

If you're using cert-manager, rotation happens automatically.

Monitoring certificate expiry

Set up alerting in your observability stack on certificate expiry:

Most observability platforms have a built-in TLS-expiry check
For self-monitoring, query kubectl get secret envoy-tls -o jsonpath='{.data.tls\.crt}' | base64 -d | openssl x509 -enddate -noout

Aim to rotate at least 14 days before expiry.

Verifying your endpoint

Check the certificate served by your workspace endpoint:

openssl s_client -connect <workspace-endpoint>:443 -servername <workspace-endpoint> </dev/null 2>/dev/null | \
  openssl x509 -noout -subject -issuer -dates

Should show your hostname as the subject and a valid date range.