[번역/정리] Kubernetes Hardening Guidance by NSA & CISA

https://media.defense.gov/2022/Aug/29/2003066362/-1/-1/0/CTR_KUBERNETES_HARDENING_GUIDANCE_1.2_20220829.PDF

 

 

이 문서는 쿠버네티스 클러스터의 보안 강화 가이드라인을 제공합니다. 주요 내용은 다음과 같습니다. 컨테이너 보안 강화, 네트워크 분리및 강화, 컨트롤 플레인강화, 인증 및 권한 부여, 감사 로깅및 위협 탐지, 업그레이드 및 애플리케이션 보안 사례 등입니다. 이 가이드는 시스템 관리자와 개발자가 쿠버네티스를 안전하게 배포하고 관리하는 데 도움을 주어, 보안 취약점을 줄이고 악의적인 활동으로부터 보호하는 것을 목표로 합니다. 궁극적으로 쿠버네티스 환경에서 발생할 수 있는 다양한 위협에 대한 종합적인 보안 전략을 제시합니다.

1. 🔐 쿠버네티스 시스템의 개요와 보안 권고사항

• 쿠버네티스(K8s)는 컨테이너화된 애플리케이션의 배포, 확장, 관리를 자동화하는 오픈소스 시스템으로, 마이크로서비스부터 전체 클러스터까지 모든 요소를 관리한다
• 주요 보안 위협은 공급망 위험, 악의적 위협 행위자, 내부자 위협이며, 특히 공급망 위험은 컨테이너 빌드 주기나 인프라 획득 과정에서 발생할 수 있다
• 보안 강화를 위해 컨테이너와 Pod의 취약점 스캔, 최소 권한 실행, 네트워크 분리, 강력한 인증/권한 부여, 감사 로그 모니터링, 정기적인 설정 검토가 필요하다
• 컨트롤 플레인은 클러스터에 대한 의사결정을 담당하며, 컨테이너 스케줄링, 장애 감지/대응, Pod복제본 관리 등의 기능을 수행한다
• 클러스터는 여러 개의 컨트롤 플레인과 하나 이상의 워커 노드로 구성되며, 워커 노드는 하나 이상의 컨테이너를 포함하는 Pod를 호스팅한다

1.1. 쿠버네티스 보안 강화 가이드 문서 개요

• 이 문서는 미국 국가안보국(NSA)과 사이버보안 및 기반시설 보안국(CISA)이 공동 개발한 쿠버네티스 보안 강화 지침이다
• 문서의 주요 목적은 사이버 보안 사양과 완화 방안을 개발하고 발행하는 것으로, 모든 관련 이해관계자들에게 공유될 수 있다
• 보안 관련 문의는 사이버보안 요구사항 센터를 통해, 사고 대응 리소스는 CISA 서비스 데스크를 통해 지원받을 수 있다
• 이 가이드는 산업계의 피드백을 반영하여 지속적으로 업데이트되며, 현재 버전 1.2(2022년 8월)까지 발행되었다
• 문서의 모든 정보와 의견은 "있는 그대로" 제공되며, 특정 상업 제품이나 서비스에 대한 정부의 보증이나 승인을 의미하지 않는다

1.2. 쿠버네티스의 주요 보안 위협과 대응 방안

• 쿠버네티스는 컨테이너화된 애플리케이션의 배포, 확장, 관리를 자동화하는 오픈소스 시스템으로, 기존 모놀리식 플랫폼 대비 유연성과 보안상의 이점을 제공한다
• 주요 보안 위협은 공급망 리스크, 악의적 위협 행위자, 내부자 위협 세 가지로, 특히 공급망 리스크는 컨테이너 빌드 주기나 인프라 획득 과정에서 발생할 수 있다
• 보안 강화를 위해 컨테이너와 파드의 취약점 스캔, 최소 권한 원칙 적용, 네트워크 분리, 방화벽사용, 암호화구현이 필요하다
• 관리자와 사용자의 접근 제한을 위한 강력한 인증과 인가, 잠재적 악성 활동 탐지를 위한 감사 로그 모니터링이 중요하다
• 보안 위험의 적절한 관리를 위해 쿠버네티스 설정을 정기적으로 검토하고 취약점 스캔을 수행해야 한다

1.3. 쿠버네티스 보안 강화 가이드의 주요 구성

• 이 문서는 미국 국가안보국(NSA)과 사이버보안 인프라 보안국이 작성한 쿠버네티스 보안 강화 지침이다
• 가이드는 아키텍처 개요, 위협 모델, 파드 보안, 네트워크 분리 등의 핵심 주제를 다룬다
• 컨테이너 보안과 관련하여 Non-root 컨테이너, 불변 파일시스템, 보안 이미지 구축 등의 상세 지침을 포함한다
• 네임스페이스, 네트워크 정책, 리소스 정책을 통한 시스템 보안 강화 방안을 제시한다
• 파드 보안 강제, 서비스 계정 토큰 보호, 컨테이너 환경 강화 등 구체적인 보안 실행 방안을 설명한다

1.4. 쿠버네티스 보안 관리 주요 영역

