Installer Guides

Securing LightBeam on EKS with AWS Certificate Manager on Elastic Load Balancer

Overview

This document provides a comprehensive guide to secure the LightBeam app on an EKS cluster utilizing AWS Certificate Manager (ACM) on an Elastic Load Balancer (ELB). The primary goal is to employ either a custom certificate or one issued by Amazon, managed by ACM, to terminate TLS on the LightBeam cluster. The ELB is the chosen point of integration as it natively works with ACM.

AWS Subnet Requirement

ALB/CLB must be deployed into subnets that each have at least 8 free IPs.If your existing subnet (e.g., 10.253.0.32/28) doesn’t have enough IPs, ELB creation fails.

Current state

Objective

  • To use a custom certificate or an Amazon-issued certificate hosted and managed by AWS Certificate Manager (ACM) to terminate TLS on the LightBeam cluster.

  • This will happen on the Elastic Load Balancer since it integrates with AWS Certificate Manager by default.

Steps

Create the ACM certificate

  • Create the ACM certificate either by requesting a new one or by importing an existing certificate.

    • In case the certificate is still pending DNS validation, check that the CNAME record specified by ACM is created and active. You can use nslookup to verify that the domain is being resolved correctly. Here are a few resources that may be useful: troubleshooting certificate validation and DNS validation knowledge center article.

    • Validation is done to prove that you actually own the domain that you are requesting a certificate for. ACM requires you modify the DNS so as to show that you have control over the domain.

  • Note down the ACM certificate ARN for the next step.

Update the Ingress spec

  • Run kubectl edit ingress lightbeam-ingress-auth-svc to access the editor.

  • Add the host domain name to the rules section in the Ingress spec:

    • spec:
  rules:
  - host: sub-domain.domain-name

  • Add the TLS section to the Ingress spec:

    •   tls:
  - hosts:
    - sub-domain.domain-name

Update the kong-proxy service spec

  • Run kubectl edit service kong-proxy to access the editor.

  • Add the following annotations:

    • service.beta.kubernetes.io/aws-load-balancer-ssl-cert: <ACM Certificate ARN>
service.beta.kubernetes.io/aws-load-balancer-ssl-ports: "443"

  • Update the following annotation values:

    • service.beta.kubernetes.io/aws-load-balancer-type: alb
service.beta.kubernetes.io/aws-load-balancer-backend-protocol: http

    • This needs to be updated since a Network Load Balancer cannot act as a TLS/HTTPS termination point, only an Application or Classic load balancer can.

    • NLB (Network Load Balancer) only supports TCP/UDP/QUIC.It cannot terminate HTTPS/TLS — it simply forwards encrypted traffic to your backend.

    • Application Load Balancer (ALB) or Classic Load Balancer (CLB) is required to:

      • Terminate TLS/HTTPS connections

      • Attach ACM certificates

      • Use Ingress resources for Kubernetes (ALB preferred)

  • Update the proxy-ssl port's targetPort in the spec section:

    •   - name: proxy-ssl
    nodePort: 30910
    port: 443
    protocol: TCP
    targetPort: 8000 #Same value as the proxy port's targetPort.

    • This is done to make sure we are redirecting back to the original listener as we are just terminating HTTPS and not directing traffic to a new port.

Update the ingress-kong deployment spec

  • Run kubectl edit deployment ingress-kong to access the editor.

  • Add the following values to the env section within the spec section:

    •       - env:
        - name: KONG_TRUSTED_IPS
          value: 0.0.0.0/0

    • This is needed to ensure that when load balancer performs the TLS termination and sets the X-Forwarded-Proto header, kong honors it and understands that the original request was made on HTTPS. The value can be limited to IPs within a customer VPN or VPC.

Route traffic to the Load Balancer

  • Create a CNAME DNS record in AWS Route 53 to map the host domain name to the domain name of the Load Balancer. The domain name of the Load Balancer can be copied from the AWS console. You can also verify that the Load Balancer and the EKS cluster are on the same VPC.

💡Notes

  • An AWS Elastic Load Balancer does not always have to be associated with an EC2 instance even though most AWS documentation suggests so. A standalone ELB can (and is, in this case) be provisioned through the service.beta.kubernetes.io/aws-load-balancer-type annotation.

  • These steps do not work if the LightBeam chart has been installed with the dev-values.yaml values as there is an issue with the health of the load balancer listeners. Also, the externalIP value causes traffic to bypass the load balancer.

About LightBeam

LightBeam automates Privacy, Security and AI Governance, so businesses can accelerate their growth in new markets. Leveraging generative AI, LightBeam has rapidly gained customers’ trust by pioneering a unique privacy-centric and automation-first approach to security. Unlike siloed solutions, LightBeam ties together sensitive data cataloging, control, and compliance across structured and unstructured data applications providing 360-visibility, redaction, self-service DSRs and automated ROPA reporting ensuring ultimate protection against ransomware and accidental exposures while meeting data privacy obligations efficiently. LightBeam is on a mission to create a secure privacy-first world helping customers automate compliance against a patchwork of existing and emerging regulations.

For any questions or suggestions, please get in touch with us at: [email protected].

PreviousFirewall RequirementsNextConfigure HTTPS for LightBeam Endpoint FQDN Standalone deployment

Last updated