Cloud Native

경계 방어는 “지킬 대상이 고정되어 있다”는 전제 위의 전략인데, 클라우드 네이티브 환경에서는 그 전제가 무너집니다.

전통적 보안 모델은 네트워크 경계에 방화벽을 세우고, 그 안의 서버들을 신뢰하는 구조였습니다. 서버는 수년간 같은 자리에 있고, IP 는 바뀌지 않으며, 배포는 분기에 한 번이니 그때만 점검하면 됐습니다.

컨테이너·마이크로서비스 환경은 세 가지 지점에서 이 전제를 깹니다.

• 동적 워크로드 — 파드(Pod)는 자동 확장과 재배치로 수시로 생겼다 사라집니다. IP 기반 방화벽 규칙으로는 대상을 특정할 수 없습니다.
• 짧은 수명 — 컨테이너의 수명은 시간·분 단위까지 짧아집니다. “서버에 백신을 깔고 주기적으로 점검”하는 방식이 들어설 자리가 없습니다.
• 확대된 공격 표면 — 서비스가 잘게 나뉘면서 서비스 간 API 통신, 컨테이너 이미지, 오케스트레이터 설정, CI/CD 파이프라인까지 공격 지점이 늘었습니다. 경계 하나를 지키는 게임이 아니라 계층 전체를 지키는 게임이 됐습니다.

공격 지점을 구체적으로 세어 보면 그림이 분명해집니다. 외부에 노출된 애플리케이션 취약점만이 아니라 설정 실수로 열린 API 서버와 대시보드, 관리 부주의로 유출된 kubeconfig 자격 증명, 악성 코드가 심긴 컨테이너 이미지, 공개 저장소에 올라온 매니페스트 파일까지가 모두 초기 침입 경로입니다. 게다가 침입에 성공한 뒤 공격자가 쓰는 수단은 대부분 클러스터가 정상적으로 제공하는 기능입니다. 컨테이너에 셸로 들어가고, 파드에 마운트된 서비스 어카운트 토큰으로 API 를 호출하고, 권한이 넉넉하게 남아 있는 롤 바인딩으로 자기 권한을 올립니다. 방어가 “침입 지점 한 곳을 막는” 문제가 아니라 “계층마다 통제를 두는” 문제인 이유가 여기 있습니다.

CNCF TAG Security 의 클라우드 네이티브 보안 백서도 같은 진단을 내립니다. 클라우드 네이티브 환경에서는 보안이 특정 제품이 아니라 개발 수명 주기 전체에 통합되어야 하며, 배포 이후가 아니라 개발·배포·런타임 각 단계에 맞는 통제가 필요하다는 것입니다(출처: CNCF TAG Security — Cloud Native Security Whitepaper v2).

쿠버네티스 공식 문서가 제시하는 4C 모델은 Cloud, Cluster, Container, Code 네 계층을 각각 지키는 심층 방어 프레임입니다.

쿠버네티스 공식 문서는 클라우드 네이티브 보안을 네 개의 동심원으로 설명합니다. 바깥에서 안쪽으로 Cloud(클라우드/데이터센터), Cluster(쿠버네티스 클러스터), Container(컨테이너), Code(애플리케이션 코드)이며, 바깥 계층이 뚫리면 안쪽 계층만으로 막기 어렵다는 점이 핵심입니다(출처: Kubernetes 공식 문서 — 보안 개요, 한국어).

그림 1. 쿠버네티스 4C 보안 모델 — Cloud·Cluster·Container·Code

• Cloud — 인프라 계층입니다. 클라우드 계정 권한 관리, 네트워크 구성, 컨트롤 플레인 접근 통제가 여기 속합니다. 관리형 서비스라면 공급자와의 책임 분담(Shared Responsibility)을 명확히 하는 일부터 시작합니다. 온프레미스라면 노드 OS 패치와 etcd 접근 통제가 같은 자리를 차지합니다.
• Cluster — 쿠버네티스 자체의 보안입니다. API 서버 인증·인가(RBAC), 네트워크 폴리시, Secret 암호화, 감사 로그가 핵심 통제입니다. 기본값을 그대로 둔 클러스터가 가장 흔한 취약 지점입니다. 특히 롤 바인딩 권한과 Secret 읽기 권한은 한 번 새면 다른 통제를 우회하는 열쇠가 되므로 별도로 관리합니다.
• Container — 이미지와 런타임의 보안입니다. 취약점 없는 이미지 사용, 루트 권한 실행 금지, 불필요한 권한(privileged) 제거가 기본입니다. 파드 스펙의 securityContext 에서 비루트 실행과 권한 상승 차단, 읽기 전용 루트 파일시스템을 지정하는 것이 출발점입니다.
• Code — 애플리케이션 코드의 보안입니다. 의존성 취약점 관리, 정적 분석(SAST), 시크릿 하드코딩 금지, TLS 통신이 여기 해당합니다.

