[발표자료 다운로드] 쿠버네티스 보안 경계 설계 — 기본값 리스크를 차단하는 기준

이 자료는 CNCF Korea 쿠버네티스 보안(Kubernetes Security)과 거버넌스 과정 1편의 발표 슬라이드다. 무엇을 막고 무엇을 열지 정하는 기준을 4C 모델, NIST SP 800-190, 그리고 네트워크·격리·API 세 층의 기본값 순서로 정리했다.

결론은 하나다. 아무것도 설정하지 않은 클러스터에서는 모든 파드가 서로 닿고, 특권 실행이 막혀 있지 않으며, 파드마다 API 토큰이 자동으로 들어간다. 쿠버네티스 보안 설계는 이 세 기본값을 하나씩 닫는 작업이고, 어떤 순서로 닫을지는 격리 수준과 Namespace 이름 규칙이 정한다.

아래 버튼을 누르면 슬라이드 10쪽을 PDF 한 파일로 받을 수 있다.

슬라이드만으로는 설명의 흐름이 끊기는 대목이 있다. 같은 내용을 발표자가 순서대로 풀어 설명한 영상을 함께 공개했다.

발표 영상은 슬라이드 순서 그대로 4C 모델부터 Namespace 이름 규칙까지 이어진다.

영상에서 다루는 순서는 다음과 같다.

• 클라우드·클러스터·컨테이너·코드로 나눈 4C 모델
• NIST SP 800-190 이 정리한 컨테이너 위험 목록
• 네트워크·격리·API 세 층의 기본값
• 기본 허용을 선별 허용으로 바꾸는 통신 제어
• 격리 수준 세 단계와 그 비용
• 서비스와 환경을 함께 쓰는 Namespace 이름 규칙

클라우드 네이티브 보안 전반을 먼저 훑고 싶다면 클라우드 네이티브 보안 완벽 가이드 — 4C 모델과 DevSecOps 적용법에서 시작하면 된다. 이 발표자료는 그 가이드의 4C 모델을 클러스터 설정 수준으로 한 단계 더 내려가 다룬다. 쿠버네티스 보안을 층별로 먼저 이해하고 오면 슬라이드가 훨씬 빠르게 읽힌다. 경계를 나눈 다음 그 안에서 누구에게 어디까지 권한을 줄지는 2편 쿠버네티스 접근 제어 — 권한 과다를 막는 위임과 감사 기준에서 이어 다룬다.

쿠버네티스 보안을 처음 설계하는 인프라팀이 실제로 묻는 질문을 기준으로 슬라이드를 배치했다.

1. 클러스터 보안은 어느 층부터 점검해야 하는가
2. 컨테이너 환경에서 무엇이 위험한지 점검 목록은 어디서 가져오는가
3. 아무 설정도 하지 않은 클러스터는 어디가 열려 있는가
4. 네임스페이스만으로 격리가 충분한 경우와 부족한 경우는 어떻게 가르는가
5. Namespace 이름 규칙이 왜 보안 통제의 범위를 정하는가

질문마다 답이 되는 슬라이드를 아래 순서대로 붙였다. 슬라이드 이미지를 누르면 크게 볼 수 있다.

쿠버네티스 공식 문서는 클라우드 네이티브 보안을 Cloud, Cluster, Container, Code 네 층으로 나눠 설명한다. 바깥 층이 안쪽 층을 감싸는 구조이고, 이 구조에서 세 가지 원칙이 나온다.

▲ (1) 바깥 층이 안쪽 층의 전제 (2) 바깥에서 안쪽 순으로 강화 (3) 층별 책임 주체 분리 (발표자료 4쪽)

첫째, 안쪽 층의 보안은 바깥 층이 안전하다는 전제 위에서만 성립한다. 클라우드 계정이 탈취되면 코드 수준의 입력 검증이나 의존성 점검은 의미를 잃는다. 집 안 금고를 아무리 튼튼히 만들어도 현관문이 열려 있으면 소용이 없는 것과 같다.

둘째, 그래서 강화 순서가 정해진다. 클라우드 계정과 네트워크에서 시작해 클러스터 설정, 컨테이너 이미지와 런타임, 마지막으로 애플리케이션 코드 순으로 내려간다. 코드만 잘 쓰면 안전하다는 접근이 위험한 이유다.