• 컨트롤 플레인 강화, etcd, kubeconfig 파일 관리는 쿠버네티스 시스템의 기본적인 보안 요소다
• 워커 노드 분리와 암호화, 시크릿 관리를 통해 클라우드 인프라의 민감한 정보를 보호한다
• 인증과 역할 기반 접근 제어(RBAC)를 통해 시스템 접근을 제어한다
• 감사 로깅과 위협 탐지는 시스콤프, 시스로그, SIEM 플랫폼을 활용하여 구현한다
• 서비스 메시와 장애 허용 시스템을 통해 보안성과 안정성을 확보한다

1.5. 쿠버네티스 보안 가이드 부록 및 예시 목록

• 부록(Appendix) 섹션에는 non-root 애플리케이션용 Dockerfile, 읽기 전용 파일시스템 배포 템플릿, 네임스페이스, 네트워크 정책등의 실제 구현 예시가 포함되어 있다
• 보안 정책 관련 예시로는 Pod보안 정책, LimitRange, ResourceQuota, 암호화설정, KMS 구성이 제공되어 있다
• 접근 제어와 감사 관련 예시로는 RBAC Role, RoleBinding, ClusterRoleBinding, 감사 정책, 감사 로깅활성화를 위한 플래그 설정이 포함되어 있다
• 문서는 도구(Tools), 업그레이드, 애플리케이션 보안 사례, 참고 문헌 등의 추가 섹션을 포함하고 있다

1.6. 쿠버네티스 소개와 보안 가이드의 목적

• 쿠버네티스(K8s)는 컨테이너화된 애플리케이션의 배포, 확장, 관리를 자동화하는 오픈소스 컨테이너 오케스트레이션시스템이다
• 쿠버네티스는 마이크로서비스부터 전체 클러스터까지 모든 요소를 관리하며, 마이크로서비스 기반 컨테이너화된 애플리케이션은 기존 모놀리식 플랫폼보다 유연성과 보안상의 이점을 제공한다
• 이 보안 가이드는 국가 보안 시스템과 중요 인프라의 관리자들을 위한 보안 문제 해결과 강화 전략을 제시한다
• 문서는 클러스터 구성요소, 컨테이너 공급망 의존성, 포드 컴포넌트, 컨테이너 빌드 워크플로우, 역할 기반 접근 제어, 서비스 메시통합 등 다양한 보안 관련 요소들을 다룬다

1.7. 쿠버네티스 보안 강화를 위한 핵심 권장사항

• 쿠버네티스 파드 보안을 위해 non-root 사용자로 컨테이너를 실행하고, 변경 불가능한 파일 시스템을 사용하며, 컨테이너 이미지의 취약점을 스캔해야 한다
• 기술적 제어를 통해 특권 컨테이너 방지, hostPID/hostIPC/hostNetwork 같은 컨테이너 탈출 기능 차단, 루트 권한 실행 거부 등 최소한의 보안 수준을 강제해야 한다
• 네트워크 보안을 위해 방화벽과 RBAC으로 제어 평면 노드 접근을 제한하고, TLS 인증서를 사용한 암호화된 통신을 구성하며, 네트워크 정책으로 리소스를 격리해야 한다
• 인증 및 권한 부여는 익명 로그인을 비활성화하고, 강력한 사용자 인증을 사용하며, 사용자/관리자/개발자별로 고유한 RBAC 정책을 생성해야 한다
• 감사 로깅과 위협 탐지를 위해 감사 로깅을 활성화하고, 클러스터 API 감사 이벤트, 메트릭, 애플리케이션 로그 등을 외부에 집계하며, 모니터링 및 경고 시스템을 구현해야 한다

 

2. 🔒 쿠버네티스 클러스터의 구성요소와 위협 모델

• 쿠버네티스 컨트롤 플레인은 API 서버, etcd저장소, 스케줄러, 클라우드 컨트롤러 매니저로 구성되어 클러스터를 관리하고 제어한다
• 워커 노드는 컨테이너화된 애플리케이션을 실행하며, kubelet과 kube-proxy 서비스를 통해 컨트롤 플레인의 오케스트레이션을 지원한다
• 주요 위협 요인으로는 공급망 공격(컨테이너/애플리케이션, 런타임, 인프라 수준), 악의적인 외부 위협, 내부자 위협(관리자, 사용자, 클라우드 서비스 제공자)이 있다
• 데이터 탈취나 컴퓨팅 파워 도용( 암호화폐 채굴 등)을 목적으로 하는 공격자들이 쿠버네티스를 표적으로 삼는다
• 보안 강화를 위해서는 CSP의 기본 설정을 그대로 사용하지 말고, 인증 및 권한 부여 등의 보안 설정을 직접 관리해야 한다

2.1. 쿠버네티스의 핵심 구성요소와 역할

• 컨트롤 플레인은 클러스터 상태 관리, 파드 수 유지, 노드 손실 대응 등을 담당하며, 클라우드 컨트롤러 매니저는 클라우드 기반 배포 시 로드밸런서와 가상 네트워킹을 관리한다
• API 서버는 관리자가 쿠버네티스를 제어하는 인터페이스로, 컨트롤 플레인외부에 노출되며 확장 가능하도록 설계되어 있다
• etcd는 클러스터 상태 정보를 저장하는 영구 저장소이며, 스케줄러는 워커 노드의 상태를 추적하고 파드 실행 위치를 결정한다
• 워커 노드는 컨테이너화된 애플리케이션을 실행하는 물리적/가상 머신으로, kubelet과 kube-proxy를 통해 파드 실행 관리와 네트워크 라우팅을 수행한다
• CSP 쿠버네티스 서비스는 대부분의 관리 기능을 제공하지만, 기본 설정이 보안에 취약하므로 인증 및 권한 부여와 같은 보안 설정은 조직이 직접 관리해야 한다

