기술관리형 Kubernetes(EKS)도 보안 점검이 필요할까요?

지난 게시글에서는 Kubernetes와 Amazon EKS의 개념에 대해 알아보았습니다

Amazon EKS는 AWS에서 제공하는 관리형 Kubernetes 서비스로 클러스터 운영의 편의성을 제공하지만 보안까지 AWS 책임지지 않습니다.

AWS가 서비스를 제공하며 Control Plane은 AWS가 관리하지만 다른 IAM 권한, Kubernetes 설정, 컨테이너 이미지, 네트워크 정책 등에 대해 직접 관리가 필요합니다.

1. EKS는 왜 서버 점검과 다를까요?

일반적인 EC2 보안 점검은 운영체제에 직접 접속하여 계정 관리, 패스워드 정책, 서비스 설정, 파일 권한, 로그 등을 확인합니다.

반면 Amazon EKS는 관리형 Kubernetes 서비스이기 때문에 점검 방식이 달라집니다.

Control Plane에 대해서는 AWS가 관리하며, 고객은 일반적으로 해당 영역에 직접 접근할 수 없습니다. 또한 Fargate 환경에서는 Worker Node 역시 직접 접속하지 않는 경우가 많습니다.

따라서 EKS 보안 점검은 운영체제보다 클러스터 설정, 접근 권한, 네트워크 정책, 컨테이너 이미지, 감사 로그 등 Kubernetes 플랫폼 전반의 보안 설정을 확인하는 것이 핵심입니다.

2. 실제 EKS 보안 점검은 어떻게 수행할까요?

실제 프로젝트에서는 보안 컨설턴트가 Worker Node에 접속하여 점검하는 경우보다 고객이 제공한 설정 정보와 클러스터 정보를 기반으로 보안 상태를 분석하는 경우가 대부분입니다.

일반적으로 다음과 같은 자료를 수집하여 점검을 수행합니다.

3. 보안 컨설턴트는 어떤 항목을 확인할까요?

EKS 보안 점검에서는 운영체제가 아닌 Kubernetes 플랫폼과 AWS 설정을 중심으로 확인합니다.

※ 본 표는 대표적인 점검 항목을 정리한 것으로 고객 환경 및 Kubernetes 구성에 따라 추가적인 보안 설정과 운영 정책을 함께 확인합니다. 

4. 마무리

Amazon EKS는 관리형 Kubernetes 서비스이지만 보안 점검이 불필요한 것은 아닙니다.

Control Plane은 AWS가 관리하지만, IAM 권한, Kubernetes 리소스, 컨테이너 이미지, 네트워크 정책 등 고객이 직접 관리해야하고 잘못된 설정은 서비스 장애나 보안 사고로 이어질 수 있으므로 주기적인 점검과 운영 정책 관리가 필요합니다.

실제 보안 컨설팅에서는 운영체제에 직접 접속하여 점검하기보다 AWS 관리콘솔, AWS CLI, kubectl, Amazon ECR 등의 정보를 종합적으로 분석하여 보안 상태를 확인합니다.

관리형 서비스는 운영의 편의성을 제공하지만, 보안까지 모두 관리하지 않으므로 지속적으로 점검하는 것이 안전한 EKS 운영의 핵심이라고 할 수 있습니다.

※ 핵심 체크포인트

• EKS는 운영체제가 아닌 Kubernetes 플랫폼 중심으로 보안 점검을 수행합니다.
• Worker Node에 직접 접속하기보다 AWS 관리콘솔, AWS CLI, kubectl 등을 활용하여 설정을 확인합니다.
• IAM 및 Kubernetes RBAC은 최소 권한 원칙을 적용해야 합니다.
• API Endpoint 접근 제어, Control Plane Logging, Kubernetes 버전 등 클러스터 설정을 주기적으로 점검해야 합니다.
• Pod Security, ServiceAccount, IRSA, NetworkPolicy 등 Kubernetes 보안 설정을 확인해야 합니다.
• Amazon ECR 및 Amazon Inspector를 활용하여 컨테이너 이미지 취약점을 지속적으로 관리해야 합니다.

신동찬 | sdc@cela.kr