한 회사에서 전송 중 암호화가 필요한 서비스를 만들 계획입니다. 클라이언트와 서비스 백엔드 사이의 트래픽이 해독되어서는 안 됩니다. 회사는 TCP 포트 443을 통해 gRPC 프로토콜을 사용하여 서비스를 구현할 예정입니다. 이 서비스는 최대 수천 개의 동시 연결로 확장됩니다.
서비스의 백엔드는 Kubernetes Cluster Autoscaler 및 Horizon Pod Autoscaler가 구성된 Amazon Elastic Kubernetes Service(Amazon EKS) Duster에서 호스팅됩니다. 회사는 클라이언트와 백엔드 간의 양방향 인증을 위해 상호 TLS를 사용해야 합니다.
어떤 솔루션이 이러한 요구 사항을 충족합니까?
A. Kubernetes용 AWS 로드 밸런서 컨트롤러를 설치합니다. 해당 컨트롤러를 사용하여 포트 443의 TCP 리스너로 Network Load Balancer를 구성하여 백엔드 서비스 포드의 IP 주소로 트래픽을 전달합니다.
B. Kubernetes용 AWS 로드 밸런서 컨트롤러를 설치합니다. 해당 컨트롤러를 사용하여 포트 443의 HTTPS 리스너로 Application Load Balancer를 구성하여 백엔드 서비스 포드의 IP 주소로 트래픽을 전달합니다.
C. 대상 그룹을 만듭니다. EKS 관리형 노드 그룹의 Auto Scaling 그룹을 대상으로 추가합니다. 포트 443에서 HTTPS 리스너가 있는 Application Load Balancer를 생성하여 대상 그룹에 트래픽을 전달합니다.
D. 대상 그룹을 만듭니다. EKS 관리형 노드 그룹의 Auto Scaling 그룹을 대상으로 추가합니다. 포트 443에 TLS 리스너가 있는 Network Load Balancer를 생성하여 대상 그룹에 트래픽을 전달합니다.
답변: D
A. Network Load Balancer (NLB) 사용: NLB는 Layer 4에서 작동하며, TCP 트래픽을 지원합니다. 하지만, HTTPS 리스너 또는 TLS 종료 기능은 지원하지 않습니다. 이 옵션은 백엔드 서비스 포드의 IP 주소로 트래픽을 전달하는 것을 포함하지만, TLS 종료는 언급하지 않습니다. 따라서, 이 옵션은 양방향 TLS 인증을 직접 지원하지 않습니다.
B. Application Load Balancer (ALB) 사용: ALB는 Layer 7에서 작동하며, HTTPS 리스너를 지원합니다. 하지만, ALB는 일반적으로 TLS 종료를 지원하며, 클라이언트와 백엔드 사이의 양방향 TLS 인증 구성은 직접적으로 지원하지 않습니다. 또한, gRPC 트래픽(기본적으로 HTTP/2에 의존)을 처리할 수 있지만, 이 시나리오의 요구 사항에 완전히 맞지 않을 수 있습니다.
C. Application Load Balancer (ALB) 및 HTTPS 리스너 사용: 이 옵션도 ALB를 사용하지만**, gRPC 및 양방향 TLS 인증에 대한 명시적인 지원 없이** HTTPS 리스너에 초점을 맞춥니다. ALB는 TLS 종료를 제공할 수 있지만, 클라이언트와 서버 간의 암호화된 통신 경로를 유지하면서 양방향 TLS를 구성하는 데는 제한적입니다.
D. Network Load Balancer (NLB) 및 TLS 리스너 사용: 이 옵션은 포트 443에 TLS 리스너가 있는 NLB를 사용하여 대상 그룹에 트래픽을 전달합니다. NLB는 Layer 4에서 작동하며, TLS 리스너를 사용할 때 TLS 종료 옵션을 제공하지 않습니다. 이는 트래픽이 백엔드 서버까지 암호화된 상태를 유지한다는 것을 의미합니다. NLB를 사용하면 양방향 TLS 인증을 구성할 수 있으며, 이는 클라이언트와 백엔드 사이에 암호화된 통신을 유지하면서도 양방향 인증을 가능하게 합니다. 따라서, 이 옵션은 gRPC 트래픽과 양방향 TLS 인증의 요구 사항을 가장 잘 충족합니다.
리스너
![[AWS ANS-C01 #1] ALB, NLB / 로드밸런서 컨트롤러 설치 vs 대상그룹 만들어서 Auto Scaling / TLS 종료 [AWS ANS-C01 #1] ALB, NLB / 로드밸런서 컨트롤러 설치 vs 대상그룹 만들어서 Auto Scaling / TLS 종료](https://blog.kakaocdn.net/dn/b9EixJ/btsFSaipZ5F/OBG7ULuUaogWPEfw6BZVo1/img.png)
리스너
리스너는 규칙에 설정된 프로토콜과 포트번호에 따라 트래픽을 받아들입니다. 타겟의 서비스에 맞추어 리스너의 규칙을 정해야합니다.
대상그룹
하나 이상의 대상에 대하여 트래픽을 라우팅하여 부하분산을 합니다. 대상 그룹 내의 인스턴스들이 정상적으로 작동하고 있는지 Keepalive 프로세스를 사용해 주기적으로 확인합니다.
로드밸런서 컨트롤러 설치 vs 대상그룹 만들어서 Auto Scaling
로드 밸런서 컨트롤러를 설치하는 접근 방식
- Kubernetes용 AWS 로드 밸런서 컨트롤러를 설치하는 방식은 Kubernetes 클러스터와 AWS 로드 밸런서 사이의 직접적인 통합을 의미합니다. 이 컨트롤러는 Kubernetes 서비스를 AWS 로드 밸런서(이 경우 Network Load Balancer 또는 Application Load Balancer)와 동적으로 연결하여, Kubernetes 내부의 변화(예: 서비스 포드의 IP 주소 변동)에 자동으로 대응합니다.
- 이 방식은 Kubernetes 선언적 구성을 사용하여 로드 밸런서를 관리합니다. 즉, Kubernetes 리소스(예: 서비스, 인그레스)의 설정을 통해 로드 밸런서의 동작을 정의하고, 로드 밸런서 컨트롤러가 이를 AWS 로드 밸런서에 적용합니다.
대상 그룹을 만들어서 Auto Scaling하는 접근 방식
- AWS 중심: 이 방식은 AWS 관리 콘솔이나 AWS CLI를 통해 직접 Application Load Balancer(ALB)나 Network Load Balancer(NLB) 및 대상 그룹을 구성하는 것을 포함합니다. 여기서는 Kubernetes 클러스터 밖에서 로드 밸런서를 설정하고, EKS 관리형 노드 그룹이나 Auto Scaling 그룹을 대상으로 추가합니다.
- 비록 EKS 클러스터의 Auto Scaling은 자동으로 처리될 수 있지만, 로드 밸런서와 대상 그룹의 초기 설정은 수동으로 이루어집니다. Kubernetes 리소스와의 동적 통합은 AWS 로드 밸런서 컨트롤러를 통해 이루어지는 것이 아니라, AWS 자체의 설정과 정책에 의해 관리됩니다.
주요 차이점
- 관리 포인트: 로드 밸런서 컨트롤러를 사용하는 방식은 Kubernetes 내에서 로드 밸런싱 구성을 관리하게 하여, Kubernetes 환경과의 통합을 강화합니다. 반면, 대상 그룹과 Auto Scaling을 직접 설정하는 방식은 AWS 수준에서의 구성과 관리에 중점을 둡니다.
- 자동화와 유연성: 로드 밸런서 컨트롤러를 통한 접근 방식은 Kubernetes의 변화에 더 민감하게 반응하고, 자동화된 관리를 제공합니다. AWS 수준에서의 수동 설정은 초기 설정에 더 많은 작업을 필요로 하지만, AWS 리소스에 대한 더 직접적인 제어를 가능하게 합니다.
두 방식 모두 유효하지만, 프로젝트의 요구사항, 팀의 기술적 선호도, 관리 및 운영에 대한 전략에 따라 선택될 수 있습니다.
TLS 종료란?
TLS 종료는 TLS(Transport Layer Security) 암호화 통신 세션을 종료하는 과정을 의미합니다. 특히 네트워크 구성에서, TLS 종료는 일반적으로 클라이언트와 서버 간의 암호화된 통신을 중간에서 종료하고 복호화하는 지점을 가리킵니다. 이러한 종료 지점은 종종 로드 밸런서, 리버스 프록시, 또는 애플리케이션 전송 게이트웨이와 같은 네트워크 장비나 소프트웨어에 의해 수행됩니다.
TLS 종료의 주요 포인트는 다음과 같습니다:
- 암호화 해제: TLS 종료 지점에서는 TLS를 사용한 암호화된 데이터를 복호화합니다. 이로써, 해당 장비 또는 서비스는 복호화된 데이터를 읽고 처리할 수 있습니다.
- 성능: 암호화 및 복호화 과정은 리소스를 상당히 사용할 수 있습니다. TLS 종료를 네트워크의 앞단에서 수행함으로써, 백엔드 서버의 부담을 줄이고 성능을 최적화할 수 있습니다.
- 보안 및 관리: TLS 종료 지점을 중앙화함으로써, 보안 정책, 암호화 방식, 인증서 관리 등을 보다 효율적으로 수행할 수 있습니다. 예를 들어, SSL/TLS 인증서는 이 지점에서 설치 및 관리될 수 있으며, 모든 인바운드 연결에 대해 일관된 보안 기준을 적용할 수 있습니다.
TLS 종료 예시:
- 로드 밸런서: HTTPS 트래픽을 로드 밸런서로 라우팅할 때, 로드 밸런서에서 TLS 연결을 종료하고 트래픽을 복호화한 다음, 내부 네트워크 상의 백엔드 서버로 일반 텍스트(HTTP) 형태로 전달할 수 있습니다.
- 리버스 프록시: 외부에서 오는 암호화된 트래픽을 받아서 애플리케이션 서버 앞에서 복호화하고, 그 내용을 기반으로 내부 네트워크에서 적절한 서버로 요청을 전달합니다.
TLS 종료는 네트워크 아키텍처의 보안과 성능 최적화에 중요한 역할을 하지만, 종료 지점에서 복호화된 데이터가 처리되기 때문에, 이 지점을 보호하기 위한 추가적인 보안 조치가 필요합니다.
'DevOps > 🐝 AWS' 카테고리의 다른 글
[AWS ANS-C01 #2] ALB, NLB / X-Forwarded-For / IP 보존 (0) | 2024.03.19 |
---|---|
[AWS ANS] Listener 규칙 – Host header (호스트 조건) / Path (경로 조건) 차이 (0) | 2024.03.19 |
S3용 체크섬 알고리즘 추가하기 [AHSS 스터디 1주차] (1) | 2023.09.03 |
[AWS Network] VPC Peering과 Transit Gateway 차이 (0) | 2023.07.01 |
[AWS JAM - DB] DML(update) 작동시키는 사람 cloud insights로 찾기 (AUDIT USER ACTIVITY) (1) | 2023.02.03 |
댓글