2.2. 쿠버네티스 환경의 주요 위협 모델

• 쿠버네티스는 데이터 탈취나 컴퓨팅 파워 도용(주로 암호화폐 채굴 목적)의 주요 타겟이 되며, 서비스 거부 공격의 대상이 될 수 있다
• 공급망 공격은 다양하고 완화하기 어려운 위협으로, 시스템 구성 요소, 서비스, 인력 등 최종 제품에 관련된 모든 요소가 공격 대상이 될 수 있다
• 컨테이너/애플리케이션 수준에서는 개발자의 신뢰성과 개발 인프라 방어에 의존하며, 악성 컨테이너나 서드파티 애플리케이션이 클러스터 침투 경로가 될 수 있다
• 컨테이너 런타임은 각 노드에서 컨테이너 이미지 로드와 리소스 관리를 담당하며, 취약점 발생 시 컨테이너 간 격리가 불충분해질 수 있다
• 인프라스트럭처 수준에서는 워커 노드나 컨트롤 플레인을 구성하는 기반 시스템의 소프트웨어/하드웨어 의존성이 공격 진입점이 될 수 있다

2.3. 쿠버네티스 클러스터의 주요 공격 위협 요소

• 악의적 행위자는 원격에서 취약점을 악용하거나 사회공학적 방법으로 탈취한 인증정보를 이용해 시스템에 접근한다
• 컨트롤 플레인의 여러 구성 요소들은 클러스터를 추적하고 관리하기 위해 통신하는데, 적절한 접근 제어가 없을 경우 공격자들의 주요 표적이 된다
• 워커 노드는 컨테이너 엔진 외에도 kubelet과 kube-proxy 서비스를 호스팅하며, 컨트롤 플레인외부에 존재하여 공격자들이 더 쉽게 접근할 수 있다
• 클러스터 내부의 컨테이너화된 애플리케이션은 외부에서 접근 가능하여 공격자의 일반적인 표적이 되며, 이를 통해 공격자는 이미 침투한 Pod에서 권한 상승이나 내부 리소스 접근이 가능하다

2.4. 내부자 위협과 Pod 보안의 중요성

• 내부자 위협은 조직 내 개인에게 부여된 특별한 지식과 권한을 악용하여 쿠버네티스 클러스터를 공격할 수 있는 위험이다
• 관리자는 컨테이너 환경에서 임의의 명령을 실행할 수 있는 권한을 가지며, RBAC 인증으로 위험을 줄일 수 있지만 최소 하나의 관리자 계정은 클러스터 제어 권한을 가져야 한다
• 일반 사용자와 클라우드 서비스 제공자도 각각 컨테이너화된 서비스 접근 권한과 물리적 시스템 접근 권한을 통해 쿠버네티스 환경을 손상시킬 수 있다
• Pod는 가장 작은 쿠버네티스 배포 단위로, 사이버 공격자의 초기 실행 환경이 되기 쉬우므로 보안 강화가 필수적이다
• Pod보안 강화는 공격을 어렵게 만들고 성공적인 침해의 영향을 제한하는 것을 목표로 한다

2.5. 컨테이너 보안 강화를 위한 non-root 실행과 불변 파일시스템

• 기본적으로 많은 컨테이너 서비스가 특권을 가진 root 사용자로 실행되며, 특권 실행이 불필요한 애플리케이션도 컨테이너 내에서 root로 실행된다
• non-root 컨테이너는 컨테이너 이미지 빌드 시 구성되며, 쿠버네티스에서는 SecurityContext:runAsUser를 통해 non-zero 사용자로 실행할 수 있다
• 개발자들은 빌드 시점에 non-root 실행을 통합하는 것이 권장되는데, 이는 애플리케이션이 root 권한 없이도 정상 작동한다는 더 나은 보증을 제공한다
• Rootless 컨테이너 엔진은 root로 실행되는 데몬 대신 권한이 없는 컨텍스트에서 실행될 수 있지만, 현재는 대부분 실험적 단계이므로 프로덕션 환경에서는 사용하지 않는 것이 좋다
• 쿠버네티스는 컨테이너의 파일 시스템을 잠글 수 있어 악의적인 활동을 방지할 수 있으며, 필요한 경우 특정 디렉터리에 대해서만 읽기/쓰기가 가능한 보조 파일시스템을 마운트할 수 있다

2.6. 컨테이너 이미지 보안 및 파드 보안 강화 방안

• 신뢰할 수 있는 저장소를 통한 컨테이너 이미지 생성이 필요하며, 플랫폼 수준의 제어와 네트워크 수준의 제한을 통해 개발자들의 저장소 사용을 제한할 수 있다
• 컨테이너 빌드 과정에서 이미지 스캐닝을 통해 오래된 라이브러리, 알려진 취약점, 보안되지 않은 포트나 권한과 같은 잘못된 구성을 식별해야 한다
• 파드 보안 강화는 Kubernetes 1.23 버전부터 기본적으로 활성화된 Pod Security Admission(privileged, baseline, restricted 카테고리로 분류)과 deprecated된 PodSecurity Policies를 통해 구현할 수 있다
• 컨테이너화된 애플리케이션이 서비스 계정에 직접 접근할 필요가 없는 경우, "automountServiceAccountToken: false" 지시문을 통해 시크릿 토큰 마운트를 비활성화해야 한다
• 하이퍼바이저 기반 컨테이너화, 커널 기반 솔루션( seccomp), 애플리케이션 샌드박스와 같은 추가적인 도구들을 통해 컨테이너 환경을 더욱 강화할 수 있다

