lander.log

AWS ALB Ingress Backend Protocol

4 min read

AWS ALB Ingress Backend Protocol

정의 (Definition)

AWS Load Balancer Controller에서 Backend Protocol은 ALB가 클라이언트로부터 받은 요청을 Kubernetes Pod(Target)로 전달할 때 사용할 통신 프로토콜(HTTP vs HTTPS) 을 결정하는 설정입니다. 기본값은 HTTP이며, alb.ingress.kubernetes.io/backend-protocol 어노테이션으로 제어합니다.

문제가 되는 배경 (Problem Context)

Ingress에 TLS 인증서를 설정하여 HTTPS(443)를 열면, 일반적으로 TLS Termination이 ALB에서 일어납니다. 즉, Client → ALB (암호화), ALB → Pod (평문 HTTP) 로 통신합니다. 보안 규정상 End-to-End 암호화(E2EE) 가 필요하거나, gRPC 등을 사용하여 백엔드까지 TLS가 유지되어야 하는 경우, ALB가 평문으로 트래픽을 보내면 연결이 실패하거나 보안 위반이 됩니다.

핵심 메커니즘 (How it Works)

1. HTTP Backend (기본값)

  • 동작: ALB가 인증서를 사용하여 복호화한 후, 파드의 containerPort(보통 8080 등)로 HTTP 평문 전송을 합니다.
  • 장점: 파드에서 인증서 관리가 필요 없음. CPU 부하 감소. 설정 간단.
  • 설정: 별도 어노테이션 불필요.

2. HTTPS Backend (재암호화)

  • 동작: ALB가 복호화한 트래픽을 다시 암호화하여 파드로 전송합니다.
  • 요구사항:
    1. 파드가 자체 인증서(Self-signed 포함) 를 가지고 TLS 포트(예: 8443)를 리슨해야 함.
    2. alb.ingress.kubernetes.io/backend-protocol: HTTPS 설정.
    3. alb.ingress.kubernetes.io/healthcheck-protocol: HTTPS 설정 (헬스체크도 암호화 필요).
  • 장점: VPC 내부 구간까지 암호화하여 보안성 강화(Zero Trust).

불변 조건과 보장 범위 (Invariants & Guarantees)

  • Service Port 무관성: Kubernetes Service의 포트가 443이라고 해서 자동으로 HTTPS 백엔드가 되는 것이 아닙니다. ALB는 오직 Ingress 어노테이션과 Target Group 설정을 따릅니다.
  • 인증서 검증: ALB는 기본적으로 백엔드 파드의 인증서 유효성(CA 신뢰 등)을 엄격하게 검증하지 않을 수 있으나(설정 의존), TLS 핸드셰이크 자체는 성공해야 합니다.

실무적 함의 (Operational Implications)

  • 사이드카 패턴: 애플리케이션 코드를 수정하지 않고 HTTPS 백엔드를 구현하기 위해, Envoy나 Nginx 사이드카를 파드에 배치하여 TLS Termination을 수행하고 로컬(localhost) 앱으로 넘기는 방식이 흔히 사용됩니다.
  • 포트 혼동 주의: Ingress Rule의 service.port는 ALB가 트래픽을 보낼 목적지입니다. HTTPS 백엔드를 쓴다면 이 포트가 파드의 TLS 포트와 매핑되어야 합니다.

주의사항 / 오해 (Pitfalls & Misconceptions)

  • “서비스 443 포트를 열면 HTTPS다?”: 아닙니다. 파드가 실제로 TLS 핸드셰이크를 처리하지 못하면 443 포트로 보내도 에러(Connection Reset/Timeout)만 발생합니다.
  • ssl-redirect와의 관계: ssl-redirect는 Client → ALB 구간의 강제성이고, backend-protocol은 ALB → Pod 구간의 프로토콜입니다. 서로 독립적입니다.

References

Recent Posts