쿠버네티스 개념과 보안 위협

개요

과거 IT 환경에서는 여러 서비스를 구축하기 위해 여러 대의 물리 서버가 필요했다. 하지만 가상화(VM) 기술의 도입으로 단일 서버에서 여러 개의 가상 서버를 구축할 수 있게 되었고, 현재는 이보다 더 발전하여, 단일 서버의 호스트 자원을 여러 서비스 간에 나눠 사용하고, 애플리케이션(APP) 형태로 구축 및 배포할 수 있는 컨테이너 기술이 널리 사용되고 있다.

 

컨테이너는 애플리케이션과 그 종속성을 함께 패키징하여, 다양한 컴퓨팅 환경에서 일관되게 실행하는 이식성을 보장하기 때문에 서비스 구축 및 배포가 훨씬 간소화되고, 리소스 활용도가 향상된다. 또한, 컨테이너화는 더 빠른 배포, 더 쉬운 확장성, 더 나은 격리 및 보안 등의 이점을 제공한다.

 

이러한 배경 속에서 단일 컨테이너를 관리하는 도커가 등장했고, 다수의 컨테이너를 관리하는데 좀 더 특화된 쿠버네티스가 등장했다. 쿠버네티스는 컨테이너화된 애플리케이션의 배치, 확장 및 관리를 자동화하는 강력한 플랫폼으로, 오늘날 많은 조직들이 이를 채택하여 IT 인프라의 운영 효율성과 유연성을 크게 향상시키고 있다.

 

필자는 금융권 환경에서 업무를 수행하고 있어 기술 발전이 업무환경에 적용되는 속도는 일반 사기업에 비해 더디지만 현재 차세대로 구축되는 서비스들은 점차적으로 쿠버네티스를 도입하고 있다. 따라서 쿠버네티스의 핵심 개념과 아키텍처를 탐구하고, 쿠버네티스에서 발생할 수 있는 보안 위협 및 대응 전략에 대해 알아보자.

 

 

쿠버네티스란

쿠버네티스(Kubernetes, K8s)는 컨테이너화된 애플리케이션의 자동 배포(Deploy), 확장/축소(스케일링), 로드밸런싱 등을 제공하는 관리 플랫폼이다. 2014년 최초 구글에 의해 처음 발표되었으나 현재는 리눅스 재단에 의해 관리되고 있다. 구글의 클라우드 서비스를 구동하는 기술이기도 하며, 구글은 내부 플랫폼인 Borg를 통해 일주일에 20억 개 이상의 컨테이너 배포를 생성하고 있다.

 

※ TMI: 쿠버네티스에서 기존 컨테이너를 실행하는 컨테이너 런타임으로 도커가 많이 사용되었으나 호환성 문제로 인해 2020년 12월 8일,  쿠버네티스는 버전 1.20버전 이후 도커를 컨테이너 런타임으로 사용하는 것을 중지한다고 발표했다. 따라서 현재는 컨테이너 런타임으로 CRI-O, Containerd가 주로 사용되며, 도커 대신의 이미지 빌드 도구로는 podman 등을 사용할 수 있다.

 

그리스어로 배의 키잡이(조타수)를 뜻하는 쿠버네티스

 

쿠버네티스의 기본 아키텍처와 구성요소는 다음과 같다. 간단하게 설명하자면 마스터 노드(관리자)가 워커노드(가상 또는 물리 서버)에 Pod(서비스 컨테이너)를 배포 및 관리하는 플랫폼이라고 말할 수 있다.

쿠버네티스 구성요소	설명
API server	Control Plane의 핵심으로 클러스터 관리 명령, 데이터 검증 및 저장, 외부 접근 지점 제공
Cloud controller manager	클라우드 환경(AWS, Azure 등)에서 실행되는 경우 클라우드 공급자(CSP)와 상호 작용
Controller manager	클러스터를 원하는 상태를 관리하는 컨트롤러 관리(Pod 복제본 관리, 노드 상태 감시 등)
etcd	모든 클러스터 데이터를 저장하는 Key-Value 저장소(상태, 구성, 메타데이터, Secret 등 저장)
kubelet	각 노드에서 실행되는 Agent로 API Server의 명령을 받아 Pod의 생성, 업데이트 삭제 등 관리
kube-proxy	각 노드에서 실행되는 네트워크 프록시로 네트워크 규칙에 따라 Pod의 내/외부 통신을 관리
Scheduler	노드가 배정되지 않은 새로 생성된 Pod를 감지하고, 실행할 노드를 선택
Control Plane	마스터 노드이며, 클러스터에 관한 전반적인 결정(스케줄링, 배포 등)을 관리
Node	동작 중인 Pod를 유지시키고, 쿠버네티스 런타임(컨테이너 실행, CRI-O/Containerd) 환경 제공

 