2.7. 쿠버네티스의 네트워크 분리와 보안 정책

• 네임스페이스는 클러스터 리소스를 여러 개인, 팀, 애플리케이션 간에 분할하는 방식이며, 기본적으로 kube-system, kube-public, default 세 가지가 존재한다
• 기본적으로 쿠버네티스 리소스는 격리되어 있지 않아 횡적 이동이나 권한 상승이 가능하므로, 리소스 분리와 암호화를 통해 사이버 공격자의 활동을 제한해야 한다
• 서비스는 파드에 고유 IP 주소를 할당하는 추상화 계층으로, 파드가 재생성되거나 이동하더라도 변경되지 않는 안정적인 IP 주소를 제공한다
• 네트워크 정책은 파드, 네임스페이스, 외부 IP 주소 간의 트래픽 흐름을 제어하며, 기본적으로는 제한이 없지만 정책이 적용되면 명시적으로 허용된 연결만 가능하다
• 관리자는 모든 파드를 선택하는 기본 정책으로 모든 수신 및 송신 트래픽을 거부하고, 추가 정책을 통해 허용할 연결에 대한 제한을 완화해야 한다

 

3. 🔒 쿠버네티스의 인증 및 권한 관리 체계

• 서비스 계정과 일반 사용자 계정 두 가지 유형의 사용자가 존재하며, 기본적으로 자동 인증 메커니즘은 활성화되어 있지 않다
• 서비스 계정은 ServiceAccount Admission Controller를 통해 자동으로 관리되며, Pod를 대신하여 API 요청을 처리하고 bearer 토큰을 사용한다
• 일반 사용자와 관리자 계정은 X509 클라이언트 인증서, 부트스트랩 토큰, OpenID 토큰 등의 인증 방식 중 하나 이상을 구현해야 하며, 정적 비밀번호 파일과 같은 취약한 인증 방식은 피해야 한다
• RBAC(Role-Based Access Control)는 기본적으로 활성화되어 있으며, 조직 내 개인의 역할에 따라 클러스터 리소스에 대한 접근을 제어하는 방식이다
• 권한은 Role(특정 네임스페이스권한)과 ClusterRole(전체 클러스터 리소스 권한)로 구분되며, 각각 RoleBinding과 ClusterRoleBinding을 통해 사용자, 그룹, 서비스 계정에 연결된다

3.1. 네트워크 분리와 리소스 제한 정책

• 보안 영역(Security zones) 설정을 통해 공개 애플리케이션을 내부 리소스와 분리하여 공격 표면과 측면 이동의 기회를 제한할 수 있다
• NetworkPolicy API를 지원하는 CNI 플러그인을 사용하고, podSelector와 namespaceSelector로 Pod를 선택하여 정책을 생성해야 한다
• LimitRange는 네임스페이스내 개별 Pod나 컨테이너의 컴퓨팅 및 스토리지 자원을 제한하며, 네임스페이스당 하나만 생성할 수 있다
• ResourceQuota는 네임스페이스전체의 CPU와 메모리 사용량 총합을 제한하는 정책이다
• PID(Process ID) 제한을 통해 시스템 사용을 위한 PID를 예약하고 Pod별 프로세스 수를 제한할 수 있으며, 비정상적인 리소스 사용은 축출 정책으로 관리한다

3.2. 쿠버네티스 컨트롤 플레인 보안 강화 방안

• 컨트롤 플레인은 컨테이너 조회, Pod스케줄링, Secret 읽기, 클러스터 명령 실행 등 민감한 기능을 수행하므로 높은 수준의 보호가 필요하다
• TLS 암호화, RBAC, 강력한 인증 방식과 함께 네트워크 분리를 통해 포트 6443에서 실행되는 쿠버네티스 API 서버를 인터넷이나 신뢰할 수 없는 네트워크로부터 보호해야 한다
• kube-system 네임스페이스에 네트워크 정책을 적용하여 인터넷 접근을 제한하되, 다른 컨트롤 플레인구성 요소 및 워커 노드와의 통신은 유지해야 한다
• etcd 백엔드 데이터베이스는 클러스터의 상태 정보와 Secret을 저장하는 핵심 구성 요소로, API 서버에만 할당된 인증서를 신뢰하도록 구성하고 별도의 컨트롤 플레인노드에서 실행할 수 있다
• API 서버와 etcd서버 간 통신을 위해 HTTPS 통신을 강제하는 TLS 인증서를 설정하고, 별도의 **인증 기관(CA)**을 사용하는 것이 유익할 수 있다

3.3. 쿠버네티스 구성 파일과 워커노드 보안 강화

