Kubernetes 1.37 루트리스 노드 베타: kubelet의 호스트 root 권한을 줄인다

Kubernetes 1.37에서 KubeletInUserNamespace가 베타로 올라갔다. 기존 클러스터에 미치는 영향과 CNI·CSI 호환성, 도입 전 확인 사항을 정리한다.

Kubernetes 1.37 루트리스 노드 베타: kubelet의 호스트 root 권한을 줄인다

Kubernetes 1.37에서 KubeletInUserNamespace 기능 게이트가 베타로 승격됐다. kubelet, CRI·OCI 런타임, CNI 플러그인, kube-proxy 같은 노드 구성요소를 호스트의 비 root 사용자로 실행하는 이른바 루트리스 모드다.

Kubernetes 공식 발표KEP-2033를 기준으로 범위와 제약을 확인했다.

무엇이 바뀌었나

기능 게이트는 1.37에서 기본 활성화되지만, 이것만으로 기존 노드가 자동으로 사용자 네임스페이스 안에서 실행되지는 않는다. 기존 root 방식 클러스터의 동작은 그대로다. 노드 정보에는 runningInUserNamespace가 추가돼 스케줄링 정책에 활용할 수 있다.

개발자와 운영자에게 왜 중요한가

노드 구성요소가 침해돼도 피해를 비 root 계정 범위로 제한할 여지가 생긴다. 공유 HPC, 노트북의 로컬 클러스터, 중첩 Kubernetes, 에이전트가 테스트 클러스터를 다루는 격리 환경에서 특히 유용하다. 다만 커널 자체 취약점까지 막는 기능은 아니므로 seccomp 등 기존 방어와 함께 써야 한다.

기존 프로젝트 영향

일부 CNI·CSI 드라이버와 실제 root 권한을 요구하는 설치 워크로드는 호환되지 않을 수 있다. 사용자 네임스페이스는 Kubernetes 밖에서 준비해야 하며 rootless Docker, nerdctl, Podman을 이용한 kind 구성이 대표적인 시험 경로다.

적용 전 확인 사항

  • Kubernetes 1.37의 지원 단계와 사용하는 배포판의 제공 시점을 확인한다.
  • CNI·CSI·컨테이너 런타임 조합을 운영 환경과 같은 커널에서 시험한다.
  • runningInUserNamespace를 라벨·taint 정책과 연결해 실제 root가 필요한 워크로드를 분리한다.
  • 장애 복구, 로그 접근, cgroup·sysctl 제한을 사전에 검증한다.

출처