셋째, 층마다 통제 수단과 책임 주체가 다르다. 쿠버네티스 보안은 한 팀의 과제가 아니라 조직 전체가 함께 봐야 하는 모델이다.

4C 모델이 어디를 지킬지 나누는 지도라면, 미국 표준기술연구소(NIST)가 낸 NIST SP 800-190 Application Container Security Guide 는 그 층에서 무엇을 점검할지 적어 둔 목록이다. 발표자료는 이 문서의 위험 분류 가운데 이미지·레지스트리·오케스트레이터·컨테이너 네 가지를 추리고, 분류마다 대표 위험 세 가지씩 모두 12개를 골랐다. 원문에는 호스트 OS 위험이 별도 분류로 하나 더 있다.

▲ (1) 이미지·레지스트리·오케스트레이터·컨테이너 네 축 (2) 각 축의 대표 위험 세 가지 (3) 4C 모델과 짝을 이루는 점검 체크리스트 (발표자료 5쪽)

• 이미지 — 알려진 취약점, 이미지에 박혀 들어간 기밀 정보, 신뢰할 수 없는 이미지 사용
• 레지스트리 — 암호화되지 않은 통신, 취약한 이미지의 장기 보관, 미흡한 인증과 승인
• 오케스트레이터 — 클러스터 사용자에게 준 과도한 권한, 기밀 수준이 다른 트래픽의 혼재, 노드 자체의 취약점
• 컨테이너 — 런타임 취약점으로 인한 중단, 컨테이너에 부여된 과도한 권한, 검사를 거치지 않은 컨테이너 배포

건강검진 항목표처럼 쓰면 된다. 4C 모델로 층을 나누고, 층마다 이 목록의 해당 분류를 대조하면 빠진 점검 항목이 드러난다. 쿠버네티스 보안 감사를 준비할 때도 이 12개 항목을 질문지의 뼈대로 쓸 수 있다.

공공 부문 사업이라면 국내 기준도 함께 대조한다. 국가정보원의 국가 클라우드 컴퓨팅 보안 가이드라인은 컨테이너 환경을 관리 노드(오케스트레이터)·컨테이너 노드·컨테이너 레지스트리 세 계층으로 나누고, 13개 보안기준과 30개 세부 점검항목을 제시한다. 공공 쿠버네티스 사업의 보안 요구사항은 대부분 이 점검항목에서 나오므로, NIST SP 800-190 목록과 나란히 놓고 겹치는 항목과 빠진 항목을 표로 정리해 두면 제안과 검수 대응이 함께 빨라진다.

점검항목 가운데 감사, 패치와 설정 점검, 런타임 탐지와 모니터링은 구축할 때 한 번 확인하고 끝나는 항목이 아니다. 운영으로 넘어간 뒤에도 정기점검 목록에 남아야 하므로 운영 절차서에 처음부터 적어 둔다.

보안 경계를 실제 클러스터 설정으로 옮기면 네트워크, 격리, API 세 층이 된다. 중요한 점은 한 층만 걸면 나머지 두 층이 그대로 열린다는 것이다. 창문만 잠그고 뒷문을 열어 두면 잠근 의미가 없다.

▲ 한 층만 걸면 나머지 두 층이 그대로 열림 (발표자료 6쪽)

세 층의 기본값은 다음과 같다.

그래서 이번 파트의 출발점은 새 도구를 들이는 일이 아니라 기본값을 확인하는 일이다. 쿠버네티스 보안 점검표의 첫 줄은 세 기본값을 그대로 두고 있는지 여부다. 접근 제어와 감사는 이 과정의 2편에서, 컨테이너 실행 권한 통제는 3편에서 이어서 다룬다.

쿠버네티스에서 파드 사이 통신은 기본적으로 모두 허용된다. 격리는 선언해야만 생긴다. 어떤 파드를 대상으로 하는 NetworkPolicy 가 하나라도 생기면, 그 파드는 정책에 적힌 방향에 대해 허용 목록 방식으로 바뀐다. 정책이 붙기 전에는 모두 열려 있고, 붙는 순간 허용한 통신만 남는다.

▲ 아무 설정도 없으면 모든 파드가 서로 닿음 (발표자료 7쪽)

가장 먼저 거는 정책은 네임스페이스 단위의 기본 차단이다. 아래 정책은 payment-prod 네임스페이스의 모든 파드로 들어오는 통신을 막는다. 필요한 통신은 별도 정책으로 하나씩 연다.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
  namespace: payment-prod