• kubeconfig 파일은 클러스터, 사용자, 네임스페이스, 인증 메커니즘에 대한 민감한 정보를 포함하므로, 무단 접근과 변경으로부터 보호해야 한다
• 워커노드는 마이크로서비스와 웹 애플리케이션을 실행하는 공격 대상이 되기 쉬우므로, 노드가 침해될 경우를 대비해 다른 네트워크 세그먼트와 분리해야 한다
• 방화벽을 사용하여 내부 네트워크 세그먼트를 외부 연결 워커노드나 전체 쿠버네티스 서비스로부터 분리할 수 있다
• 워커노드는 kubelet API(10250 포트)와 NodePort 서비스(30000-32767 포트)를 인바운드 트래픽으로 사용한다
• 기밀 데이터베이스나 내부 서비스와 같이 워커노드와 통신이 불필요한 서비스는 공격 표면으로부터 분리해야 한다

3.4. 쿠버네티스의 암호화와 시크릿 관리

• 쿠버네티스의 모든 컴포넌트, 노드, 컨트롤 플레인은 TLS 1.2 또는 1.3 암호화를 사용해야 하며, 설치 중이나 이후에 TLS 부트스트래핑을 통해 설정할 수 있다
• 쿠버네티스 시크릿은 비밀번호, OAuth 토큰, SSH 키와 같은 민감한 정보를 저장하며, YAML 파일이나 컨테이너 이미지에 직접 저장하는 것보다 더 나은 접근 제어를 제공한다
• 기본적으로 시크릿은 암호화되지 않은 base64 인코딩 문자열로 저장되어 API 접근 권한이 있는 누구나 검색할 수 있지만, RBAC 정책을 적용하여 접근을 제한할 수 있다
• 시크릿 데이터의 저장 시 암호화는 API 서버나 클라우드 제공자의 **외부 키 관리 서비스(KMS)**를 통해 구현할 수 있으며, API 서버를 사용할 경우 -encryption-provider-config 인수를 사용하여 설정한다

3.5. 클라우드 메타데이터 서비스 보안과 인증 메커니즘

• 클라우드 메타데이터 서비스는 인프라 정보와 클라우드 리소스 자격 증명을 제공하므로, 관리자는 네트워크 정책이나 클라우드 구성 정책을 통해 Pod의 접근을 차단해야 한다
• 서비스 계정은 Pod를 대신하여 API 요청을 처리하며, ServiceAccount Admission Controller가 베어러 토큰을 통해 자동으로 관리한다
• Pod정의에 서비스 계정이 지정되지 않으면 해당 네임스페이스의 기본 서비스 계정이 자동으로 할당되며, automountServiceAccountToken을 false로 설정하여 이를 방지할 수 있다
• 일반 사용자와 관리자 계정은 자동 인증 방식이 없으므로, X509 클라이언트 인증서, 부트스트랩 토큰, OpenID 토큰 등의 인증 방식을 구현해야 한다
• 정적 비밀번호 파일과 같은 취약한 인증 방식은 사이버 공격자의 인증을 허용할 수 있으므로 사용을 피해야 한다

3.6. RBAC를 통한 클러스터 접근 제어 관리

• RBAC(Role-Based Access Control)는 조직 내 개인의 역할에 따라 클러스터 리소스 접근을 제어하는 기본 활성화된 방식이다
• Role은 특정 네임스페이스의 권한을, ClusterRole은 네임스페이스와 관계없이 전체 클러스터 리소스에 대한 권한을 설정한다
• RoleBinding은 정의된 네임스페이스내에서, ClusterRoleBinding은 전체 클러스터 리소스에 대해 사용자, 그룹, 서비스 계정에 권한을 부여한다
• 하나의 ClusterRole은 여러 RoleBinding과 함께 사용되어 다양한 사용자나 그룹의 범위를 제한할 수 있다
• 최소 권한 원칙에 따라 사용자, 그룹, 서비스 계정은 필요한 리소스가 있는 특정 네임스페이스에만 접근이 제한되어야 한다

3.7. 쿠버네티스 감사 로깅과 위협 탐지 체계

• 감사 로그(Audit logs)는 클러스터의 활동을 추적하며, 서비스 운영 상태 확인과 보안 유지를 위해 필수적이다
• 로깅은 호스트, 애플리케이션, 컨테이너, 컨테이너 엔진, 이미지 레지스트리, API 서버, 클라우드 등 모든 환경 수준에서 수행되어야 한다
• 주요 모니터링 대상은 API 요청 기록, 성능 지표, 배포, 자원 소비, Pod 스케일링, OS 호출, 권한 변경, 네트워크 트래픽, 볼륨 마운트 등이다
• Pod생성 또는 업데이트 시 네트워크 통신, 응답 시간, 요청, 자원 소비 등의 상세 로그를 수집하여 기준선(baseline)을 설정해야 한다
• 로그는 외부 로깅 서비스로 스트리밍하여 클러스터 외부의 보안 전문가가 실시간으로 비정상 활동을 식별할 수 있도록 하며, TLS 1.2 또는 1.3으로 암호화해야 한다

 

4. 🔍 쿠버네티스 로깅 및 감사 시스템 구성

