Enter a short description of your concept here (optional).

An internet-facing cluster deployment makes the SystemLink Enterprise application accessible from the public internet while keeping the Kubernetes cluster infrastructure in private subnets. This architecture is suitable for organizations that need:

  • Remote access to distributed teams
  • Managing geographically dispersed test systems

What is an Internet-Facing Deployment?

In an internet-facing deployment, users access the SystemLink web application and API through the public internet via HTTPS. The term "internet-facing" refers to the application accessibility, not the cluster infrastructure itself. The Kubernetes cluster nodes, databases, and internal services remain in private subnets without direct internet exposure.

Architecture Overview

A typical internet-facing SystemLink deployment uses the following network architecture:

  • Public subnets: Host load balancers (Application Gateway on Azure, Application Load Balancer on AWS) that accept HTTPS traffic from the internet
  • Private subnets: Host Kubernetes cluster nodes, databases, and all SystemLink services with no direct internet access
  • NAT Gateway: Provides outbound internet connectivity for cluster nodes to download updates, pull container images, and communicate with external services
  • Ingress controller: Runs in the Kubernetes cluster and routes traffic from the load balancer to SystemLink services
Note The following is a reference architecture. Your organization might implement internet-facing access using different components or different configurations based on your specific requirements and specific cloud platform.

Stages of a typical traffic flow:

  1. User connects to public DNS name (e.g., systemlink.example.com) via HTTPS
  2. DNS resolves to the public IP address of the load balancer in a public subnet
  3. Load balancer performs TLS termination and forwards traffic to the Kubernetes ingress controller in a private subnet
  4. Ingress controller routes requests to the appropriate SystemLink service pods in the private subnet
  5. Services respond back through the same path

For detailed subnet architecture and configuration, refer to AWS VPC or Azure VNet.

Security Requirements

NI recommends additional security measures for internet-facing deployments beyond those used in private deployments.

NI strongly recommends that all internet traffic to SystemLink use HTTPS with valid TLS certificates. NI recommends avoiding exposing HTTP endpoints to the public internet.

  • Certificate acquisition: Use the managed certificates from your cloud provider (AWS Certificate Manager, Azure Key Vault Certificates), or obtain certificates from a trusted certificate authority
  • TLS termination: NI recommends configuring TLS termination at the load balancer for simplified certificate management

NI recommends deploying a Web Application Firewall to protect against common web exploits and attacks. You can use cloud provider WAF services (AWS WAF, Azure Web Application Firewall) or third-party WAF solution.

DNS Configuration

Create DNS records in your public DNS zone for SystemLink endpoints. Refer to Layer 7 (Application) Ingress for web UI and API configuration, and Layer 4 (TCP) Ingress for Salt Master configuration. For OIDC redirect URI configuration, refer to Identity and Access Management.