쿠버네티스 기능 및 역할

쿠버네티스는 분산 시스템을 탄력적으로 실행하기 위한 프레임 워크를 제공하며, 애플리케이션의 확장과 장애 조치를 처리하고, 배포 패턴 등을 제공하는 역할을 수행한다.

쿠버네티스 기능	설명
컨테이너 오케스트레이션	여러 호스트에서 컨테이너를 자동으로 배포, 스케줄링 및 운영하며, 이를 통해 애플리케이션의 가용성과 확장성을 보장
자동화된 롤아웃과 롤백	애플리케이션 업데이트를 자동으로 관리하고, 필요한 경우 이전 버전으로 롤백할 수 있으며, 이를 통해 지속적인 배포와 통합이 가능
로드 밸런싱 및 서비스 디스커버리	네트워크 트래픽을 자동으로 로드 밸런싱하고, 서비스 디스커버리를 통해 컨테이너 간의 통신을 제공
스토리지 오케스트레이션	자동으로 스토리지 시스템을 마운트하고 관리하여, 애플리케이션이 필요로 하는 스토리지를 제공
자동화된 빈 패킹 (bin packing)	CPU와 메모리와 같은 자원을 고려하여 컨테이너를 최적의 서버에 배치
자동 스케일링	트래픽 부하에 따라 애플리케이션을 자동으로 스케일링하며, 이를 통해 리소스 사용을 최적화
자동화된 복구 (self-healing)	실패한 컨테이너를 재시작하고, 정의된 상태에 맞지 않는 컨테이너를 교체하며, 사용할 수 없는 노드에서 컨테이너를 제거
시크릿과 구성 관리	암호, OAuth 토큰, SSH 키와 같은 민감한 정보를 저장하고 관리

 

레거시 시스템과 쿠버네티스 비교

구분	레거시 시스템	쿠버네티스
아키텍처	대부분 중앙 집중식 서버, 네트워크 구조이며,명확한 네트워크 경계와 내/외부 영역 생성	컨테이너와 마이크로 서비스 기반 분산 구조이며, 각 서비스가 독립접이며, 동적 확장이 가능
보안 위협 구간	- 경계보안: 네트워크 경계 위협(WAF, IPS) - 내부보안: 경계 내부 시스템 보안 위협	- API 서버: 클러스터 전체 관리서버 보안 - Pod 간 통신: 파드와 서비스 간 통신 네트워크 보안 - 컨테이너: 격리되었지만 취약점을 통해 탈출 가능 - etcd: 클러스터의 모든 중요정보 저장된 DB
변경 관리	레거시 시스템은 변경 관리가 느리고 복잡하여 보안 업데이트 및 패치 적용이 지연	쿠버네티스의 동적 환경은 보안 관리를 복잡하게 하지만, 자동화된 업데이트와 패치 관리가 용이

 

쿠버네티스 보안 위협 및 대응 전략