• 쿠버네티스 감사 로깅은 기본적으로 비활성화되어 있으며, 관리자가 YAML 형식의 감사 정책 파일을 작성하여 감사 이벤트의 로깅 수준을 지정해야 한다
• RequestResponse 수준의 로깅은 최대한의 정보를 제공하지만, 보안을 위해 Secrets 관련 요청은 Metadata 수준으로 낮추는 것이 권장된다
• 로그 보존을 위해 원격 로깅 솔루션을 구성해야 하며, DaemonSet으로 로깅 에이전트를 실행하여 모든 노드에서 일관된 로깅을 보장할 수 있다
• 시스템 콜 감사를 위해 seccomp 도구를 사용할 수 있으며, 이는 컨테이너의 시스템 콜 능력을 제한하고 로깅하여 보안을 강화한다
• 공격자의 활동 탐지를 위해 비정상적인 Pod 배포, API 요청, 리소스 사용량 급증, 익명 계정 활동 등을 모니터링해야 한다

4.1. 쿠버네티스 감사 로깅(Audit Logging) 구성 및 정책

• kube-apiserver는 클러스터의 내외부 요청을 처리하는 컨트롤 플레인의 프론트엔드로, 각 요청은 실행 단계마다 감사 이벤트를 생성한다
• 클러스터 관리자는 감사 정책 YAML 파일을 작성하여 각 감사 이벤트의 로깅 수준을 지정해야 하며, 이는 적절한 플래그와 함께 kube-apiserver에 전달된다
• RequestResponse 수준으로 모든 이벤트를 로깅하면 보안 사고 대응에 필요한 최대한의 정보를 얻을 수 있지만, Secrets와 관련된 요청은 Metadata 수준으로 낮추어 로깅하는 것이 권장된다
• 조직의 특정 클러스터 구성과 위협 모델을 고려하여 중요하지 않은 일상적인 이벤트의 로깅 수준을 낮추되, 보안 중요 이벤트는 반드시 로깅해야 한다
• 외부 로그 서버 사용 시 append-only 접근 권한으로 로그 포워더를 구성하여 쿠버네티스 내부에서 외부 저장소의 로그가 삭제되거나 덮어쓰이는 것을 방지해야 한다

4.2. 쿠버네티스의 감사 로깅 및 로그 관리 구성

• kube-apiserver는 감사 이벤트를 위한 로깅 백엔드와 웹훅 백엔드 두 가지 구성 가능한 백엔드를 제공하며, 로그 파일 작성과 외부 HTTP API로의 전송이 가능하다
• 로깅 백엔드의 기본 설정은 -audit-log-path 플래그로, 기본 형식은 JSON이며 필요시 변경이 가능하다
• 워커 노드의 kubelet은 로그 파일을 로컬에서 관리하고 순환시키며, kubectl logs 명령어를 통해 컨테이너의 로그에 접근할 수 있다
• 컨테이너, 파드, 노드 장애 시 로그 보존을 위해 원격 로깅 솔루션 구성이 권장되며, 이는 노드에서 백엔드로 로그를 푸시하거나 사이드카 컨테이너를 통해 구현할 수 있다

4.3. 로깅 에이전트 구성 및 시스템 콜 감사 방안

• 로깅 에이전트는 Pod내 독립 컨테이너로 구성하여 노드의 애플리케이션 로그에 접근하고 조직의 SIEM으로 전달하도록 설정할 수 있다
• 사이드카 컨테이너를 각 로그 유형별로 구성하여 개별 출력 스트림으로 리디렉션하면, 노드 수준의 로깅 에이전트가 이를 SIEM으로 전달할 수 있다
• DaemonSet으로 로깅 에이전트를 실행하면 모든 워커 노드에서 일관된 로깅이 가능하며, 변경사항이 클러스터 전체에 일관되게 적용된다
• Seccomp 도구를 사용하여 컨테이너의 시스템 콜을 감사하고 제한할 수 있으며, 이는 커널의 공격 표면을 줄이는데 도움이 된다
• 관리자는 시스템 콜 로깅을 통해 Pod의 표준 작동 패턴을 파악하고, seccomp 프로파일을 더욱 제한적으로 구성할 수 있다

4.4. 로그 수집과 SIEM 플랫폼 통합

• 쿠버네티스는 기본적으로 kubelet 로그와 컨테이너 런타임 로그를 journald에 기록하며, 필요시 syslog 유틸리티를 통해 외부 저장소로 전달하도록 구성할 수 있다
• syslog 데몬(syslog-ng, rsyslog)은 시스템 전반의 로그를 통합된 형식으로 수집하고 집계하며, 많은 리눅스 시스템은 기본적으로 rsyslog나 journald를 사용한다
• SIEM(Security Information and Event Management) 소프트웨어는 조직의 네트워크 전반에서 로그를 수집하여 중앙화된 모니터링, 위협 탐지, 경고 기능을 제공한다
• 컨테이너화된 환경에서는 Pod와 컨테이너가 지속적으로 삭제되고 재배포되어 IP 주소 기반의 전통적인 SIEM에는 추가적인 과제가 된다
• 많은 SIEM 도구 개발 조직들이 쿠버네티스 환경에 특화된 제품을 개발하여 컨테이너화된 환경을 위한 완전한 모니터링 솔루션을 제공한다

4.5. 서비스 메시의 이점과 장애 허용 정책