spec:
  podSelector: 
  policyTypes:
    - Ingress

주의할 점이 하나 있다. 네트워크 플러그인이 NetworkPolicy 를 지원하지 않으면 만들어 둔 정책은 오류 없이 무시된다. 막힌 줄 알았는데 열려 있는 상태가 된다. 소화기를 벽에 걸어 뒀다고 불이 꺼지지는 않는 것처럼, 정책 파일이 있다는 사실은 차단의 증거가 아니다. 막혀야 할 위치에서 실제로 호출해 확인한다.

kubectl -n default run np-probe --rm -it --restart=Never \
  --image=busybox:1.36 -- wget -qO- -T 3 http://api.payment-prod.svc.cluster.local

응답이 오면 정책이 동작하지 않는 것이다. 시간 초과가 나야 정상이다. 정책을 배포한 뒤에는 이 확인을 배포 절차의 마지막 단계로 넣어 두면 플러그인 교체나 클러스터 이전 때 조용히 열리는 일을 막을 수 있다. 쿠버네티스 보안 점검에서 네트워크 층은 이렇게 실제 호출 결과로만 통과 여부를 판정한다.

격리 수준은 세 단계로 나뉜다. 아래로 갈수록 강하지만 그만큼 비싸다.

▲ 논리 격리와 물리 격리의 강도가 다름 (발표자료 8쪽)

고르는 원칙은 하나다. 가르고 싶은 요구 수준을 먼저 문장으로 적고, 그 수준을 만족하는 가장 낮은 비용의 격리를 고른다. 사무실에 칸막이를 칠지, 방을 따로 낼지, 건물을 나눌지 고르는 것과 같다.

네임스페이스만으로 부족해지는 지점도 분명하다. 네임스페이스는 노드와 커널을 여전히 함께 쓰고, 컨트롤 플레인 장애는 네임스페이스 경계를 넘어 번진다. 같은 건물 안 칸막이라서 건물에 정전이 나면 모든 칸이 함께 어두워진다.

대부분의 사내 요구는 네임스페이스로 충분하다. 팀이나 환경을 가르고 자원 다툼을 막는 목적이라면 여기서 끝난다. 쿠버네티스 보안 비용은 결국 이 격리 단계 선택에서 가장 크게 갈린다. 신뢰 경계가 다른 조직이 같은 클러스터에 섞이거나, 규제로 인프라 자체를 갈라야 한다고 정해졌을 때만 비용을 알고도 클러스터를 나눈다.

노드 분리를 검토할 때 공공 부문에는 조건이 하나 더 붙는다. 앞의 국가 클라우드 컴퓨팅 보안 가이드라인은 컨테이너 노드를 가상머신 위에 두도록 필수로 규정한다. 커널이 침해되거나 컨테이너 탈출이 일어났을 때 피해 반경을 하이퍼바이저 경계 안으로 묶으려는 취지다.

성능이나 비용을 이유로 베어메탈 쿠버네티스를 제안하면 보안성 검토에서 지적될 수 있으므로, 노드를 어디에 둘지는 설계 착수 시점에 확정한다. 가상머신 위에 쿠버네티스를 올리는 구성이라면 하이퍼바이저 쪽 보안기준도 별도로 충족해야 한다.

구획을 나누기로 했다면 다음 질문은 이름이다. 이름 규칙이 나중에 걸 수 있는 통제의 범위를 정하기 때문이다.

▲ 환경으로만 나누면 서비스 간 간섭이 남음 (발표자료 10쪽)

환경으로만 나누면 dev, qa, prod 세 구획 안에 서비스가 여럿 들어간다. 같은 구획 안의 서비스끼리는 서로 열려 있고, 정책이나 권한을 서비스 단위로 걸 자리가 없다. 서비스 이름과 환경을 함께 쓰면 구획이 서비스 단위로 갈리므로 뒤따르는 정책과 권한이 그대로 정렬된다. 우편물에 동 이름만 적는 것과 동과 호수를 함께 적는 것의 차이다.

환경으로만 나눈 경우      서비스명과 환경을 함께 쓴 경우
dev                       payment-dev    order-dev
qa                        payment-qa     order-qa
prod                      payment-prod   order-prod

쿠버네티스 보안 통제 가운데 Namespace 단위로 걸 수 있는 것은 세 가지다.