보안 위협	설명	대응 전략	비고
API 서버 노출	쿠버네티스 API 서버는 관리의 핵심이므로 공격 대상이 될 수 있음	API 서버에 대한 접근을 엄격하게 제어	RBAC, OpenID Connect, OAuth2, Network Policies
etcd 데이터 노출	중요한 클러스터 데이터를 저장하는 etcd는 민감한 정보 노출 위험 있음	etcd 데이터를 암호화하고, 접근을 제한	etcd 암호화, RBAC, TLS 인증서
컨테이너 취약성	컨테이너 이미지에 존재하는 취약점은 전체 클러스터 위험 초래 가능	컨테이너 이미지 정기적 스캔, 신뢰할 수 있는 이미지 소스 사용	Clair, Docker Trusted Registry, Quay
네트워크 공격	클러스터 내부/외부 네트워크 트래픽 공격 노출 가능	네트워크 폴리시 적용 및 네트워크 암호화	Calico, Cilium, Weave Net
마스터 노드 보안 위협	클러스터 관리와 스케줄링 담당, 공격자의 주요 타겟	마스터 노드의 보안 강화, 네트워크 접근 제한	방화벽, IDS/IPS 시스템, SSH 접근 제한
컨테이너 이스케이프	컨테이너가 호스트 머신 접근/영향 가능한 보안 취약점	컨테이너 격리, 런타임 및 호스트 OS 취약점 패치	gVisor, Kata Containers, SELinux, AppArmor
서비스 계정 남용	과도한 권한 가진 서비스 계정은 클러스터 제어권 제공 가능	서비스 계정의 권한 최소화 및 필요시만 사용	RBAC, Pod Security Policies
로깅 및 모니터링 부족	적절한 로깅 및 모니터링 없으면 보안 사고 조기 발견 및 대응 어려움	포괄적 로깅 및 모니터링 시스템 구축	ELK 스택(Elasticsearch, Logstash, Kibana), Prometheus, Grafana
오래된 컴포넌트 사용	오래된 소프트웨어 컴포넌트는 알려진 취약점 포함 가능	클러스터 및 컴포넌트 최신 상태 유지 및 정기적 업데이트	자동 업데이트 도구, Kubernetes 최신 버전 사용
노드 간 통신 취약점	클러스터 내 노드 간 통신이 암호화되지 않으면 데이터 유출/변조 위험	내부 통신에 TLS 암호화 적용 및 트래픽 검증	IPsec, TLS/SSL

 

쿠버네티스 오픈소스 취약점 점검도구 

취약점 점검 도구	설명	URL
Kube Hunter	쿠버네티스 클러스터를 스캔하여 취약점을 찾아내는 도구로, 원격, 인터페이스, 네트워크 등 다양한 표준 스캐닝 옵션을 제공	https://github.com/aquasecurity/kube-hunter
Kube Bench	쿠버네티스 배포가 CIS (인터넷 보안 센터) 벤치마크를 준수하는지 확인하는 도구로, 여러 버전의 쿠버네티스를 지원하며 발견된 오류에 대한 해결책을 제공	https://github.com/aquasecurity/kube-bench
Checkov	쿠버네티스 및 다른 인프라 코드 언어에 대한 빌드 시 클라우드 미스컨피그레이션을 방지하는 보안 도구로, 500개 이상의 내장 보안 정책을 포함	https://www.checkov.io/
MKIT	쿠버네티스 클러스터 및 리소스의 주요 보안 위험을 신속하게 식별하는 도구로, 웹 인터페이스를 통해 미스컨피그레이션을 평가	https://github.com/darkbitio/mkit
Kubei	쿠버네티스 클러스터에서 사용하는 모든 이미지를 스캔하며 CIS Docker 벤치마크를 포함하고, 취약점 시각화를 위한 GUI를 제공	https://github.com/Portshift/kubei
Kube Scan	클러스터의 워크로드를 평가하고 위험 점수 및 세부 사항을 제공하는 컨테이너 스캐너	https://github.com/octarinesec/kube-scan
Kubeaudit	쿠버네티스 클러스터의 보안 미스컨피그레이션을 식별하고 해결 방법을 제시하는 감사 도구	https://github.com/Shopify/kubeaudit
Kubesec	쿠버네티스 리소스의 보안 위험을 분석하고, 구성 및 매니페스트 파일을 검증하는 도구로, 컨테이너 이미지, 바이너리 패키지 또는 kubectl 플러그인으로 설치가능	https://github.com/controlplaneio/kubesec

 

쿠버네티스 보안 가이드 참고

1. [쿠버네티스 공식] 보안 체크리스트: https://kubernetes.io/docs/concepts/security/security-checklist/

Security Checklist

2. [NSA & CISA] Kubernetes Hardening Guide(2022/08/30): https://www.cisa.gov/news-events/alerts/2022/03/15/updated-kubernetes-hardening-guide

Updated: Kubernetes Hardening Guide | CISA

3. [SK 쉴더스] 클라우드 보안 가이드(컨테이너 보안)(2019/06/24): https://10th-doctrine.tistory.com/119

[SK인포섹] 클라우드 보안 가이드 - Docker, Kubernetes