• 서비스 메시는 마이크로서비스간 통신 로직을 중앙화하여 개발자의 코딩을 단순화하고, 확장성과 디버깅, 보안성을 향상시키는 플랫폼이다
• 서비스 메시는 트래픽 리디렉션, 성능 지표 수집, 서비스 간 암호화 관리, 로그 수집, 문제 진단 등 다양한 기능을 제공한다
• 쿠버네티스 환경에 적합한 서비스 메시는 관리형 서비스에서 자체 제공되거나 커스터마이징 가능한 다른 플랫폼을 선택할 수 있다
• 서비스 메시는 TLS 인증을 통한 서비스 간 암호화를 자동으로 관리하며, 일부는 이를 기본값으로 제공한다
• 장애 발생 시를 대비해 오래된 로그 파일 덮어쓰기나 로컬 저장소 활용 등의 장애 허용 정책을 수립해야 한다

4.6. 위협 탐지를 위한 로그 모니터링 전략

• 효과적인 로깅 솔루션은 필요한 모든 데이터 수집과 실시간에 가까운 적극적인 모니터링이라는 두 가지 핵심 요소로 구성된다
• 공격자들은 악성 소프트웨어 실행이나 권한 상승을 위해 Pod나 컨테이너를 배포하려 시도하며, 이때 정당한 이미지처럼 위장하거나 root 권한으로 시작하려 한다
• 공격자의 주요 행동 패턴으로는 악성 이미지 등록, API 요청을 통한 권한 상승, 크립토재킹 공격, 익명 계정 사용, 볼륨 마운트 악용 등이 있다
• 로그 탐지 시에는 비정상적인 Pod배포, 이미지 ID 비교, root 권한 시작 여부, 특이한 API 요청, Pod내부에서 발생하는 비정상적인 시스템 호출 등을 주의 깊게 관찰해야 한다
• 방대한 양의 로그로 인해 수동 검토가 어렵기 때문에, 관리자는 특정 클러스터에 맞춤화된 비정상 활동 지표를 파악하고 있어야 한다

4.7. 쿠버네티스 알림 구성과 자동 대응 방안

• 쿠버네티스 알림 시스템은 기본 지원되지 않지만, 다양한 모니터링 도구를 통해 구현이 가능하다
• 주요 알림 트리거 이벤트로는 디스크 공간 부족, 로깅 볼륨 저장 공간 부족, 외부 로깅 서비스 중단, 루트 권한으로 실행되는 파드, 익명 요청, 비정상적인 API 호출 등이 있다
• 2021년 쿠버네티스 프로젝트에서는 보안 컨텍스트 변경, admission 컨트롤러 구성 업데이트, 민감한 파일/URL 접근 등을 추가 모니터링 항목으로 제시했다
• 보안 사고 발생 시 자동 대응 체계를 구축하여 신속한 조치가 가능하며, 예를 들어 비정상적인 파드 생성 시 해당 파드를 자동으로 제거하고 새로운 파드를 재배치하는 방식을 활용할 수 있다
• 쿠버네티스는 기본적으로 광범위한 감사 기능을 제공하지 않지만, 사용자가 필요에 따라 커스텀 솔루션을 개발하거나 적절한 애드온을 선택할 수 있다

 

5. 🔒 쿠버네티스 보안 업데이트 및 애플리케이션 보안 관리

• 지속적인 보안 관리를 위해 패치, 업데이트, 업그레이드를 꾸준히 수행하며, 쿠버네티스, 하이퍼바이저, 가상화 소프트웨어, 플러그인 등 모든 시스템 구성요소를 최신 상태로 유지해야 한다
• 24/7 서비스 가용성이 필요한 기업은 고가용성 클러스터를 사용하여 서비스 중단 없이 한 번에 하나씩 물리적 머신의 펌웨어, 커널, OS 업데이트를 수행할 수 있다
• CIS 벤치마크를 준수하고 정기적인 취약점 스캔과 침투 테스트를 수행하여 보안 설정 오류와 제로데이 취약점을 사전에 탐지해야 한다
• 공격 표면을 줄이기 위해 오래되고 사용하지 않는 구성요소를 제거하고, 관리형 쿠버네티스 서비스를 활용하여 업그레이드와 패치를 자동화할 수 있다
• 개발자는 실수로 오래된 이미지가 배포되는 것을 방지하기 위해 새로운 이미지에 적절한 태그를 지정해야 한다

5.1. 쿠버네티스 보안 모니터링 및 감시 도구

• 쿠버네티스 환경은 기존 SIEM 플랫폼과 통합이 가능하며, Prometheus, Grafana, Elastic Stack(ELK) 등의 오픈소스 모니터링 도구를 활용할 수 있다
• 모니터링 도구들은 이벤트 감시, 위협 분석, 경고 관리뿐만 아니라 컨테이너의 리소스 격리 매개변수, 사용 기록, 네트워크 통계 등을 수집할 수 있다
• RBAC의 위험한 권한 설정을 식별하기 위해 접근 제어 및 권한 구성을 감사할 때 스캐닝 도구를 활용할 수 있다
• NSA와 CISA는 기존 환경에서 침입 탐지 시스템(IDS)을 사용하는 조직들에게 쿠버네티스 환경에도 이를 통합할 것을 권장한다
• 비정상적인 동작을 보이는 컨테이너를 감지하고 초기 클린 이미지로 재시작할 수 있으며, CSP들은 관리형 확장 솔루션을 제공한다

5.2. 지속적인 보안 업데이트와 취약점 관리

