Traffic Encryption#

TLS can be used to secure a WebRTC stream by encrypting signaling communication between the client and server. The method depends on where TLS is terminated; either at the NLB fronting a GPU worker node, or at the POD via Envoy Proxy.

This guide covers both approaches, detailing how to integrate TLS into the existing process of initiating a new streaming session using standard methods.

TLS Termination#

Pod-Level Termination: TLS can be terminated directly at the pod level. In this configuration, each stream is secured by an Envoy Proxy sidecar, which handles TLS termination. This method ensures the entire stream remains encrypted end-to-end, including traffic within the Kubernetes cluster.
Load Balancer Termination: TLS termination can also occur at the Network Load Balancer (NLB) level. In this approach, TLS termination happens at the NLB, meaning that traffic between the client and the NLB is encrypted, but traffic between the NLB and the Kit Application pods within the cluster is not. The NLB handles the TLS certificates and decryption.

Detailed Pros & Cons

Some of this information, while technically correct, may not be as relevant when specifically considering Kit Application streaming.

TLS Termination at the POD with Envoy Proxy (Sidecar Approach)

Overview:

In this approach, Envoy Proxy is deployed as a sidecar alongside the streaming Kit Application pod. The Envoy proxy handles TLS termination, meaning that all traffic between the client and the Kit Application is encrypted until it reaches the Envoy sidecar within the pod.

Pros:

End-to-End Encryption: The connection remains encrypted all the way to the pod, ensuring the entire communication path (from client to application) is secure.
Granular Control: Allows more fine-grained control over traffic management at the application level, including advanced features like rate limiting, traffic shaping, and authentication at the pod level.
Flexible Routing: Envoy Proxy can be configured with advanced routing capabilities, load balancing, and service discovery. This allows different pods to have different certificate configurations if needed.

Cons:

Increased Complexity: Deploying Envoy as a sidecar adds complexity to the deployment, with the need for managing Envoy configurations and certificate distribution at the pod level.
Resource Overhead: Running an Envoy sidecar alongside every pod increases the resource consumption (CPU, memory) since each pod will have its own instance of Envoy.
Operational Overhead: Managing TLS certificates at the pod level can become more complex, particularly if you are dealing with many pods, each requiring secure certificate updates and renewals.

TLS Termination at the Network Load Balancer (NLB)

Overview:

In this approach, TLS termination happens at the NLB, meaning that traffic between the client and the NLB is encrypted, but traffic between the NLB and the Kit Application pods within the cluster is not. The NLB handles the TLS certificates and decryption.

Pros:

Simplified Management: TLS certificates are managed centrally at the NLB level, simplifying certificate management and updates. There’s no need to distribute certificates across all the pods.
Lower Resource Overhead: Since TLS termination occurs at the NLB, the pods only handle unencrypted traffic, reducing the computational load on each pod.
Performance: Offloading TLS termination to the NLB can reduce the overhead on the application pods, potentially improving performance, especially in high-throughput streaming environments.
Centralized Control: By managing TLS at the NLB, it is easier to implement consistent security policies across all incoming traffic.

Cons:

Lack of End-to-End Encryption: The communication between the NLB and the Kit Application pods is unencrypted, which could expose internal traffic to security risks unless it is running in a secure, private network.
Less Granular Control: Since TLS termination happens at the NLB, there is less control over traffic management at the application level. Features like fine-grained authentication or advanced traffic policies would need to be handled at the NLB, which may be limited in functionality compared to Envoy.
Single Point of Failure for TLS: The NLB becomes the single point responsible for terminating TLS, which could be a risk if not managed properly (e.g., certificate expiry, NLB misconfiguration).

Key Differences:

Aspect	TLS at Envoy Sidecar (Pod-Level)	TLS at Network Load Balancer (NLB)
Encryption Scope	End-to-end encryption, including pod-level communication	Encryption ends at the NLB; internal traffic is unencrypted
Traffic Control	Granular control over traffic at the application/pod level	Centralized control, but less granularity over traffic policies
Operational Complexity	Higher complexity due to managing sidecars and certificates	Simpler, with centralized TLS management at the NLB
Resource Overhead	Higher, as each pod requires additional resources for Envoy	Lower, as TLS termination is offloaded to the NLB
Performance	Potential performance impact due to pod-level TLS handling	Potential performance gain, as pods only handle unencrypted traffic
Security	Stronger security with end-to-end encryption	Weaker internal security unless additional internal encryption is added
Certificate Management	Certificates managed per pod; more complex to scale	Centralized certificate management at the NLB

