Amazon EKS

Overview

The Amazon EKS integration runs the Pomerium Kubernetes Ingress Controller in an EKS cluster. Pomerium handles Ingress resources that select the pomerium class. The AWS Load Balancer Controller or the selected EKS service controller exposes the Pomerium entry service.

EKS workloads can stay on private Service addresses while Pomerium owns user authentication and route policy. Explicit controller selection keeps application Ingress resources separate from AWS load-balancer resources.

EKS runs the Kubernetes resources. The Pomerium controller converts matching Ingress resources into protected routes. AWS networking exposes the Pomerium service through the reviewed load-balancer design.

How it works

Verify the current Pomerium requirements. Install a pinned controller version and complete the global Pomerium custom resource. Use the documented http3-eks variant only when the design needs HTTP/3.

Create the application Ingress with the pomerium class and a private Service backend. Do not assign the AWS ALB class and the Pomerium class to the same application Ingress.

Validate the Pomerium LoadBalancer Service, AWS target health, security groups, subnets, DNS, TLS, controller events, and backend endpoints. Test an allowed request and a denied request.

Example

A private Grafana Service has a TLS Ingress with spec.ingressClassName: pomerium. The Pomerium controller builds the route and policy. The platform team exposes Pomerium through an EKS load balancer instead of giving Grafana its own public load balancer.

Considerations

• The Pomerium controller and AWS Load Balancer Controller own different resources. AWS creates an ALB for its Ingress resources and an NLB for LoadBalancer Services.
• Validate EKS Auto Mode, Fargate, load-balancer, storage, architecture, and security-context constraints for the selected cluster.
• Pomerium does not protect the EKS control plane or all east-west traffic.