4C 의 실무적 의미는 “어느 한 계층의 보안 제품을 사는 것”으로 끝나지 않는다는 데 있습니다. 계층마다 책임 팀과 도구가 다르므로, 보안 점검표도 계층별로 나눠서 관리해야 빈틈이 보입니다.

계층을 나눠 보면 조직의 사각지대도 드러납니다. Cloud 는 인프라팀, Code 는 개발팀이 이미 관리하고 있는 경우가 많은데, 그 사이의 Cluster 와 Container 는 “쿠버네티스를 도입한 팀”이 암묵적으로 떠안고 있다가 아무도 점검하지 않는 상태로 남기 쉽습니다. 4C 를 점검표로 쓸 때 가장 먼저 확인할 것은 도구가 아니라 각 계층에 이름이 적힌 담당자가 있는가입니다.

이미지 보안의 원칙은 세 가지입니다. 스캔해서 걸러내고, 최소 이미지로 표면을 줄이고, 서명으로 출처를 증명합니다.

컨테이너 이미지는 애플리케이션과 의존성 전체를 담는 만큼, 이미지 하나에 포함된 OS 패키지·라이브러리의 취약점이 그대로 운영 환경에 들어갑니다. 통제 지점은 세 곳입니다.

1. 취약점 스캔 — Trivy 같은 스캐너로 이미지의 알려진 취약점(CVE)을 검사하고, 심각도 기준을 정해 파이프라인에서 차단합니다. 스캔은 일회성이 아니라 레지스트리에 있는 이미지에 대해 반복 수행해야 합니다. 새 CVE 는 계속 공개되기 때문입니다.
2. 최소 베이스 이미지 — 패키지가 적을수록 취약점도 적습니다. 범용 OS 이미지 대신 distroless 나 alpine 같은 최소 이미지를 쓰면 공격 표면과 이미지 크기가 함께 줄어듭니다.
3. 서명과 검증 — 빌드된 이미지에 서명하고, 클러스터가 서명된 이미지만 실행하도록 정책을 겁니다. “우리 파이프라인이 만든 이미지”임을 암호학적으로 증명하는 장치입니다.
4. 레지스트리 내재화 — 이미지를 조직의 프라이빗 레지스트리로 모으면 위 세 가지 통제를 거는 지점이 한 곳으로 모입니다. 외부 레지스트리의 장애나 Rate Limit 정책으로부터 빌드·배포를 분리하고, 검증·패치된 표준 베이스 이미지만 쓰도록 강제하며, dev·stg·prod 저장소를 나눠 RBAC 로 접근을 통제할 수 있습니다(출처: 컨테이너 레지스트리 이미지 관리 방안, Cloud Native Forum). Harbor 같은 레지스트리는 Trivy·Clair 스캐너를 함께 배치해 저장과 스캔을 한 곳에서 묶는 구성이 일반적입니다(출처: 쿠버네티스 Private 컨테이너 레지스트리 구축 방법, Cloud Native Forum).

그림 2. 컨테이너 이미지 보안 — 배포 전 네 개의 통제 지점

이 네 가지는 모두 배포 전 단계의 통제라는 공통점이 있습니다. 운영에 들어간 뒤 잡는 것보다 파이프라인에서 걸러내는 편이 비용도 위험도 작습니다.

실무에서 자주 막히는 지점은 “스캔을 언제 도느냐”와 “무엇을 막느냐” 두 가지입니다. 스캔 시점은 세 곳에 두는 편이 안전합니다. 빌드 직후에 한 번(새로 만든 이미지 검사), 레지스트리에 있는 이미지를 대상으로 정기적으로 한 번(새 CVE 반영), 그리고 배포 시점의 어드미션 단계에서 한 번(정책 위반 차단)입니다. 차단 기준은 처음부터 모든 취약점을 막으면 파이프라인이 서므로, Critical 은 즉시 차단하고 High 는 기한을 정해 관리하는 식으로 단계를 나누는 것이 현실적입니다. 중요한 것은 기준의 엄격함이 아니라 기준이 문서가 아니라 파이프라인 설정으로 존재하는가입니다.

