Applied Kubernetes Hardening: A Practical Playbook

Kubernetes는 기본적으로 유연성을 가지고 배포되며, 보안은 고려 대상이 아닙니다. 모든 열린 포트, 관대한 RBAC 역할, 제한 없는 파드는 초대장입니다. 클러스터를 강화한다는 것은 이러한 틈을 체계적으로 메우면서도 의존하는 워크로드를 깨뜨리지 않는 것입니다. 이것은 체크리스트 작업이 아니라 신원, 네트워크, 워크로드, 공급망 계층에 걸쳐 있는 지속적인 규율입니다.

먼저 컨트롤 플레인을 잠그세요

API 서버는 모든 클러스터에서 가장 가치 있는 대상입니다. 익명 인증을 비활성화하고 강력한 인증 방법을 적용하는 것으로 시작하세요. 정적 토큰이나 만료되지 않는 클라이언트 인증서보다는 신원 제공자와의 OIDC 통합이 선호됩니다. etcd 데이터스토어에 대한 접근을 제한하세요. 암호화 저장소가 활성화되지 않으면 모든 시크릿과 설정 객체가 평문으로 보관됩니다. base64 인코딩을 신뢰하지 말고 KMS 제공자를 사용해 시크릿을 암호화하세요. base64 인코딩은 실제 보호를 제공하지 않습니다. 처음부터 감사 로깅을 활성화하세요. 이것이 없으면 문제가 발생했을 때 포렌식 기록이 없습니다.

RBAC: 편의성이 아닌 최소 권한

프로덕션 클러스터에서 가장 흔한 설정 오류는 너무 광범위한 RBAC 바인딩입니다. 한 네임스페이스의 파드만 읽으면 되는 서비스 계정에 cluster-admin을 부여합니다. 실제 업무 기능 주변으로 역할을 구성하고 가능한 한 네임스페이스로 범위를 제한하세요. Role과 ClusterRole 정의에서 와일드카드 동사와 리소스를 피하세요. kubectl auth can-i --list 또는 rbac-lookup과 같은 도구로 바인딩을 정기적으로 감사해 권한 확산을 잡으세요. 서비스 계정은 사용자와 동일한 정밀성이 필요합니다. API 접근이 필요 없는 파드의 서비스 계정 토큰 자동 마운트를 비활성화하세요.

파드 보안: 침해를 가정하세요

Pod Security Admission(더 이상 사용되지 않는 PodSecurityPolicy를 대체함)을 사용하면 네임스페이스 수준에서 기본 또는 제한된 프로필을 적용할 수 있습니다. 최소한 권한 있는 컨테이너, 호스트 네임스페이스 공유, 권한 상향을 허용하지 마세요. runAsNonRoot: true를 설정하고 기본적으로 모든 Linux 기능을 제거한 후 명시적으로 필요한 것만 다시 추가하세요. 읽기 전용 루트 파일시스템은 공격자가 실행 중인 컨테이너에 악의적인 바이너리를 쓰는 것을 방지합니다. 이러한 제어는 중요합니다. 컨테이너 탈출이나 악용된 애플리케이션 취약점이 전체 노드 침해로 이어지지 않아야 하기 때문입니다.

네트워크 정책은 선택 사항이 아닙니다

기본적으로 Kubernetes 클러스터의 모든 파드는 다른 모든 파드와 통신할 수 있습니다. 이러한 평면 네트워크 모델은 공격자의 횡적 이동 꿈입니다. NetworkPolicy 리소스를 구현해 기본적으로 수신 및 송신을 거부한 후 애플리케이션이 필요로 하는 트래픽 흐름만 명시적으로 허용하세요. 이는 실제로 NetworkPolicy 적용을 지원하는 CNI 플러그인이 필요합니다. Calico, Cilium 등이 이 역할을 수행합니다. 기본 Kubernetes 네트워크 모델은 자체적으로 아무것도 적용하지 않습니다. 신뢰 경계별로 네임스페이스를 분할하고 정책을 위에 계층화하면 진정한 심층 방어를 얻을 수 있습니다.

이미지 및 공급망 무결성

강화는 런타임 설정으로 끝나지 않으며, 배포하는 것으로 시작합니다. 컨테이너 이미지를 레지스트리에 도달하기 전에 알려진 취약점을 검사하고, Kyverno 또는 OPA Gatekeeper와 같은 승인 컨트롤러를 사용해 서명되고 검증된 이미지만 클러스터에서 실행되도록 강제하세요. 이미지 태그를 latest와 같은 변경 가능한 태그 대신 다이제스트로 고정하세요. 다이제스트는 무언가 변해도 모를 수 있습니다. 파드가 풀 수 있는 레지스트리를 제한해 손상되거나 오타로 된 이미지가 프로덕션에 유입되는 공통 공급망 공격 경로를 차단하세요.

Kubernetes 기본값을 넘어선 시크릿 관리

네이티브 Kubernetes Secrets는 없는 것보다 낫지만, 진정한 시크릿 관리 솔루션은 아닙니다. 외부 시크릿 관리자(Vault, AWS Secrets Manager 등)를 통합하고 클러스터 객체로 저장하지 말고 런타임에 시크릿을 주입하세요. 네이티브 Secrets를 반드시 사용해야 한다면, etcd 암호화가 활성화되어 있고 RBAC이 읽기 접근을 엄격히 제한하는지 확인하세요. 네임스페이스의 시크릿에 get 권한이 있는 모든 파드 또는 사용자가 자격 증명을 유출할 수 있기 때문입니다.

일회성 설정이 아닌 지속적 검증

강화 설정은 새 워크로드가 배포되고 우선 순위가 보안보다 속도로 이동하면서 시간이 지나면서 표류합니다. kube-bench는 CIS Kubernetes Benchmark를 기준으로 준수 여부를 확인하고, kube-hunter는 클러스터에 대한 공격자 정찰을 시뮬레이션할 수 있습니다. 이러한 검사를 CI/CD 파이프라인에 포함시켜 인시던트 대응 전화 중이 아니라 프로덕션에 도달하기 전에 설정 오류를 잡으세요.

Kubernetes 강화는 단일한 은탄환 제어에 관한 것이 아니라 신원, 네트워크, 워크로드, 공급망에 걸쳐 방어를 계층화하는 것입니다. 따라서 한 계층의 장애가 전체 침해로 이어지지 않습니다. 클라우드 인프라 보안 패턴 및 방어 도구에 대한 자세한 내용은 Korra Studio의 DEFENSE_GRID 플랫폼에서 관련 세그먼트를 살펴보세요.