기술사 학습노트 | imt-log

기술사 학습노트 › 클라우드 / 보안 › 클라우드 네이티브 보안

CLOUD SECURITY · 정보관리기술사 / 컴퓨터시스템응용기술사

쿠버네티스(Kubernetes) 보안 아키텍처 완벽 해부: API 접근 통제와 4C 방어 모델

경계 보안(Perimeter Security)이 무너진 클라우드 네이티브 환경에서, 쿠버네티스 API 서버를 방어하기 위한 3단계 통제 메커니즘(인증, 인가, 어드미션 컨트롤)과 OPA Gatekeeper를 활용한 동적 정책 통제, 그리고 심층 방어를 위한 4C 모델을 심층 분석한다.

정보관리기술사 컴퓨터시스템응용기술사 쿠버네티스보안 4C모델 RBAC AdmissionControl NetworkPolicy OPA 제로트러스트 DevSecOps

Ⅰ. 클라우드 네이티브 보안의 핵심, 쿠버네티스 위협 모델과 4C

가. 동적 인프라 환경의 새로운 보안 위협

과거의 보안은 방화벽을 세우고 내부망을 신뢰하는 경계 보안(Perimeter Security) 방식이었다. 그러나 쿠버네티스(K8s) 환경에서는 수많은 파드(Pod)가 1초에도 수백 번씩 생성과 소멸을 반복하고, 컨테이너 이미지는 외부 레지스트리에서 다운로드되며, 모든 통신이 오버레이 네트워크상에서 이루어진다. 이로 인해 컨테이너 탈출(Container Breakout), API 서버 탈취, 악성 이미지 배포와 같은 새로운 형태의 보안 위협이 대두되었다.

나. 심층 방어(Defense in Depth) 전략: 4C 보안 모델

쿠버네티스 공식 문서에서 제시하는 클라우드 네이티브 보안의 다계층 방어 모델이다. 바깥쪽 계층이 무너지더라도 안쪽 계층이 방어하는 제로 트러스트(Zero Trust) 철학을 기반으로 한다.

• Cloud (클라우드/인프라): K8s가 구동되는 물리/가상 서버, 네트워크 보안 그룹(VPC), IAM 권한 등 CSP(AWS, GCP 등) 레벨의 인프라 접근 통제이다.
• Cluster (클러스터): 쿠버네티스의 심장인 API 서버에 대한 접근 통제, etcd 암호화, RBAC 권한 관리 및 워커 노드 간의 통신 보안이다.
• Container (컨테이너): 파드(Pod) 레벨의 보안. 불필요한 특권(Privileged) 권한 제거, 이미지 취약점 스캐닝, 런타임 보안(Falco) 모니터링이다.
• Code (코드): 개발 파이프라인 단계. 정적 코드 분석(SAST), 의존성 스캐닝, TLS/mTLS를 통한 암호화 통신 적용이다.

Ⅱ. 쿠버네티스 API 서버 접근 통제(Access Control) 아키텍처

가. K8s API 요청 처리 파이프라인 시각화

사용자(kubectl)나 파드 내부의 애플리케이션(Service Account)이 K8s 리소스를 조작하기 위해 API 서버에 요청을 보내면, 인증(AuthN) ➔ 인가(AuthZ) ➔ 어드미션 컨트롤(Admission Control)이라는 엄격한 3단계 수문장(Gatekeeper)을 반드시 통과해야만 etcd(상태 저장소)에 기록된다.

나. 3단계 핵심 제어 컴포넌트 분석 (3단표)

통제 단계	명칭 및 주체	핵심 기능 및 보안 메커니즘
Step 1. 인증 (Authentication)	"당신은 누구인가?" (인증서, 토큰)	요청을 보낸 주체의 신원(Identity)을 확인한다. 클러스터 관리자는 주로 X.509 클라이언트 인증서나 OIDC(SSO)를 사용하며, 파드 내부의 애플리케이션은 API 서버와 통신하기 위해 Service Account Token(JWT)을 사용한다.
Step 2. 인가 (Authorization)	"어떤 권한이 있는가?" (RBAC 모델)	인증된 주체가 특정 리소스(Pod, Secret 등)에 대해 특정 행동(Get, Create, Delete)을 할 권한이 있는지 검사한다. 쿠버네티스의 표준 인가 방식은 RBAC(Role-Based Access Control)이며, Role과 RoleBinding을 통해 최소 권한의 원칙을 강제한다.
Step 3. 어드미션 컨트롤 (Admission Control)	"정책에 위배되지 않는가?" (Mutating, Validating)	요청이 인가되었더라도, 클러스터 전체의 보안 정책(예: "모든 이미지는 사내 레지스트리에서만 가져와야 함", "루트 권한 실행 금지")에 위배되는지 최종 검사한다. 필요시 요청의 내용을 수정(Mutating)하거나 반려(Validating)하는 가장 강력한 보안 관문이다.

