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.

Securing other aspects of WebRTC traffic

WebRTC communication between a client and a server involves two key components: signaling traffic and media/data traffic. TLS is used to secure signaling traffic, ensuring the safe exchange of session details needed to establish the connection.

For media and data traffic, WebRTC uses DTLS and SRTP to provide end-to-end encryption, ensuring all streams remain secure.

Encryption protocols for the various forms of traffic:

  • Signaling Traffic: TLS can be used secure signaling traffic via HTTPS or WSS.

  • Media Traffic: DTLS/SRTP handles encryption for media streams.

  • Data Channel Traffic: DTLS secures the data channel traffic.

Beyond encrypting the traffic, authentication and authorization can be used to make the initial connection to the stream more secure.

Authorizing a WebRTC Stream

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.

More information

A TLS certificate is a digital credential that verifies a website’s identity and enables secure, encrypted connections. It contains the site’s public key and organizational details.

Certificates are generated for a specific domain (e.g., api.mycluster.com) or use a wildcard (e.g., *.mycluster.com) to cover everything in one level of subdomains. This means that *.mycluster.com covers nlbs.mycluster.com but not nlb1.nlbs.mycluster.com.

It is crucial you are clear on the structure and naming of the cluster topology you will use for TLS Termination, NLB routing and API-Gateway access, as these all need valid TLS Certificates, with proper coverage, for secure communication.

Kubernetes’ cert-manager can be used with the primary CSPs as well as third-party certificate management providers to help you in managing your TLS Certificates. Similarly, ExternalDNS can help you manage your DNS entries.

The major CSPs have their own Certificate Management services, such as AWS Certificate Manager (ACM) and Azure App Service Certificates. These services tend to be very well integrated and can simplify your deployment.

Alternatively, there are various third-party credential management providers that work with Kubernetes’ cert-manager, such as Let’s Encrypt, DigiCert, GlobalSign, Venafi and ZeroSSL. 1

Further discussion of DNS configuration and TLS Certificate generation are highly dependent on the specific deployment strategy and platform chosen and are outside the scope of this guide.

1

These are provided as examples and should not be considered recommendations or endorsements.

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
 1apiVersion: omniverse.nvidia.com/v1
 2kind: ApplicationProfile
 3metadata:
 4  name: nlb-tls
 5spec:
 6  name: NLB example profile using TLS
 7  description: Default profile - uses an AWS NLB per stream 
 8  supportedApplications:
 9    - name: "usd-viewer"
10      versions: 
11        - "*"
12    - name: "usd-explorer"
13      versions: 
14        - "*"
15  chartValues:
16    global:
17      imagePullSecrets:
18        - name: regcred
19    streamingKit:
20      sessionId: session_id
21      service:
22        signalingPort: 443
23        mediaPort: 80
24        healthPort: 31002
25        annotations:
26          # NLB configuration
27          service.beta.kubernetes.io/aws-load-balancer-type: "external"
28          service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: "ip"
29          service.beta.kubernetes.io/aws-load-balancer-scheme: "internet-facing"
30          service.beta.kubernetes.io/load-balancer-source-ranges: "<replace with allowed ranged>"
31          # Cross zone
32          service.beta.kubernetes.io/aws-load-balancer-attributes: "load_balancing.cross_zone.enabled=true"
33          # Health check
34          service.beta.kubernetes.io/aws-load-balancer-healthcheck-protocol: "HTTP"
35          service.beta.kubernetes.io/aws-load-balancer-healthcheck-port: "8080"
36          service.beta.kubernetes.io/aws-load-balancer-healthcheck-path: "/health"
37          # DNS Annotations
38          external-dns.alpha.kubernetes.io/hostname: "<not set, will be done dynamically>"
39          # NLB TLS Annotations
40          service.beta.kubernetes.io/aws-load-balancer-ssl-cert: "<replace me with SSL cert ARN>"
41          service.beta.kubernetes.io/aws-load-balancer-ssl-ports: "443"
42          service.beta.kubernetes.io/aws-load-balancer-ssl-negotiation-policy: "ELBSecurityPolicy-TLS13-1-2-2021-06"
43          service.beta.kubernetes.io/aws-load-balancer-backend-protocol: "tcp"
44        type: LoadBalancer
45      name: kit-app
46      resources:
47        requests:
48          nvidia.com/gpu: "1"
49        limits:
50          cpu: "3"
51          memory: "20Gi"
52          nvidia.com/gpu: "1"
53      env:
54        - name: USD_PATH
55          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.