Kubernetes 보안: RBAC, 네트워크 정책 및 파드 보안

Kubernetes는 컨테이너화된 작업을 대규모로 오케스트레이션하지만, 복잡성 때문에 공격 표면이 넓습니다. 보안을 유지해야 하는 주요 구성 요소는 다음과 같습니다. API 서버(중앙 제어 플레인으로, 이 부분이 침해되면 전체 클러스터를 제어할 수 있음), etcd(클러스터 상태 데이터베이스로, 비밀을 base64로 저장하므로 저장 데이터를 암호화해야 함), kubelet(노드 에이전트로, 인증되지 않은 kubelet API를 사용하면 임의의 Pod를 실행할 수 있음), 컨테이너 실행 환경(Docker/containerd), 그리고 모든 Pod를 연결하는 네트워크 패브릭입니다. Security+ 응시자는 Kubernetes의 잘못된 구성이 클라우드 보안에서 가장 흔하게 발견되는 문제 중 하나라는 점을 이해해야 합니다.

Kubernetes RBAC(역할 기반 접근 제어)는 사용자, 서비스 계정, 프로세스가 어떤 API 리소스에 어떤 작업을 수행할 수 있는지 제어합니다. 이 모델에는 네 가지 객체가 있습니다. Role(네임스페이스 범위 권한), ClusterRole(클러스터 전체 권한), RoleBinding(네임스페이스 내 주체에 Role 부여), ClusterRoleBinding(클러스터 전체에서 주체에 ClusterRole 부여)입니다. 모든 kubectl 명령은 RBAC 규칙에 따라 확인되는 API 호출로 변환됩니다. RBAC가 구성되지 않으면 인증된 사용자 또는 서비스 계정이 관리자 권한을 가질 수 있습니다.

Kubernetes의 모든 Pod는 API 인증에 사용되는 ID인 서비스 계정으로 실행됩니다. 기본적으로 Pod는 해당 네임스페이스의 default 서비스 계정을 사용하며, 이 계정에는 광범위한 권한이 있을 수 있습니다. 최소 권한 원칙을 따르려면 각 애플리케이션에 필요한 권한만 가진 전용 서비스 계정을 만들어야 합니다. 또한 API 접근이 필요하지 않은 Pod에 automountServiceAccountToken: false를 설정하면 서비스 계정 토큰이 Pod 파일 시스템에 마운트되지 않습니다. 이렇게 하면 침해된 애플리케이션이 해당 토큰을 사용하여 API를 호출하는 것을 막을 수 있습니다.

Kubernetes에서는 기본적으로 모든 Pod가 어떤 네임스페이스에 있는 다른 모든 Pod와 통신할 수 있습니다. 침해된 Pod는 데이터베이스, 내부 API, 다른 마이크로서비스에 즉시 접근을 시도할 수 있습니다. Kubernetes NetworkPolicy 리소스는 레이블, 네임스페이스, 포트를 기준으로 Pod 간 트래픽을 제한하는 규칙을 정의합니다. 권장되는 방식은 각 네임스페이스에 '모두 기본 거부' 네트워크 정책을 적용한 다음, 필요한 통신 경로에 대해서만 명시적인 허용 규칙을 추가하는 것입니다. NetworkPolicy를 사용하려면 이를 지원하는 CNI 플러그인(Calico, Cilium, Weave)이 필요합니다. 호환되는 CNI가 없으면 기본 Kubernetes는 NetworkPolicy를 무시합니다.

Pod Security Standards(PSS)는 Kubernetes 1.23에서 도입되고 1.25에서 안정화되었으며, 더 이상 사용되지 않는 Pod Security Policy(PSP)를 네임스페이스 수준에서 적용되는 세 가지 기본 제공 프로필로 대체합니다. Privileged(제한 없음, 시스템 구성 요소용), Baseline(권한 있는 컨테이너 및 호스트 네트워크 접근과 같은 알려진 권한 상승 방지), Restricted(강화된 프로필로, root가 아닌 사용자 사용, 모든 기능 제거, 읽기 전용 root 파일 시스템 적용)입니다. 네임스페이스에 레이블을 지정하여 정책 수준을 적용하며, 이를 위반하는 Pod는 승인 단계에서 거부됩니다.

Kubernetes Secrets는 비밀번호, 토큰, TLS 인증서와 같은 민감한 데이터를 저장합니다. 기본적으로 Secrets는 base64로 인코딩된 값으로 etcd에 저장되며 암호화되지 않습니다. etcd를 읽을 수 있거나 충분한 RBAC 권한이 있는 사람은 누구나 이를 쉽게 디코딩할 수 있습니다. 모범 사례에는 AES-GCM을 사용하여 etcd의 저장 데이터를 암호화하고 키를 KMS(AWS KMS, GCP KMS)에 저장하는 방법, HashiCorp Vault 또는 AWS Secrets Manager와 같은 외부 비밀 관리자와 Secrets Store CSI Driver를 통해 연동하는 방법, 그리고 필요한 서비스 계정만 읽을 수 있도록 RBAC를 통해 Secret 접근을 제한하는 방법이 있습니다.