공급망 보안은 “내 코드”만이 아니라 “내 코드가 의존하는 모든 것”의 무결성을 다루며, SBOM·Sigstore·SLSA 가 표준 도구 세트입니다.

현대 애플리케이션의 코드 대부분은 직접 작성한 것이 아니라 오픈소스 의존성입니다. 의존성 하나가 오염되면 그것을 쓰는 모든 시스템이 함께 위험해집니다. 2020년 SolarWinds 사건과 2021년 Log4Shell 취약점이 공급망 보안을 업계 전면에 끌어올린 계기였습니다.

대응 체계는 세 축으로 정리됩니다.

• SBOM(Software Bill of Materials) — 소프트웨어 자재 명세서입니다. 이 이미지에 어떤 구성 요소가 어떤 버전으로 들어 있는지를 기계가 읽을 수 있는 형식(SPDX, CycloneDX)으로 기록합니다. 새 취약점이 공개됐을 때 “우리가 영향을 받는가”를 즉시 답할 수 있게 하는 기반입니다.
• Sigstore — 서명 도구 모음으로, OpenSSF 산하 프로젝트입니다. cosign 으로 이미지·아티팩트에 서명하고 투명성 로그(Rekor)에 기록해, 키 관리 부담을 낮추면서 서명·검증을 파이프라인에 넣을 수 있게 합니다.
• SLSA(Supply-chain Levels for Software Artifacts) — 빌드 과정의 무결성 수준을 단계로 정의한 프레임워크입니다. 빌드 출처(provenance) 기록부터 변조 방지 빌드까지, 우리 파이프라인이 어느 수준인지 진단하고 끌어올리는 기준으로 씁니다.

그림 3. 공급망 보안 3축 — SBOM·Sigstore·SLSA 가 답하는 질문

세 축은 서로를 대체하지 않고 각자 다른 질문에 답합니다. SBOM 은 “무엇이 들어 있는가”, Sigstore 는 “이것이 우리가 만든 것이 맞는가”, SLSA 는 “만드는 과정을 믿을 수 있는가”에 답합니다. SBOM 만 있으면 구성 요소는 알아도 그 이미지가 중간에 바뀌었는지 모르고, 서명만 있으면 출처는 알아도 그 안의 취약점은 모릅니다. 도입 순서를 정한다면 SBOM 생성을 빌드에 붙이는 일이 가장 쉽고, 서명·검증이 그다음이며, 빌드 환경 자체의 무결성을 다루는 SLSA 상위 단계가 마지막입니다.

CNCF 보안 백서 역시 배포 단계 통제로 아티팩트 서명·출처 검증을 명시합니다(출처: CNCF TAG Security — Cloud Native Security Whitepaper v2). 요컨대 공급망 보안의 질문은 “이 코드는 안전한가”에서 “이 코드가 여기까지 온 경로를 신뢰할 수 있는가”로 확장됩니다.

런타임 보안의 뼈대는 제로 트러스트입니다. 네트워크 위치로 신뢰를 주지 않고, 모든 요청을 검증하며, 정책을 코드로 강제합니다.

CNCF 용어집은 제로 트러스트 아키텍처를 신뢰를 완전히 제거한 IT 시스템 설계 방식으로 정의하며, 핵심 원칙을 “절대 신뢰하지 말고 항상 검증하라(never trust, always verify)”로 요약합니다. 네트워크 경계 안쪽이라도 각 기기와 시스템은 다른 구성 요소와 통신하기 전에 스스로를 검증해야 한다는 것입니다(출처: CNCF Cloud Native Glossary — Zero Trust Architecture). 경계 안이면 믿어 주던 전통 모델의 정반대입니다. 쿠버네티스 환경에서의 구현 수단은 다음과 같습니다.

