피드로 돌아가기
Kubernetes BlogKubernetes Blog
DevOps

Kubernetes v1.35에서 supplementalGroupsPolicy 필드를 GA로 승격하여 컨테이너 이미지의 /etc/group에서 암묵적으로 병합되는 그룹 정보를 명시적으로 제어 가능

Kubernetes v1.35: Fine-grained Supplemental Groups Control Graduates to GA

2025년 12월 23일9intermediate

Context

Kubernetes는 기본적으로 Pod 매니페스트의 보안 컨텍스트와 컨테이너 이미지의 /etc/group 파일의 그룹 정보를 자동으로 병합하여 적용합니다. 이로 인해 Pod 매니페스트에 선언되지 않은 암묵적 그룹 ID가 컨테이너 프로세스에 할당되어 정책 엔진으로 검증할 수 없고, 파일 권한 제어 시 예기치 않은 접근 제어 문제가 발생할 수 있습니다.

Technical Solution

  • supplementalGroupsPolicy 필드 도입: Pod의 .spec.securityContext에 supplementalGroupsPolicy 필드를 추가하여 보충 그룹 계산 방식을 제어
  • Merge 정책 (기본값): /etc/group의 그룹 정보를 기존처럼 병합하여 하위 호환성 유지
  • Strict 정책: fsGroup, supplementalGroups, runAsGroup에만 지정된 그룹 ID만 적용하고 /etc/group의 암묵적 그룹 정보를 무시
  • 프로세스 ID 투명성 제공: .status.containerStatuses[].user.linux 필드를 통해 첫 번째 컨테이너 프로세스에 할당된 UID/GID 및 보충 그룹을 노출하여 보안 감시 강화
  • 컨테이너 런타임 지원 요구: Strict 정책은 containerd v2.0 이상, CRI-O v1.31 이상 등 업데이트된 CRI 런타임 필요

Key Takeaway

Kubernetes 클러스터 관리자는 Pod 매니페스트에서 모든 보충 그룹을 명시적으로 선언하고 supplementalGroupsPolicy: Strict를 정책 엔진으로 강제하여, 컨테이너 이미지의 암묵적 그룹 정보로 인한 보안 취약성을 사전에 차단할 수 있습니다.


Kubernetes를 운영하는 조직에서 보안 강화 정책을 적용할 때, Pod 매니페스트의 모든 보충 그룹(supplementalGroups, fsGroup, runAsGroup)을 명시적으로 선언하고 supplementalGroupsPolicy: Strict를 적용하면, 컨테이너 이미지의 /etc/group에서 암묵적으로 주입되는 예기치 않은 그룹 ID로 인한 볼륨 접근 제어 문제를 방지할 수 있습니다.

원문 읽기