EKS란 #3 Deep Dive on to EKS - 보안편

클러스터 엔드포인트 제한하는 방법

그렇다면 어떻게, 클러스터 엔드포인트로의 액세스를 제한할 수 있을까요?
EKS 처음 시작 시에 자주 들 수 있는 질문입니다.
기본적으로 클러스터를 생성하였을 때, 퍼블릭하게 액세스가 가능한 엔드포인트가 부여됩니다.
이런저런 내용을 테스트하기에는 좋지만, 프로덕션 레벨에서 사용하기에 모범 사례는 아닙니다.
 
또한, AWS는 클러스터에 대한 프라이빗 엔드포인트를 제공합니다.
클러스터의 VPC 내부에서 접근 가능합니다.
 
- 가능하다면, 퍼블릭 엔드포인트를 비활성화하고 프라이빗 엔드포인트를 사용하는 것을 권장합니다.
다이어그램에서 보시다시피, 프라이빗 엔드포인트를 활성화하면 모든 트래픽은 VPC 내부의 서브넷 간 그리고 컨트롤 플레인이 돌고 있는 EKS 소유한 내부 VPC 서브넷 간의 통신을 가능케 하는 ENI를 거치게 됩니다.
 
- 만약 가능하지 않을 경우에는 퍼블릭 엔드포인트에 접근할 수 있는 IP 주소를 제어하는 방법이 있습니다.
예를 들어서 지점 사무실 혹은 기업망이 있고, 클러스터에 접근할 필요가 있을 경우 해당 CIDR 퍼블릭 엔드포인트를 제한할 수 있습니다.
 
- 만약, 보안상 이유로 인바운드 / 아웃바운드 인터넷 연결이 불필요할 경우 클러스터를 프라이빗 서브넷에서만 구동할 수 있습니다. 이 경우 S3, ECR 등을 사용하기 위해서 AWS 프라이빗 링크를 설치하셔야 합니다.
 

워커 노드를 안전하게 구동하는 법

그렇다면, 워커 노드는 어떻게 안전하게 구동시킬 수 있을까요?
가장 쉬운 방법은 아마도 컨테이너를 위해서 만들어진 OS를 사용하는 방법입니다.
 
- AWS Bottlerocket이 있습니다.
AWS가 지원하는 호스트 OS로, 컨테이너를 구동하는데 최적화 되어 있으며, 오픈소스 프로젝트로 
쿠버네티스의 각 버전에 Bottlerocket에 최적화된 EKS 버전들을 많이 퍼블리싱합니다.
또한 Bottlerocket을 지원하는 관리형 노드 그룹 역시 출시되어 있습니다.
 
- 워커 노드를 불변으로 취급합니다.
컨테이너가 불변한 성격을 띄고 있고, 컨테이너가 퍼블리싱되면 워커 노드 역시 동일하게 취급합니다.
그렇기 때문에 만약 워커노드의 AMI 버전을 업데이트하기 위해서는 워커노드를 변경하기보다 현재 구성을 내리고, 업데이트 AMI 버전을 지닌 새로운 EC2를 올리는 방법을 진행합니다.
(관리형 노드그룹은 자동화 된 프로세스이기 때문에 신경 쓰실 필요가 없습니다.)
 
- SSH 대신에 AWS 시스템 매니저를 사용합니다.
EKS 최적화된 아마존 리눅스 AMI와 Bottlerocket AMI는 SSM을 기본적으로 내장하고 있습니다.
22번 포트를 열거나 인스턴스에 SSH 키를 활성화 할 필요가 없습니다.
만약 디버깅을 이유로 액세스해야 한다면, SSM을 사용하면 됩니다.
 
- EKS CIS 벤치마크를 사용합니다.
EKS는 커스텀 AMI를 지원합니다.
우리는 커스텀 AMI를 배포하기보다 빌드 스크립트 역시 오픈 소스로 사용합니다.
많은 고객사들이 요구사항 혹은 커스텀 AMI를 만드는 것을 규정 준수의 이유로 필요로 합니다. 
만약 그럴 경우, EKS CIS 벤치마크를 사용하는 것을 권장합니다.
만든 커스텀 AMI가 모범 사례를 따르고 있는지 검증할 수 있습니다.
 
- AWS Fargate를 사용합니다.
만약 위의 내용들을 적용하고 싶은 의향이 없으실 경우, 특별한 보안 혹은 규정 준수를 지킬 의무가 없을 경우에는
해당 내용에 대한 책임을 Fargate에게 부여하면 됩니다.
EKS는 AWS 서버리스 컨테이너 엔진인 Fargate를 지원합니다.