• 네트워크 폴리시(NetworkPolicy) — 쿠버네티스는 네임스페이스와 노드가 달라도 모든 파드가 서로 통신할 수 있는 개방형(flat) 네트워크 모델이 기본입니다. 그래서 파드 하나가 뚫리면 공격자가 그 파드를 교두보 삼아 데이터베이스·인증 서비스로 옮겨 다니는 공격 확산(Lateral Movement)이 쉽게 일어납니다. 네트워크 폴리시는 이 전제를 “기본 거부(default deny) 후 명시적으로 허용된 통신만 개방”하는 화이트리스트 모델로 뒤집습니다. 결제 서비스는 주문 서비스에서만 호출된다면, 그 경로만 열고 나머지는 닫습니다. 다만 폴리시는 CNI 플러그인이 지원해야 실제로 적용되므로, Calico·Cilium·Weave Net 같은 지원 CNI 가 설치돼 있는지부터 확인해야 합니다(출처: 네트워크 폴리시 — 파드 간 통신 제어, Cloud Native Forum 쿠버네티스 전자책).
• mTLS(상호 TLS) — 서비스 간 통신을 양방향 인증서로 암호화·인증합니다. Istio 같은 서비스 메시를 쓰면 애플리케이션 코드 수정 없이 서비스 간 mTLS 를 일괄 적용할 수 있습니다.
• 정책 엔진(OPA) — Open Policy Agent 는 “루트 컨테이너 금지”, “서명 없는 이미지 배포 금지” 같은 규칙을 코드로 정의하고, 어드미션 컨트롤 단계에서 위반 배포를 자동 거부합니다. 사람의 점검표를 클러스터가 강제하는 규칙으로 바꾸는 도구입니다. 그 앞단에는 쿠버네티스에 내장된 파드 시큐리티 어드미션(Pod Security Admission)이 있습니다. 네임스페이스에 baseline·restricted 수준을 라벨로 지정하는 것만으로 특권 컨테이너와 호스트 네임스페이스 사용을 막을 수 있어, 정책 엔진을 도입하기 전 가장 적은 비용으로 세울 수 있는 기본선입니다.
• 런타임 탐지 — Falco 같은 도구가 실행 중 컨테이너의 이상 행위(예상 밖 프로세스 실행, 민감 파일 접근)를 감지합니다. 배포 전 통제를 통과한 위협이 실행 단계에서 움직일 때를 잡는 마지막 층입니다.

여기서 관측성과의 연결 고리가 생깁니다. 이상 행위 탐지도, 침해 사고 조사도 메트릭·로그·트레이스가 수집되고 있어야 가능합니다. 그 세 신호를 하나의 표준으로 모으는 방법은 OpenTelemetry 란 무엇인가? 글에서 다룹니다.

DevSecOps 는 배포 직전 보안 심사를 개발 초기 단계의 자동 검사로 옮기는(Shift-Left) 실천이며, 보안을 게이트가 아니라 파이프라인의 일부로 만듭니다.

전통 조직에서 보안은 개발이 끝난 뒤 배포 직전에 등장하는 관문이었습니다. 배포가 분기 1회라면 가능한 방식이지만, 하루 수십 번 배포하는 환경에서는 보안팀이 병목이 되거나 심사가 형식화되거나 둘 중 하나가 됩니다.

DevSecOps 는 검사 시점을 왼쪽(개발 초기)으로 옮기고 자동화합니다. 개발자는 배포 다음 날 보안 티켓을 받는 대신, 커밋 몇 분 뒤 파이프라인 실패로 문제를 알게 됩니다. 고치는 비용이 가장 쌀 때입니다.

그림 4. DevSecOps Shift-Left — 단계별 보안 검사 배치와 수정 비용

파이프라인 단계별로 어떤 검사가 어디에 붙는지 정리하면 다음과 같습니다.

표를 왼쪽에서 오른쪽으로 읽으면 비용이 커지는 순서이기도 합니다. 커밋 단계에서 걸린 시크릿은 커밋을 고치면 끝나지만, 런타임에서 발견한 같은 문제는 자격 증명 교체와 영향 범위 조사를 동반합니다. 그래서 오른쪽 통제를 갖췄다고 왼쪽을 건너뛰지 않고, 왼쪽부터 채운 뒤 오른쪽으로 확장하는 순서를 권합니다.

