Kubernetes 보안이란 무엇인가?
Kubernetes 보안은 클러스터, 클러스터에서 실행되는 워크로드, 그리고 이를 공급하는 파이프라인을 보호하기 위해 빌드, 배포, 런타임 전반에 적용하는 통제의 집합입니다. 이러한 통제가 없으면 인증되지 않은 요청 하나로 전체 클러스터가 장악될 수 있습니다. 이것이 바로 2025년 3월에 공개된 ingress-nginx의 심각도 9.8 취약점인 IngressNightmare였습니다. ingress-nginx는 Kubernetes 클러스터의 40% 이상에서 실행되는 컨트롤러입니다.
해당 admission webhook은 인증 없이 pod 네트워크에 위치해 있었고, ingress-nginx는 기본적으로 클러스터의 모든 Secret을 읽습니다. 네트워크에 도달하면 클러스터를 장악할 수 있었습니다. 익스플로잇 체인도, 탈취된 비밀번호도 필요하지 않았습니다. 단지 허용적인 기본 설정이 구성된 대로 동작했을 뿐입니다.
Kubernetes가 기본 제공하는 것과 프로덕션 클러스터에 필요한 것 사이의 이 간극을 메우는 것이 바로 하드닝입니다. Kubernetes 보안 모범 사례는 빌드하는 이미지부터 실행하는 워크로드까지 단계별로 이 간극을 해소하는 방법입니다. 오케스트레이션은 워크로드, 비밀 정보, east-west 트래픽을 하나의 컨트롤 플레인에 중앙집중화하므로, 단일 오구성만으로도 실행 중인 모든 서비스가 노출될 수 있습니다. 따라서 이 작업은 플랫폼이 아니라 사용자에게 책임이 있습니다.
Kubernetes 보안이 중요한 이유는 무엇인가?
Kubernetes는 스스로를 하드닝하지 않습니다. CISA/NSA Kubernetes Hardening Guidance는 모든 신규 클러스터에서 나타나는 세 가지 의미 있는 기본 설정을 문서화합니다. 익명 API 서버 로그인이 활성화되어 있고, Secret은 etcd에 암호화되지 않은 상태로 저장되며, 감사 로깅은 비활성화되어 있습니다. 공동 책임 모델은 네 가지 통제를 사용자에게 맡깁니다: 역할 기반 액세스 제어(RBAC), 네트워크 정책, 비밀 정보 암호화, 런타임 통제입니다. 클라우드 제공업체도 이를 대신 구성해주지 않으며, 배포판도 마찬가지입니다. 이러한 통제는 사용자 구성에 존재하고 시간이 지나며 드리프트하므로, 팀들은 점점 더 수동 감사 대신 Kubernetes 보안 태세 관리를 통해 이를 지속적으로 검증하고 있습니다.
인증되지 않은 API 서버에 도달한 공격자는 etcd의 모든 Secret을 읽고, 아무 노드에나 pod를 스케줄링하며, 감사 로깅이 침묵하는 동안 네임스페이스 간 이동까지 할 수 있습니다. 따라서 사용자가 처음 받는 신호는 침해 자체일 수 있습니다. 노출된 엔드포인트 하나가 몇 분 만에 클러스터 전체 액세스로 이어지며, 이는 IngressNightmare가 따랐던 것과 동일한 패턴입니다.
도입이 확대될수록 위험도 커집니다. Cloud Native Computing Foundation (CNCF) Annual Cloud Native Survey는 현재 컨테이너 사용자의 82%가 Kubernetes를 프로덕션에서 실행한다고 보고합니다. 이는 2023년의 66%에서 증가한 수치입니다. 클러스터가 고객 대면 서비스, 규제 대상 데이터, 감사 의무의 경로에 놓이면서, 단 하나의 누락된 통제가 침해 노출, 감사 실패, 그리고 팀이 책임져야 하는 보고 대상 사고로 이어집니다. 무엇이 걸려 있는지 아는 것은 클러스터의 어느 부분이 그 위험을 지니는지 알 때에만 의미가 있습니다.
Kubernetes 클러스터의 핵심 구성 요소
인벤토리화하지 않은 것은 하드닝할 수 없습니다. 각 구성 요소는 특정한 보안 노출을 지니며, 그 노출을 이해해야 통제가 어디에 적용되어야 하는지 알 수 있습니다.
컨트롤 플레인 구성 요소:
- API 서버: 실행하는 모든
kubectl명령, 모든 admission webhook, 모든 서비스 계정 토큰 요청은 API 서버를 통과합니다. 여기서 무단 액세스가 발생하면 클러스터 전체 제어로 이어집니다. - etcd: 의존하는 모든 클러스터 상태, 구성, Secret을 저장합니다. etcd에 대한 읽기 액세스는 기능적으로 클러스터 전체의 루트 권한과 동일합니다.
- 스케줄러 및 컨트롤러 매니저: 손상된 스케줄러는 로컬 리소스를 악용하기 위해 특정 노드에 워크로드를 배치할 수 있습니다. 컨트롤러 조작은 배포, 복제본 수, 리소스 할당을 조용히 변경할 수 있습니다.
워커 노드 구성 요소:
- kubelet: 모든 노드에서 pod 사양을 실행하는 에이전트입니다. kubelet API를 노출된 상태로 두면 공격자가 컨테이너를 생성하거나 노드에서 직접 명령을 실행할 수 있습니다.
- kube-proxy: 서비스 라우팅을 위한 네트워크 규칙을 관리합니다. 잘못 구성된 프록시 규칙은 내부 서비스를 외부 트래픽에 노출시킬 수 있습니다.
- 컨테이너 런타임: 호스트에서 컨테이너를 실행합니다. NIST SP 800-190이 지적하듯이, 취약한 런타임은 지원하는 모든 컨테이너와 호스트 자체를 노출시킵니다.
Pod, 컨테이너 및 네트워킹:
- Pod는 네트워크 네임스페이스를 공유하므로, pod 내의 손상된 컨테이너는 네트워크 통제 없이 동일 pod의 다른 컨테이너에 액세스할 수 있습니다. NetworkPolicy 객체가 없으면 서로 다른 네임스페이스의 pod는 기본적으로 자유롭게 통신합니다.
- 컨테이너 이미지와 infrastructure-as-code (IaC) 템플릿은 외부 레지스트리에서 클러스터로 유입되며, 프로덕션으로 가져온 오염된 이미지는 이를 스케줄링하는 모든 노드로 전파됩니다. 각 구성 요소를 해당 노출과 매핑하면 이 가이드의 하드닝 통제가 정확히 어디에 적용되는지 알 수 있습니다.
빌드부터 런타임까지의 라이프사이클 전반에서 Kubernetes 보안이 작동하는 방식
Kubernetes는 시점 기반 점검이 아니라 지속적인 워크플로를 통해 보호합니다. 각 단계는 서로 다른 범주의 통제를 시행하며, 한 단계의 출력은 다음 단계의 입력이 됩니다. 각 단계에서 어떤 일이 일어나는지 살펴보겠습니다.
- 빌드 시점: 알려진 취약점에 대해 컨테이너 이미지를 스캔하고, 정책에 따라 IaC 템플릿을 검증하며, 이미지를 암호학적으로 서명하고, software bill of materials (SBOM)를 생성합니다. 이러한 예방 통제는 어떤 아티팩트도 스케줄링되기 전에 문제를 원천에서 차단합니다.
- 배포 및 구성: 워크로드를 제출하면 admission controller가 스케줄링 전에 정책에 따라 이를 평가합니다. RBAC는 누가 리소스를 생성, 수정 또는 읽을 수 있는지 결정하고, 네트워크 정책은 어떤 pod가 통신할 수 있는지 정의합니다. 빌드 시 서명한 이미지는 admission control이 실제로 서명을 검사할 때에만 여기서 보호됩니다.
- 컨트롤 플레인 및 노드 구성: 노출 범위를 줄이기 위해 API 서버, etcd, kubelet, 노드 OS를 구성합니다. 인증, 권한 부여, 암호화는 다른 모든 단계가 의존하는 신뢰 경계를 설정하므로, 약한 컨트롤 플레인은 다운스트림 전체를 약화시킵니다.
- 런타임: 모니터링 도구는 실행 중인 워크로드에서 행동 이상, 구성 드리프트, 알려진 공격 패턴을 감시하며, seccomp 및 AppArmor 프로필은 컨테이너가 수행할 수 있는 시스템 호출을 제한합니다. 런타임은 빌드와 배포가 놓친 간극을 포착하는 단계이기도 합니다.
런타임 결과를 업데이트된 이미지, 업데이트된 IaC, 업데이트된 admission 정책으로 빌드 단계에 다시 반영할 때 루프가 닫힙니다. 이 라이프사이클은 모든 핸드오프가 유지될 때만 작동합니다. 핸드오프 하나가 실패하면 어떤 대가를 치르는지 살펴보겠습니다.
손상된 Kubernetes 클러스터의 영향
클러스터가 손상되면 그 결과는 단일 워크로드를 훨씬 넘어 확장됩니다.
- 측면 이동과 블래스트 반경: 클러스터는 네트워크 연결을 공유하는 수십 개에서 수천 개의 pod를 실행합니다. 공격자가 pod 하나에 액세스하면 RBAC 권한이 과도하고 네트워크 정책이 없을 때 네임스페이스와 노드 전반으로 측면 이동할 수 있습니다.
- 비밀 정보 노출: etcd는 API 키, 데이터베이스 자격 증명, TLS 인증서, 서비스 토큰을 보관합니다. Secret은 기본적으로 암호화되지 않으므로, etcd 읽기 액세스 권한을 가진 공격자는 클러스터의 모든 자격 증명을 추출할 수 있습니다.
- 공급망 전파: 지속적 통합 및 지속적 전달(CI/CD) 파이프라인을 통해 배포된 오염된 컨테이너 이미지는 이를 스케줄링하는 모든 노드에 도달합니다. 수백 개의 복제본을 실행하는 클러스터에서는 손상된 이미지 하나가 몇 분 안에 전체 인프라 전반에서 악성 코드를 실행할 수 있습니다.
- 워크로드 및 데이터 손상: 프로덕션 데이터베이스, 고객 대면 애플리케이션, 내부 서비스가 나란히 실행됩니다. 하나의 워크로드에서 발생한 침해는 민감한 데이터를 노출시키거나, 서비스 가용성을 방해하거나, 향후 공격을 위한 지속성을 구축할 수 있습니다.
- 컴플라이언스 및 규제 노출: 클러스터가 결제 데이터, 의료 기록 또는 정부 워크로드를 처리하는 경우 PCI DSS, HIPAA, FedRAMP 및 SOC 2 요구 사항의 적용을 받습니다. 감사에 실패하는 잘못 구성된 클러스터는 운영 중단과 재정적 벌금으로 이어질 수 있습니다.
하드닝은 단일 침해의 블래스트 반경을 줄이고, incident response 일정을 단축하며, 컴플라이언스 프로그램에 필요한 감사 증적을 생성합니다. 이를 실제로 달성하는 일은 Kubernetes의 실행 방식에 특화된 이유들 때문에 생각보다 더 어렵습니다.
Kubernetes 보안의 과제
Kubernetes 보안은 가장 숙련된 팀원에게도 운영상 어렵습니다. 플랫폼의 일시성, 선언적 구성 모델, 분산 아키텍처는 정적 보안 도구가 처리하도록 설계되지 않은 마찰을 만들어냅니다.
- 일시적이고 끊임없이 변화하는 워크로드: Pod는 지속적으로 생성, 삭제, 재스케줄링됩니다. 오전 9시에 찍은 클러스터 태세 스냅샷은 오전 9시 5분의 상태를 반영하지 못할 수 있습니다.
- 실행 중인 컨테이너에 대한 가시성 격차: 컨테이너는 호스트 커널을 공유하지만 프로세스, 파일 시스템, 네트워크 스택은 격리합니다. 표준 호스트 기반 모니터링 도구는 정상적인 컨테이너 동작과 악성 활동을 구분할 맥락이 부족한 경우가 많습니다.
- 구성 복잡성과 드리프트: 프로덕션 클러스터에는 수백 개의 YAML 매니페스트, RBAC 바인딩, admission 규칙이 포함됩니다. Git에 선언한 것과 클러스터에서 실행되는 것 사이의 드리프트는 추적되지 않는 노출을 초래합니다.
- 멀티 클러스터 및 멀티 클라우드 확산: Amazon Web Services (AWS), Azure, Google Cloud Platform (GCP), 온프레미스 환경 전반에서 클러스터를 실행하는 경우, 각각 고유한 공동 책임 경계를 가진 서로 다른 관리형 서비스 전반에 일관된 정책을 시행해야 합니다.
- 분절된 도구: 이미지 스캐닝, RBAC 관리, 네트워크 정책 시행, 런타임 모니터링, 컴플라이언스 보고에는 공유 데이터 모델이 없는 별도 도구가 필요한 경우가 많습니다. 경고 상관 분석은 사용자 몫입니다.
- 기술 및 조직적 마찰: 전문 기술은 부족하며, 2025 CNCF 설문조사에서는 처음으로 클라우드 네이티브 도입의 주요 장벽이 기술이 아니라 조직적 요인이라는 결과가 나왔습니다. 내부 커뮤니케이션, 팀 역학, 리더십 정렬이 문제였습니다. 통제는 소유자가 없기 때문에 적용되지 않습니다.
이러한 제약은 도구 선택과 채용 우선순위를 모두 형성하며, 동일한 실수가 클러스터 전반에서 반복되는 이유를 설명합니다.
일반적인 Kubernetes 보안 실수
특정 운영자 안티패턴이 공격자가 악용하는 노출을 만듭니다. 클러스터에서 다음 각각을 식별하고 제거하십시오:
- 권한 있는 컨테이너 또는 루트 컨테이너 실행. 권한 있는 컨테이너는 모든 Linux 커널 격리를 우회합니다. 루트로 실행되며
allowPrivilegeEscalation: true가 설정된 컨테이너는 호스트로 탈출할 수 있습니다. - cluster-admin 또는 와일드카드 RBAC 부여. 와일드카드 권한
(resources: ["*"], verbs: ["*"])은 아직 존재하지 않는 API 리소스에도 자동으로 확장됩니다. Kubernetes 문서는 이 패턴에 "DO NOT USE"라는 라벨을 붙입니다. - 기본 허용 네트워킹을 그대로 두기. NetworkPolicy 객체가 없으면 서로 다른 네임스페이스의 pod는 자유롭게 통신합니다.
- 평문 매니페스트에 Secret 저장. 자격 증명을 Git에 커밋하거나 환경 변수로 전달하면 크래시 덤프, 로그, 셸 기록에 노출됩니다.
- 이미지 및 IaC 스캐닝 생략. 스캔되지 않은 이미지를 배포하면 취약점이 통제 없이 프로덕션에 도달하게 됩니다.
- 하드닝을 일회성 게이트로 취급. 부트스트랩 시 하드닝된 클러스터도 팀이 워크로드를 추가하고 구성을 수정하면서 드리프트합니다. 지속적인 시행이 없으면 태세는 저하됩니다.
- 노드 및 컨트롤 플레인 구성을 무시. 익명 API 서버 로그인을 활성화된 상태로 두고, etcd 암호화를 건너뛰며, 감사 로깅을 누락하는 것은 명시적인 시정 조치가 필요한 기본 상태입니다.
이들 각각은 아래의 실천 방법으로 수정할 수 있습니다. 클러스터에 추가 워크로드를 확장하기 전에 제거해야 할 노출 체크리스트로 취급하십시오.
Kubernetes 보안 모범 사례
이러한 Kubernetes 보안 모범 사례는 Kubernetes 클러스터 하드닝의 운영 핵심을 이루며, 앞서 소개한 동일한 네 가지 라이프사이클 단계에 따라 구성되어 있습니다. 각 단계는 이전 단계가 유지된다는 가정 위에 있으므로 순서대로 진행하십시오.
빌드 단계 보호
- 이미지가 레지스트리에 도달하기 전에 취약점을 스캔하십시오. 취약한 이미지가 배포 가능한 아티팩트가 되지 않도록 컨테이너 이미지 스캐닝을 CI 파이프라인에 통합하십시오.
- 최소 또는 distroless 베이스 이미지를 사용하십시오. Distroless 이미지는 셸, 패키지 관리자, 불필요한 바이너리 없이 애플리케이션과 런타임 종속성만 포함합니다. 이미지는 명시적 버전 접미사로 고정하십시오
(e.g., gcr.io/distroless/static-debian13). 그리고latest tag는 절대 사용하지 마십시오. - 이미지에 서명하고 검증하십시오. CI에서 Cosign 또는 Notary를 사용해 이미지에 서명하십시오. 배포 시 서명되지 않았거나 검증되지 않은 이미지를 거부하도록 admission controller를 구성하십시오.
- IaC 및 Kubernetes 매니페스트를 스캔하십시오. Terraform, Helm 차트, 원시 YAML이 클러스터에 도달하기 전에 보안 정책에 따라 검증하십시오.
- 모든 이미지에 대해 SBOM을 생성하여 출처를 확립하고 배포 후 취약점 추적을 지원하십시오.
- 비밀 정보를 이미지에서 제외하십시오. 자격 증명, API 키, 인증서를 컨테이너 이미지나 Dockerfile에 절대 포함하지 마십시오.
이러한 빌드 단계 통제는 어떤 것이든 실행되기 전에 취약하거나 서명되지 않은 아티팩트가 파이프라인에 들어오는 것을 막습니다. 이를 통과한 이미지도 클러스터가 올바르게 승인할 때에만 안전하며, 그 지점부터는 배포 시점 구성이 역할을 이어받습니다.
클러스터 구성 및 배포 하드닝
이러한 Kubernetes RBAC 모범 사례와 네트워크 통제는 배포 시점 정책을 시행되는 가드레일로 전환합니다.
최소 권한 RBAC를 적용하십시오. 명시적 동사와 리소스 이름을 가진 네임스페이스 범위 Role을 생성하십시오. 와일드카드 권한 부여를 제거하십시오.
cluster-admin은 비상 시에만 제한하십시오. API 액세스가 필요하지 않은 서비스 계정에는automountServiceAccountToken: false를 설정하십시오.기본 거부 네트워크 정책을 시행하십시오. 부트스트랩 시 모든 네임스페이스에 수신 및 송신 모두에 대해
default-deny-allNetwenforce mode with the restrictedorkPolicy를 적용하십시오. DNS용 UDP 포트 53 송신 예외를 포함해 워크로드별 명시적 허용 규칙을 추가하십시오.Restricted Pod Security Standard를 시행하십시오. 프로덕션 네임스페이스에는
enforce모드와restricted level의 Pod Security Admission을 사용하십시오. 이는 권한 있는 컨테이너를 차단하고,runAsNonRoot를 요구하며, seccomp 프로필을 의무화하고, 볼륨 유형을 제한합니다.OPA Gatekeeper 또는 Kyverno로 admission control을 추가하십시오.
readOnlyRootFilesystem: true, allowPrivilegeEscalation: false, 이미지 레지스트리 허용 목록, capability drop-ALL 정책을 시행하십시오. 기존 워크로드를 감사하기 위해 먼저 dryrun 모드를 사용한 뒤deny로 전환하십시오.외부 저장소에서 Secret을 관리하고 etcd 저장 시 암호화를 적용하십시오. envelope 암호화를 위해 key management service (KMS) v2 provider를 사용하고, tmpfs를 사용하는 Secrets Store CSI Driver를 통해 Secret을 볼륨으로 마운트하여 비밀 데이터가 노드 디스크에 기록되지 않도록 하십시오. Secret을 환경 변수로 전달하는 방식은 피하십시오.
리소스 제한을 설정하십시오. 리소스 고갈을 방지하기 위해 모든 컨테이너에 CPU 및 메모리 요청과 제한을 정의하십시오.
배포 시점 정책이 시행되면 워크로드는 최소 권한과 기본 거부 네트워킹 하에서 실행됩니다. 그러나 이러한 가드레일이 의존하는 신뢰는 여전히 컨트롤 플레인과 그 아래 노드에 있으므로, 다음으로 이를 하드닝해야 합니다.
컨트롤 플레인 및 워커 노드 보호
컨트롤 플레인은 단 하나의 약한 설정이 다른 모든 것에 영향을 미치는 유일한 위치입니다. 다음 각각을 구성한 뒤, 부트스트랩 시 한 번만이 아니라 일정에 따라 검증하십시오.
| 하드닝 단계 | 구성할 항목 | 출처 |
| API 서버 액세스 | 강력한 인증과 상호 TLS를 요구하고, API 서버를 공용 인터넷에서 분리하십시오. | CIS Benchmark |
| 익명 인증 | --anonymous-auth=false 설정 | CISA/NSA guidance |
| 감사 로깅 | API 감사, 메트릭, 애플리케이션, seccomp 로그를 활성화하고, 이를 클러스터 외부로 집계하며, 이에 대한 경고를 설정하십시오 | CISA/NSA guidance |
| etcd | 저장 시 암호화를 적용하고, 상호 TLS를 요구하며, API 서버만 접근할 수 있도록 방화벽 뒤에 격리하십시오 | CIS Benchmark |
| kubelet | API 액세스를 제한하고, 읽기 전용 포트를 비활성화하며, 노드 수준 구성을 적용하십시오 | CIS Benchmark |
| 노드 기준선 | 사용 중인 릴리스에 맞춰 컨트롤 플레인, etcd, 노드를 CIS Kubernetes Benchmark에 정렬하고, 지속적인 주기로 스캔하십시오 | CIS Benchmark |
| 버전 | Kubernetes, 노드 OS, 컨테이너 런타임을 정기적인 주기로 패치하십시오 | — |
컨트롤 플레인을 잠그고 노드를 패치하면 기반이 유지됩니다. 그러나 라이브 워크로드는 선언된 상태에서 드리프트하거나 내부에서 공격받을 수 있으며, 이를 포착하는 것이 런타임 통제입니다.
런타임 보안 및 위협 탐지
강력한 Kubernetes 런타임 보안은 정적 통제로는 포착할 수 없는 것을 잡아냅니다.
- 런타임 동작을 모니터링하십시오. 비정상적인 syscall, 예상치 못한 프로세스 실행, 네트워크 연결, 파일 수정 사항을 감시하는 컨테이너 네이티브 런타임 보안 도구를 배포하십시오. NIST SP 800-190은 기존 침입 방지 시스템(IPS) 및 웹 애플리케이션 방화벽(WAF) 도구가 컨테이너에 적합한 보호를 제공하지 않는다고 명시합니다.
- 구성 드리프트를 탐지하십시오. 실행 중인 워크로드를 Git에 선언된 상태와 비교하십시오. 원래 이미지 또는 구성에서 벗어난 컨테이너를 표시하십시오.
- seccomp 및 AppArmor 또는 SELinux 프로필을 적용하십시오. 최소한
RuntimeDefaultseccomp 프로필을 사용하십시오. 먼저 일부 노드에 사용자 지정 프로필을 배포한 뒤 검증 후 클러스터 전체로 확장하십시오. - 읽기 전용 루트 파일 시스템을 실행하고 불필요한 capability를 제거하십시오. 모든 프로덕션 컨테이너에
readOnlyRootFilesystem: true및capabilities: drop: [ALL]를 설정하십시오. - runAsNonRoot를 시행하십시오. Pod 보안 컨텍스트에서
runAsNonRoot: true를 요구하십시오. 배포 시점 오버라이드에만 의존하지 말고, 빌드 시점에 비루트 사용자로 실행되도록 이미지를 빌드하십시오. - 자율 대응 및 지속적인 감사 로깅을 활성화하십시오. 공격 타임라인을 재구성하기 위해 런타임 경고를 감사 로그와 상관 분석하십시오. 루프를 닫기 위해 결과를 빌드 시점 정책에 다시 반영하십시오.
이 네 단계가 함께 지속적으로 하드닝된 클러스터를 만듭니다. 업계 벤치마크는 각 단계에서 "올바르게 구성됨"이 무엇인지 설명하며, 클러스터를 이에 맞춰 측정해야 합니다.
Kubernetes 보안 표준 및 컴플라이언스
업계에서 인정받는 벤치마크는 위에서 설명한 실천 방법을 운영화하고, Kubernetes 컴플라이언스 프로그램에 필요한 감사 증적을 제공합니다.
| 표준 | 범위 | 관련성 |
| 컨트롤 플레인, etcd, 워커 노드, 정책 | PCI DSS, FedRAMP, SOC 2, FISMA 및 NIST National Checklist Program에서 인정 | |
| 빌드, 배포, 네트워크, RBAC, 로깅, 런타임 | 연방 및 중요 인프라 클러스터를 위한 권위 있는 정부 기준선 | |
| 세 가지 계층 전반의 pod 수준 권한 제한 | Kubernetes 내장 시행 메커니즘이며 CISA/NSA guidance Table I에 직접 매핑됨 | |
| 컨테이너 라이프사이클 보안 | 컨테이너 통제를 NIST SP 800-53 Rev 5 (AU-2, CM-2, SC-7, IR-4 등)에 매핑 |
이제 Kubernetes가 기본 프로덕션 플랫폼이 되면서, 컴플라이언스 프레임워크는 점점 더 Kubernetes 특화 통제를 일반 인프라 보안의 하위 집합이 아니라 별도의 감사 영역으로 취급하고 있습니다.
CIS GKE Benchmark 및 CIS OpenShift Benchmark와 같은 플랫폼별 벤치마크는 관리형 서비스별 통제로 일반 벤치마크를 확장합니다. 표준을 아는 것은 기준선입니다. 더 어려운 질문은 Kubernetes 보안이 다음에 어디로 향하는가입니다.
Kubernetes 보안의 미래 동향
오늘 배포하는 통제는 변화하는 기반 위에 놓여 있으며, 세 가지 동향이 팀이 Kubernetes 보안 모범 사례에 접근하는 방식을 재편하고 있습니다.
- AI 워크로드가 공격 표면을 이동시킵니다. 클러스터가 AI 및 머신러닝 워크로드의 기본 실행 환경이 되면서 GPU 스케줄링, 모델 아티팩트, 대규모 학습 데이터셋이 새로운 표적이 됩니다. 데이터와 모델 공급망 보호는 별도의 문제가 아니라 클러스터 하드닝의 일부가 되고 있습니다.
- 소프트웨어 공급망 무결성이 필수가 됩니다. SBOM 생성, 서명된 아티팩트, 출처 증명은 규제 산업과 정부 조달에서 선택적 성숙도 지표에서 기준선 기대치로 이동하고 있습니다.
- 자율 런타임 방어가 수동 트리아지를 대체합니다. 클러스터 활동의 양과 속도는 사람의 검토 능력을 앞지릅니다. 정상과 비정상 워크로드 활동을 구분하고 분석가를 기다리지 않고 대응하는 행동 기반 AI는 차별화 요소에서 기본값으로 이동하고 있습니다.
각 동향은 같은 방향을 가리킵니다. 라이프사이클 초기에 더 많은 자동화, 런타임에서 더 많은 자율성이 필요하며, 바로 그 지점에서 플랫폼 도구가 가치를 입증합니다.
SentinelOne으로 Kubernetes 보안 강화
이 가이드에서 다룬 Kubernetes 기본 통제인 RBAC, NetworkPolicy, Pod Security Standards, etcd 암호화, 감사 로깅은 클러스터 하드닝의 기반을 형성합니다. SentinelOne은 이 가이드에서 언급한 약점 각각에 매핑되는 태세 관리, 공급망 스캐닝, K8s admission control, 런타임 위협 탐지를 그 위에 추가합니다.
Singularity Cloud Security는 Kubernetes 클러스터가 실행되기 전에 이를 스캔합니다. 빌드 시점 스캐닝은 CI/CD 파이프라인, 버전 관리 시스템, 컨테이너 레지스트리와 직접 통합됩니다. 알려진 취약점과 750개 이상의 노출된 비밀 정보 유형을 검사합니다. 동일한 스캔은 Terraform, Helm, CloudFormation, Kubernetes YAML을 포함한 infrastructure-ascode 템플릿도 다루어 정책 위반을 조기에 포착합니다. Kubernetes Admission Controller는 API 서버의 최종 게이트키퍼 역할을 하며, 승인되지 않았거나 알려진 악성 이미지를 배포 전에 차단합니다.
Kubernetes Security Posture Management (KSPM)는 클러스터 전반의 가시성 격차를 해소합니다. 클러스터, 노드, 네임스페이스, 배포 전반에 걸쳐 통합 인벤토리를 구축한 뒤, 과도하게 허용적인 액세스와 위험한 구성을 드러냅니다. 이어서 Offensive Security Engine™이 실제 공격을 시뮬레이션하여, Verified Exploit Paths™를 통해 공격자가 실제로 도달 가능한 오구성을 확인합니다. 보안 팀은 모든 결과를 트리아지하는 대신 실제 악용 가능한 항목의 우선순위를 정합니다. 동일한 규칙 엔진이 Admission Controller도 구동하므로, 태세에서 배포까지 정책 일관성이 유지됩니다.
런타임에서 Singularity Cloud Workload Security는 extended Berkeley Packet Filter (eBPF)를 기반으로 머신 속도로 비정상 동작을 탐지합니다. 자동화된 대응은 분석가를 기다리지 않고 악성 프로세스를 종료하고 감염된 파일을 격리합니다. Graph Explorer는 Kubernetes 공격 표면 전반의 관계를 시각화하여 팀이 정확히 무엇이 노출되었는지 확인할 수 있게 합니다. 런타임 탐지가 악성 이미지를 표시하면, 해당 결과는 자동으로 Admission Controller에 다시 반영됩니다. 그러면 해당 이미지는 이후의 모든 배포에서 차단되어, 한 번의 탐지가 지속적인 정책으로 전환됩니다. Purple AI는 하나의 데이터 레이크에서 클라우드 워크로드 텔레메트리에 대해 자연어 기반 threat hunting과 이벤트 요약을 제공하므로, 분석가는 도구 간 전환 대신 평문 언어로 질의할 수 있습니다.
프로덕션에서 클러스터가 어디에 노출되어 있는지 확인하십시오. SentinelOne 데모 요청을 통해 자체 환경에서 Kubernetes 태세 관리와 런타임 위협 탐지를 살펴보십시오.
서버, VM, 컨테이너를 위한 AI 기반 클라우드 워크로드 보호(CWPP)로, 런타임 위협을 실시간으로 탐지하고 차단합니다.
핵심 요약
Kubernetes는 허용적인 기본 설정으로 제공되며, 클러스터 보안은 사용자 책임으로 남겨집니다. 이 가이드의 Kubernetes 보안 모범 사례는 네 단계에 걸쳐 있습니다: 빌드 시 이미지 스캐닝 및 서명, 배포 시 RBAC 및 NetworkPolicy, 컨트롤 플레인에서의 etcd 암호화 및 감사 로깅, 런타임에서의 행동 기반 모니터링입니다.
구성을 CIS Benchmark 및 CISA/NSA guidance에 맞추고, 위에서 식별한 일반적인 실수를 제거하며, 런타임 결과를 빌드 시점 정책에 다시 반영해 루프를 닫으십시오. 그 단계에 도달하면 더 이상 추측할 필요가 없습니다. 어느 날이든 어떤 네임스페이스든 가리키며 무엇이 시행되고 있는지, 무엇이 드리프트했는지, 그리고 이에 대해 무엇을 했는지 보여줄 수 있습니다.
FAQ
모든 새 Kubernetes 클러스터에는 세 가지 설정이 안전하지 않은 상태로 제공됩니다. CISA/NSA Kubernetes Hardening Guidance v1.2에서 이를 문서화하고 있습니다. 익명 API 서버 로그인이 활성화되어 있고, Secrets는 암호화되지 않은 상태로 etcd에 저장되며, 감사 로깅은 비활성화되어 있습니다.
NetworkPolicy 객체가 없으면 Pod 간 통신은 제한되지 않습니다. 이러한 항목은 직접 강화해야 합니다. 공동 책임 모델에 따라 클라우드 제공업체나 Kubernetes 배포판은 이러한 제어를 대신 적용하지 않습니다.
컨테이너 보안과 Kubernetes 보안은 동일한 스택의 서로 다른 계층에서 작동합니다. 컨테이너 보안은 이미지와 컨테이너 인스턴스에 중점을 둡니다: 취약점 스캐닝, 런타임 격리, capability 제거, 그리고 호스트 커널 보호.
Kubernetes 보안은 개별 컨테이너와 이를 둘러싼 클러스터 모두에 걸쳐 적용되며, RBAC, admission control, 네트워크 정책, etcd, 그리고 오케스트레이션 감사 로깅을 추가합니다. 컨테이너 보안은 더 광범위한 Kubernetes 보안 분야에 포함됩니다.
Pod Security Policies (PSPs)는 Kubernetes v1.21에서 더 이상 사용되지 않게 되었고 v1.25에서 제거되었습니다. Pod Security Standards (PSS)는 세 가지 정책 계층(Privileged, Baseline, Restricted)을 정의하며, 라벨을 통해 네임스페이스 수준에서 정책을 적용하는 기본 제공 admission controller인 Pod Security Admission (PSA)에 의해 시행됩니다.
PSA는 v1.25에서 안정화 단계에 도달했습니다. 클러스터가 v1.25 이상에서 실행 중이고 PSA를 구성하지 않았다면, Pod 수준 시행 계층 없이 운영 중인 것입니다.
Kubernetes 클러스터에는 네 가지 주요 규정 준수 프레임워크가 적용됩니다. CIS Kubernetes Benchmark는 PCI DSS, FedRAMP, SOC 2 및 FISMA에서 인정됩니다. CISA/NSA Kubernetes Hardening Guidance는 정부 기준선 역할을 합니다.
NIST SP 800-190은 컨테이너 제어를 NIST SP 800-53 Rev 5 제어 계열에 매핑합니다. Pod Security Standards는 CISA/NSA 지침에 직접 매핑되는 기본 제공 시행 메커니즘을 제공합니다.
관리형 Kubernetes 서비스는 컨트롤 플레인 가용성, 패치 적용 및 일부 인프라 보안을 처리합니다. 여전히 RBAC 정책, NetworkPolicy 객체, Pod Security Admission, Secrets 암호화 및 런타임 모니터링은 사용자의 책임입니다.
공유 책임 모델이 적용됩니다. 즉, 공급자는 컨트롤 플레인 인프라를 보호하고, 사용자는 워크로드, 구성 및 액세스 제어를 보호합니다. 플랫폼별 CIS Benchmarks에는 각 관리형 서비스에 적용해야 하는 추가 제어가 문서화되어 있습니다.