• 쿠버네티스 보안 강화는 지속적인 과정으로, 패치와 업데이트, 업그레이드를 꾸준히 유지해야 한다
• 전체 시스템의 보안을 위해 쿠버네티스, 하이퍼바이저, 가상화 소프트웨어, 플러그인, 운영체제, CI/CD 파이프라인 등 모든 구성요소를 최신 상태로 유지해야 한다
• 24/7 서비스 가용성이 필요한 기업은 고가용성 클러스터를 사용하여 서비스 중단 없이 시스템 업데이트를 수행할 수 있다
• 관리자는 CIS 벤치마크를 준수하고, 정기적인 취약점 스캔과 침투 테스트를 수행하여 보안 위험을 사전에 탐지하고 해결해야 한다
• 공격 표면을 줄이기 위해 오래되거나 사용하지 않는 구성요소를 제거하고, 관리형 쿠버네티스 서비스를 활용하여 업그레이드와 패치를 자동화할 수 있다

5.3. 참고 자료와 non-root 사용자 Dockerfile 예시

• 쿠버네티스 보안 강화를 위한 주요 참고 자료로 CIS 벤치마크, DISA STIG, 쿠버네티스 공식 문서, MITRE ATT&CK 등이 제시되어 있다
• 보안 강화를 위한 non-root 애플리케이션 실행 Dockerfile 예시가 제공되어 있다
• Dockerfile에서는 Ubuntu 최신 버전을 기반으로 make 유틸리티를 설치하고, 새로운 사용자(user1)와 그룹(group1)을 생성하여 애플리케이션을 실행한다
• 소스 코드는 "code" 폴더에서 복사되어 make 유틸리티를 통해 빌드되며, 컨테이너의 기본 진입점이 설정된다

5.4. 읽기 전용 루트 파일시스템을 활용한 쿠버네티스 배포 템플릿

• 읽기 전용 루트 파일시스템을 사용하는 쿠버네티스 배포 템플릿의 예시를 제공한다
• 템플릿은 securityContext에서 readOnlyRootFilesystem: true 설정을 통해 컨테이너의 파일시스템을 읽기 전용으로 구성한다
• 쓰기 작업이 필요한 애플리케이션을 위해 볼륨 마운트를 통한 쓰기 가능한 영역을 별도로 생성할 수 있다
• 템플릿은 ubuntu:latest 이미지를 사용하며, emptyDir 볼륨을 통해 쓰기 가능한 임시 저장소를 제공한다

5.5. Pod 보안 정책(PSP)의 구성요소와 권장사항

• Pod 보안 정책(PSP)은 클러스터 전체에 적용되는 정책으로, Pod가 클러스터 내에서 실행되기 위한 보안 요구사항과 기본값을 지정하는 메커니즘이다
• PSP는 Pod생성 시점에만 요구사항을 적용할 수 있으며, 이미 실행 중인 Pod에는 영향을 미치지 않는다
• 주요 PSP 구성 요소에는 privileged(특권 컨테이너 실행 제어), hostPID/hostIPC(호스트 프로세스 네임스페이스공유), hostNetwork(호스트 네트워크 사용), allowedHostPaths(호스트 파일시스템 접근 제한) 등이 있다
• 보안 강화를 위해 privileged, hostPID, hostIPC, hostNetwork는 false로 설정하고, root 파일시스템은 읽기 전용으로 설정해야 한다
• 컨테이너 애플리케이션은 MustRunAsNonRoot 설정과 함께 non-zero 그룹으로 실행하도록 구성해야 한다

5.6. Pod Security Policy(PSP)의 주요 구성 요소와 보안 설정

• Pod Security Policy 적용을 위해서는 Kubernetes admission controller의 PodSecurityPolicy 플러그인 활성화가 선행되어야 한다
• PSP는 root 권한 상승 제한, SELinux 컨텍스트 설정, AppArmor 프로필 설정, seccomp 프로필을 통한 컨테이너 샌드박싱 등의 보안 기능을 제공한다
• 관리자는 RBAC을 통해 정책을 승인해야 하며, 여러 PSP가 존재하는 환경에서는 Pod가 가장 덜 제한적인 정책을 따르므로 주의가 필요하다
• fsGroup을 0이 아닌 값으로 설정하고, runAsUser: MustRunAsNonRoot 설정의 효과적인 적용을 위해 권한 상승을 false로 설정해야 한다
• seccomp 감사 프로필을 사용하여 필요한 syscall을 식별한 후, 다른 모든 syscall을 차단하는 seccomp프로필을 활성화하는 것이 권장된다

5.7. Pod 보안 정책과 네임스페이스 구성 예시

• Pod 보안 정책(PSP)은 컨테이너가 루트 권한 없이 실행되도록 강제하고, 권한 상승을 방지하며, 호스트 네트워크/IPC/PID 접근을 제한하는 등 강력한 보안 요구사항을 적용한다
• 네임스페이스는 kubectl create namespace 명령어나 YAML 파일을 통해 생성할 수 있으며, kube- 접두사는 시스템 예약어와의 충돌을 피하기 위해 사용을 피해야 한다
• 새로운 파드를 특정 네임스페이스에 배포하기 위해서는 kubectl config use-context 명령어로 네임스페이스를 전환하거나, 명령어에 --namespace 옵션을 추가하거나, YAML 파일의 metadata에 명시할 수 있다
• 한번 생성된 리소스는 네임스페이스간 이동이 불가능하므로, 다른 네임스페이스로 이동하려면 삭제 후 재생성해야 한다