• 자원 총량 — ResourceQuota 와 LimitRange 로 구획이 쓸 수 있는 CPU·메모리 상한을 정한다
• 통신 정책 — NetworkPolicy 로 어느 구획에서 어느 구획으로 갈 수 있는지 정한다
• 권한 범위 — RoleBinding 으로 구획 안에서만 유효한 역할을 부여한다

다만 클러스터 전체에 걸친 장애는 구획으로 막히지 않는다. 사고 반경을 더 줄이려면 클러스터를 나눠야 하고, 그러면 앞에서 본 관리 비용이 늘어난다. 이 둘 사이의 균형을 잡는 것이 쿠버네티스 보안 설계다.

• 쿠버네티스 보안 점검은 4C 모델을 따라 Cloud 에서 Code 순으로 내려간다. 안쪽 층의 보안은 바깥 층 위에서만 성립한다.
• NIST SP 800-190 은 컨테이너 환경의 위험을 분류별 점검 목록으로 제공하며, 발표자료는 네 분류에서 대표 위험 12개를 추렸다.
• 아무 설정도 없는 클러스터는 네트워크 모두 허용, 특권 실행 미차단, 서비스 계정 토큰 자동 주입이 기본값이다.
• NetworkPolicy 는 네트워크 플러그인이 지원할 때만 동작하므로 막혀야 할 위치에서 실제 호출로 확인한다.
• 격리는 네임스페이스·노드·클러스터 세 단계이며, 요구 수준을 만족하는 가장 낮은 비용의 단계를 고른다.
• Namespace 이름에 서비스명과 환경을 함께 쓰면 자원 총량·통신 정책·권한 범위를 서비스 단위로 걸 수 있다.

쿠버네티스 보안은 어디부터 점검해야 하나?

바깥 층부터 점검한다. 4C 모델에서 안쪽 층의 보안은 바깥 층이 안전하다는 전제 위에서만 성립하므로, 클라우드 계정과 클러스터 설정을 먼저 확인한 뒤 컨테이너와 코드로 내려간다.

NetworkPolicy 를 만들었는데 통신이 막히지 않는 이유는?

네트워크 플러그인이 NetworkPolicy 를 지원하지 않으면 정책은 오류 없이 무시된다. 정책 파일이 있다는 사실은 차단의 증거가 아니므로, 막혀야 할 파드에서 실제로 호출해 결과를 확인한다.

네임스페이스만으로 격리가 충분한가?

대부분의 사내 요구는 네임스페이스로 충분하다. 다만 노드와 커널, 컨트롤 플레인은 여전히 공유되므로 신뢰 경계가 다른 조직이 섞이거나 규제로 인프라를 갈라야 할 때는 노드 분리나 클러스터 분리를 검토한다.

Namespace 이름은 어떻게 짓는 것이 좋은가?

서비스 이름과 환경을 함께 쓴다. payment-prod 처럼 구획이 서비스 단위로 갈리면 ResourceQuota, NetworkPolicy, RoleBinding 같은 통제를 서비스 단위로 걸 수 있다. 환경으로만 나누면 같은 구획 안의 서비스끼리 서로 열린 채로 남는다.

CNCF Korea 에서 함께 읽을 글이다.

• 클라우드 네이티브 보안 완벽 가이드 — 4C 모델과 DevSecOps 적용법
• 쿠버네티스 접근 제어 — 권한 과다를 막는 위임과 감사 기준 (2편)
• 쿠버네티스 (Kubernetes) 란 무엇인가 — 개념과 도입 이유
• 쿠버네티스 아키텍처 완벽 정리 — 컨트롤 플레인부터 워커 노드까지
• 실습 — 네임스페이스 기반 통신 제한
• 쿠버네티스가 마이크로서비스 운영의 필수 플랫폼인 이유
• 컨테이너 기술 표준 정리 — 쿠버네티스·CRI-O·runC의 역할과 차이
• 쿠버네티스 vs 도커 차이 완벽 정리

공식 문서와 원문이다.

• Kubernetes — Cloud Native Security and Kubernetes
• NIST SP 800-190 Application Container Security Guide
• Kubernetes — Network Policies
• Kubernetes — Namespaces
• Kubernetes — Multi-tenancy
• Kubernetes — Pod Security Standards
• Kubernetes — Service Accounts

쿠버네티스 보안과 거버넌스 과정 1편의 발표 슬라이드 10쪽을 PDF 한 파일로 정리했다.