Ⅲ. 심층 분석 1: 권한 인가(RBAC)와 네트워크 격리(Network Policy)

가. RBAC (역할 기반 접근 통제) 아키텍처

특정 사용자에게 직접 권한을 부여하지 않고, '역할(Role)'을 생성하여 권한을 정의한 뒤, 이를 사용자(또는 Service Account)와 묶어주는(Binding) 구조이다. 특정 네임스페이스(Namespace)에 국한된 Role / RoleBinding과 클러스터 전체에 적용되는 ClusterRole / ClusterRoleBinding으로 나뉜다. 이를 통해 퇴사자 발생 시 권한 회수가 용이해지고, 컴플라이언스를 충족할 수 있다.

나. 네트워크 정책 (Network Policy): 마이크로 세그멘테이션

기본적으로 쿠버네티스 클러스터 내부의 모든 파드(Pod)는 서로 격리 없이 통신이 가능합니다(Default Allow All). 이는 해커가 하나의 파드를 장악하면 내부망을 횡적 이동(Lateral Movement)하며 다른 파드를 해킹할 수 있다는 의미입니다.
이를 방지하기 위해 네트워크 정책(Network Policy)을 적용하여 Default Deny(모든 통신 차단) 상태로 만들고, CNI(Calico, Cilium 등) 플러그인을 통해 특정 라벨(Label)을 가진 파드끼리만 통신할 수 있도록 L3/L4 수준의 마이크로 세그멘테이션(Micro-segmentation) 방어벽을 구축해야 합니다.

Ⅳ. 심층 분석 2: 파드 보안(PSS)과 OPA 기반 동적 정책 검증

가. Pod Security Standards (PSS)와 PSA

과거에 사용되던 PodSecurityPolicy(PSP)가 폐기되고, K8s 1.25부터는 Pod Security Admission(PSA)가 내장되었다. 이는 파드의 보안 수준을 세 가지 표준(Privileged, Baseline, Restricted)으로 나누어 네임스페이스 단위로 강제한다. 예를 들어 Restricted 프로필을 적용하면, 호스트 네트워크 사용 금지, 루트(root) 권한 실행 금지 등 가장 엄격한 컨테이너 보안 정책이 자동으로 검증된다.

나. Policy as Code: OPA (Open Policy Agent) Gatekeeper

기본적인 PSA만으로는 "사내 도커 레지스트리 주소가 아니면 파드 생성 거부", "특정 라벨(Label)이 누락된 배포 차단" 등 기업의 복잡한 비즈니스 보안 정책을 커버할 수 없다. 이를 위해 Validating Admission Webhook 단계에 OPA Gatekeeper를 연동한다.

• Rego 언어: 인프라 보안 정책을 선언적인 코드(Policy as Code)로 작성할 수 있게 해주는 OPA의 전용 쿼리 언어이다.
• 동적 검사: 개발자가 kubectl apply를 실행할 때마다 OPA 엔진이 실시간으로 YAML 파일을 가로채어 Rego 정책과 비교 분석하고, 위배 시 배포를 원천 차단하여 인프라의 컴플라이언스 준수를 강제한다.

Ⅴ. 클라우드 네이티브의 미래: 제로 트러스트와 DevSecOps 연계

가. 서비스 매시(Service Mesh)를 통한 제로 트러스트 구현

쿠버네티스 내부 통신은 기본적으로 평문(HTTP)으로 전송되어 스니핑(Sniffing)에 취약하다. Istio와 같은 서비스 매시 아키텍처를 도입하면, 각 파드 옆에 사이드카(Sidecar) 프록시를 배치하여 파드 간의 모든 통신을 상호 TLS(mTLS)로 자동 암호화하고, L7(애플리케이션) 계층의 강력한 라우팅 통제 및 가시성을 확보하여 내부 통신조차 신뢰하지 않는 제로 트러스트 아키텍처를 완성할 수 있다.

나. 파이프라인으로의 보안 내재화: DevSecOps

운영 환경(K8s)에서의 방어뿐만 아니라, CI/CD 파이프라인의 좌측으로 보안을 이동시키는 시프트 레프트(Shift-Left) 전략이 필수적이다. 소스 코드 커밋 단계에서 SAST 도구(SonarQube)로 점검하고, 컨테이너 빌드 단계에서 Trivy, Clair 등의 도구로 이미지의 CVE 취약점을 스캐닝하며, 운영 중인 런타임 환경에서는 Falco를 통해 비정상적인 시스템 콜(System Call)을 탐지하는 End-to-End DevSecOps 생태계를 구축해야 한다.

블로그: 기술사 학습노트 · imt-log.tistory.com

← [클라우드 / 보안] 목록