Endpoint aliases¶

Configuring Endpoint aliases¶

Omnistrate additionally enables users to assign specific aliases to any deployment or resource instance endpoints. By configuring DNS records, users can map their deployment endpoints to these aliases. These are configured per Resource. Eg: If you have two Resources DB and Redis in your SaaS architecture, you can allow your users to configure a custom DNS for each of these Resources separately.

The feature offers the capability to configure the deployments with specific domain, providing enhanced branding, customization, and control over their infrastructure. The endpoint aliases feature supports SSL/TLS encryption for secure communication between clients and the configured endpoint.

Compose Spec Configuration¶

Users can enable the endpoint aliases feature in the compose spec:

services:
  web:
    image: nginx
    x-omnistrate-capabilities:
      customDNS:
        targetPort: 80

Plan Spec Configuration¶

If you're using the Plan spec for deploying a Helm chart, Kustomize resource or an Operator CRD, you can enable it in the Plan spec:

services:
  - name: web
    capabilities:
      customDNS:
        TargetKubernetesService:
          TargetName: my-service
          TargetPort: 80

targetPort is the port number where your http service is listening on. TargetKubernetesService is the target Kubernetes service to which the alias should be mapped to.

Enabling custom DNS with HTTPS load balancer¶

You can also enable custom DNS at the HTTPS (L7) load balancer level by setting enableCustomDNS: true on the load balancer configuration. This applies the custom DNS alias to the load balancer endpoint rather than to an individual Resource endpoint.

Compose Spec Configuration¶

x-omnistrate-load-balancer:
  https:
    - name: api-gateway
      enableCustomDNS: true
      paths:
        - associatedResourceKey: gateway
          path: /

Plan Spec Configuration¶

loadBalancers:
  https:
    - name: api-gateway
      enableCustomDNS: true
      paths:
        - associatedResourceKey: gateway
          path: /
          backendPort: 80

enableCustomDNS enables custom DNS on the L7 load balancer, allowing your customers to configure a domain alias for the load balancer endpoint.

Custom DNS as an Input Parameter¶

When you enable the customDNS capability on a Resource, Omnistrate automatically exposes the custom DNS hostname as an input parameter for your customers. This means your customers can provide their desired domain name directly during instance creation or update it afterward, without requiring additional configuration from the SaaS Provider.

The input parameter appears in the Customer Portal and API as a configurable field on the Resource. When a customer provides a domain name, Omnistrate provisions the necessary infrastructure (L7 load balancer, TLS certificate) and returns the TXT verification record that the customer must add to their DNS configuration.

How it works¶

1. SaaS Provider enables customDNS capability in the Compose Spec or Plan Spec
2. Customer provides their desired domain name as an input parameter when creating or updating an instance
3. Omnistrate provisions the L7 load balancer and generates a TXT verification record
4. Customer adds the TXT record and CNAME or A record to their DNS provider
5. Omnistrate verifies domain ownership and provisions the TLS certificate

Setting up custom endpoint aliases¶

• Users can register or transfer a custom domain name through a domain registrar of their choice.
• Once the domain is acquired, users can update their custom resource instance endpoint with the newly acquired custom domain name.
• Next, users need to configure DNS settings and create CNAME or A record to map their custom domain to the target endpoint provided by Omnistrate.
• Additionally, users must add a TXT record with the "verification-" prefix to their custom domain, using the instance ID as the value to verify domain ownership.
• Omnistrate facilitates secure communication over HTTPS, with certificates issued by trusted public certificate authorities (CAs), such as Google CA.

After configuring DNS settings, SSL certificates, and endpoint configurations, users can validate domain ownership and initiate DNS propagation to ensure that domain mappings are applied correctly. Domain propagation may take some time to propagate globally and become accessible to users worldwide.