When to Choose Each Approach:

Envoy Sidecar:

When you need end-to-end encryption and fine-grained control over traffic at the pod level.
When the security requirements demand that even internal traffic between the NLB and the pods must be encrypted.
If you need to implement advanced routing, mutual TLS, or complex traffic policies.

NLB Termination:

When you want to simplify TLS management and reduce the resource overhead on application pods.
When internal traffic is either trusted or within a secure network (e.g., private VPC), and encryption beyond the NLB is not necessary.
When you need to optimize performance for high-throughput applications without the overhead of pod-level TLS termination.

Conclusion

Both approaches have trade-offs between security, performance, and operational complexity, and the right choice depends on your deployment’s specific security and performance requirements.

Creating TLS certificates#

Before enabling TLS encryption, you must first create a TLS certificate with appropriate coverage for your cluster, based on your TLS termination method.

Wildcard certificates (*.mydomain.com) are recommended when deploying multiple NLBs, especially when using individual load balancers per stream, as they help simplify certificate management.

POD level termination#

Each stream is configured with an Envoy Proxy sidecar that can be used for TLS termination. This ensures a stream is fully encrypted end-to-end, including within the cluster.

This assumes a TLS wildcard certificate has already been created and the user has access to both the public and private keys.#

apiVersion: omniverse.nvidia.com/v1
kind: ApplicationProfile
metadata:
   name: nlb
spec:
   name: NLB example profile
   description: Default profile - uses an AWS NLB per stream
   supportedApplications:
      - name: "usd-viewer"
         versions:
            - "*"
   chartMappings:
      container: streamingKit.image.repository
      container_version: streamingKit.image.tag
      name: streamingKit.name
   chartValues:
      global:
         imagePullSecrets:
            - name: regcred
      streamingKit:
         envoyTLS:
            enabled: true
            secretRef: sessions-tls-secret
         <... other values ...>

Load balancer termination#

Augmenting the AWS NLB sample values.yaml with the highlighted lines to enable NLB TLS Termination#

apiVersion: omniverse.nvidia.com/v1
kind: ApplicationProfile
metadata:
  name: nlb-tls
spec:
  name: NLB example profile using TLS
  description: Default profile - uses an AWS NLB per stream 
  supportedApplications:
    - name: "usd-viewer"
      versions: 
        - "*"
    - name: "usd-explorer"
      versions: 
        - "*"
  chartValues:
    global:
      imagePullSecrets:
        - name: regcred
    streamingKit:
      sessionId: session_id
      service:
        signalingPort: 443
        mediaPort: 80
        healthPort: 31002
        annotations:
          # NLB configuration
          service.beta.kubernetes.io/aws-load-balancer-type: "external"
          service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: "ip"
          service.beta.kubernetes.io/aws-load-balancer-scheme: "internet-facing"
          service.beta.kubernetes.io/load-balancer-source-ranges: "<replace with allowed ranged>"
          # Cross zone
          service.beta.kubernetes.io/aws-load-balancer-attributes: "load_balancing.cross_zone.enabled=true"
          # Health check
          service.beta.kubernetes.io/aws-load-balancer-healthcheck-protocol: "HTTP"
          service.beta.kubernetes.io/aws-load-balancer-healthcheck-port: "8080"
          service.beta.kubernetes.io/aws-load-balancer-healthcheck-path: "/health"
          # DNS Annotations
          external-dns.alpha.kubernetes.io/hostname: "<not set, will be done dynamically>"
          # NLB TLS Annotations
          service.beta.kubernetes.io/aws-load-balancer-ssl-cert: "<replace me with SSL cert ARN>"
          service.beta.kubernetes.io/aws-load-balancer-ssl-ports: "443"
          service.beta.kubernetes.io/aws-load-balancer-ssl-negotiation-policy: "ELBSecurityPolicy-TLS13-1-2-2021-06"
          service.beta.kubernetes.io/aws-load-balancer-backend-protocol: "tcp"
        type: LoadBalancer
      name: kit-app
      resources:
        requests:
          nvidia.com/gpu: "1"
        limits:
          cpu: "3"
          memory: "20Gi"
          nvidia.com/gpu: "1"
      env:
        - name: USD_PATH
          value: "/app/data/Forklift_A/Forklift_A01_PR_V_NVD_01.usd"

DNS management#

For TLS to function correctly, the NLB’s DNS record must be covered by its TLS certificate.

Automatic DNS registration can be managed by the external-dns operator. Installation guides are provided for AWS and Azure.