승인 컨트롤러는 Kubernetes API 서버의 플러그인으로, 인증과 권한 부여가 끝난 후 객체가 저장되기 전에 API 요청을 가로챕니다. 이를 통해 요청을 검증하거나 변경하거나 거부할 수 있습니다. 보안과 관련된 승인 컨트롤러에는 다음이 있습니다. PodSecurity(Pod 보안 표준 적용), ImagePolicyWebhook(외부 이미지 서명 검증 허용), AlwaysPullImages(로컬에 캐시된 악성 이미지 사용을 막기 위해 항상 새 이미지를 가져오도록 강제), OPA/Gatekeeper(Open Policy Agent로, 가장 유연하며 Rego 언어로 표현한 사용자 지정 정책을 사용하여 조직의 보안 규칙을 적용)입니다.

Kubernetes 제어 플레인 구성 요소를 강화하는 것은 매우 중요합니다. API 서버에는 인증되지 않은 접근을 차단하도록 --anonymous-auth=false를 설정하고, 모든 API 활동을 기록하도록 --audit-log-path를 구성하며, 모든 연결에 TLS를 사용해야 합니다. kubelet에는 --authorization-mode=Webhook(AlwaysAllow가 아님)을 설정하고 익명 인증을 비활성화해야 합니다. etcd에는 TLS 피어 및 클라이언트 암호화, 제한된 네트워크 접근(API 서버만 접근 가능), 저장 데이터 암호화를 적용해야 합니다. CIS Kubernetes Benchmark는 모든 구성 요소 설정을 점검하는 종합 체크리스트를 제공합니다.

Kubernetes 네임스페이스는 리소스를 논리적으로 분리하지만, 그 자체로 강력한 보안 경계를 제공하지는 않습니다. 주로 조직상의 격리를 제공할 뿐입니다. 진정한 멀티테넌트 격리(예: 서로 다른 고객의 작업)를 위해서는 추가 제어가 필요합니다. 여기에는 네임스페이스 간 트래픽을 차단하는 네트워크 정책, 특정 사용자가 리소스를 과도하게 사용하여 발생하는 DoS를 방지하는 리소스 할당량, 강력하게 격리된 테넌트를 위한 별도 노드 풀, 테넌트별 전용 클러스터가 있습니다. 많은 조직에서는 하나의 클러스터 안에서 더 강력한 멀티테넌시를 구현하기 위해 Hierarchical Namespaces 또는 vCluster와 같은 상용 솔루션을 사용합니다.

Kubernetes 감사 로깅은 모든 API 요청을 기록합니다. 누가 요청했는지, 어디에서 요청했는지, 어떤 Action을 요청했는지, 어떤 Resource를 대상으로 했는지를 기록합니다. 감사 로그는 보안 사고 후 포렌식 조사와 비정상적인 역할 바인딩, Secret 접근, 프로덕션 Pod에 대한 exec 명령과 같은 이상 동작을 탐지하는 데 필수적입니다. 감사 로그는 중앙 집중식 SIEM으로 스트리밍해야 합니다. Falco는 컨테이너 동작에 대한 런타임 모니터링을 제공하며, 클라우드 관리형 Kubernetes 서비스(EKS, GKE, AKS)는 각각의 로깅 플랫폼과 기본적으로 감사 로그를 통합합니다.

Kubernetes의 소프트웨어 공급망 보안은 신뢰할 수 있고 검증된 이미지만 프로덕션에 도달하도록 보장합니다. CNCF의 소프트웨어 공급망 보안 권장 사항에는 배포 전에 Cosign으로 이미지 서명을 검증하는 것(어드미션 컨트롤러를 통해 강제), 모든 컨테이너 이미지에 대해 SBOM(소프트웨어 자재 명세서)을 생성하고 검증하여 구성 요소의 출처를 추적하는 것, 변경 가능한 태그 대신 다이제스트(myimage@sha256:abc123)로 이미지를 고정하는 것, 배포 전에 모든 타사 Helm 차트에서 잘못된 구성과 취약점을 검사하는 것이 포함됩니다.

이 lesson에서 다룬 CompTIA Security+ (SY0-701) 개념에 대한 이해도를 확인해 보세요.

이 lesson에서는 다음을 배웠습니다. Kubernetes RBAC는 Roles, ClusterRoles, Bindings를 통해 API 접근을 제어하므로 서비스 계정에는 항상 최소 권한을 적용해야 합니다. NetworkPolicy 기본 거부 구성은 Pod와 네임스페이스 사이의 측면 이동을 방지하며, Pod Security Standards는 네임스페이스 수준에서 컨테이너 강화를 적용하여 권한 있는 컨테이너, 호스트 네트워크 접근, root 실행을 차단합니다. 다음으로는 서버리스 보안과 함수 수준의 공격 표면을 살펴봅니다.