중요한 것은 도구 나열이 아니라 책임 구조의 변화입니다. 보안팀은 개별 배포를 심사하는 대신 정책과 기준을 코드로 정의하고, 개발팀은 그 기준을 파이프라인 안에서 상시 통과하며 개발합니다. 컨테이너·CI/CD·DevOps 위에 보안이 얹히는 구조이므로, 4대 요소가 아직 낯설다면 클라우드 네이티브 4대 요소 글을 먼저 보시기 바랍니다. 그리고 보안 체계는 전환 방식 자체와 맞물려 있습니다. VM 을 그대로 옮긴 조직과 컨테이너·마이크로서비스로 다시 설계한 조직은 지켜야 할 대상부터 다르기 때문입니다. 그 차이는 클라우드 네이티브 vs 클라우드 — 마이그레이션 방식으로 보는 차이에서 확인하실 수 있습니다.

클라우드 네이티브 보안을 한 줄로 줄이면 이렇습니다. 성벽 하나를 높이 쌓는 대신, 네 계층에 얇은 방어를 겹겹이 두고 그 검사를 사람이 아니라 파이프라인이 상시 수행하게 만드는 것입니다. 환경이 동적으로 바뀌었으니, 보안도 동적으로 바뀌어야 합니다.

Q. 4C 보안 모델이란 무엇인가요?

쿠버네티스 공식 문서가 제시하는 계층별 방어 프레임으로, Cloud(인프라)·Cluster(쿠버네티스)·Container(이미지·런타임)·Code(애플리케이션) 네 계층을 각각 지키는 심층 방어 모델입니다. 바깥 계층이 취약하면 안쪽 통제만으로 막기 어렵습니다.

Q. SBOM 은 왜 필요한가요?

새 취약점이 공개됐을 때 “우리 시스템이 영향을 받는가”를 즉시 답하기 위해서입니다. 이미지에 포함된 구성 요소와 버전을 기계가 읽을 수 있는 명세로 남겨 두면, Log4Shell 같은 사건 때 영향 범위를 수 시간이 아니라 수 분 안에 파악할 수 있습니다.

Q. 서비스 메시 없이도 제로 트러스트를 할 수 있나요?

가능합니다. 네트워크 폴리시로 파드 간 통신을 제한하고, 애플리케이션 수준 TLS 와 RBAC 를 조합하면 기본기는 갖춰집니다. 다만 서비스 수가 많아지면 mTLS 일괄 적용과 통신 정책 관리에 서비스 메시가 훨씬 효율적입니다.

Q. DevSecOps 도입은 어디서부터 시작해야 하나요?

CI 파이프라인에 이미지 취약점 스캔과 시크릿 유출 검사를 넣는 것이 가장 효과 대비 비용이 낮은 출발점입니다. 이후 정책 엔진(OPA)으로 배포 규칙을 강제하고, 런타임 탐지로 확장하는 순서를 권합니다.

Q. 보안 때문에 배포 속도가 느려지지 않나요?

수동 심사를 자동 검사로 바꾸면 오히려 빨라집니다. 파이프라인 검사는 수 분 안에 끝나고, 문제를 커밋 직후에 발견하므로 수정 비용도 작습니다. 병목은 보안 자체가 아니라 사람 손을 거치는 심사 절차에서 생깁니다.

• Kubernetes 공식 문서 — 클라우드 네이티브 보안 개요(한국어)
• CNCF TAG Security — Cloud Native Security Whitepaper v2
• CNCF 용어집 — Zero Trust Architecture

함께 읽기 (Cloud Native Forum)

• 클라우드 네이티브란? 개념·구성요소·도입 전략 가이드 — 이 글의 상위 개념 정리
• 클라우드 네이티브 4대 요소 — 컨테이너·MSA·CI/CD·DevOps — DevSecOps 가 올라타는 토대
• 클라우드 네이티브 vs 클라우드 — 마이그레이션 방식으로 보는 차이 — 전환 방식에 따라 달라지는 보안 대상
• 쿠버네티스 전자책 8.4 네트워크 폴리시 — 파드 간 통신 제어 — 기본 거부 정책과 CNI 전제, 실습까지
• 컨테이너 레지스트리 이미지 관리 방안 — 표준 베이스 이미지와 저장소별 접근 통제
• 쿠버네티스 Private 컨테이너 레지스트리 구축 방법 — Harbor·취약점 스캐너 구성
• OpenTelemetry 란 무엇인가? — 런타임 탐지와 사고 조사의 기반이 되는 관측 데이터 표준