Kubernetes 1.37 rootless 모드 베타, 노드 권한을 낮추는 방법이 넓어졌다
AI를 활용하여 생성한 이미지입니다.
컴퓨팅 · 해외 이슈
Kubernetes 1.37에서 노드 구성 요소를 호스트의 일반 사용자 권한으로 실행하는 기능이 베타 단계로 올라갔어요. 기능 이름은 KubeletInUserNamespace이고, 흔히 rootless 모드라고 부릅니다.[1]
컨테이너 안에서 root로 실행되는 프로세스가 호스트에서도 root 권한을 갖는 구조는 컨테이너 탈출 사고 때 피해를 키울 수 있어요. Kubernetes 문서는 사용자 네임스페이스를 쓰면 컨테이너 안의 root가 네임스페이스 바깥, 즉 호스트에서는 권한 없는 사용자로 보인다고 설명합니다.[2]
무엇이 베타가 됐을까?
Kubernetes 공식 발표에 따르면 이번 변화는 kubelet 하나만 낮은 권한으로 실행하는 기능이 아니에요. kubelet을 비롯해 컨테이너 런타임, OCI 런타임, CNI 플러그인, kube-proxy 같은 노드 구성 요소 전체를 Linux 사용자 네임스페이스 안에서 호스트의 비root 사용자로 실행할 수 있게 하는 기능 게이트가 베타로 승격됐어요.[1]
이 작업은 2018년 실험에서 출발했고, Kubernetes 1.22에서 알파 기능으로 병합된 뒤 단계적으로 다듬어졌어요.[1] 베타는 기능이 실제 운영 환경을 염두에 둔 수준까지 올라왔다는 뜻이지, 모든 배포판과 런타임 조합에서 추가 확인 없이 켜도 된다는 뜻은 아닙니다.
보안상 달라지는 지점
일반적인 컨테이너에서는 컨테이너 내부의 root 권한과 호스트 권한 사이에 여러 격리 장치가 작동하지만, 취약점이 생기면 그 경계가 공격 대상이 될 수 있어요. 사용자 네임스페이스는 컨테이너 내부의 UID 0을 호스트의 비root UID로 매핑해, 컨테이너 안에서 가능한 작업과 호스트에서 가능한 작업을 분리합니다.[2]
그래서 이 기능은 취약점이 사라진다는 약속이 아니라, 취약점이 악용됐을 때 호스트에서 바로 높은 권한으로 이어지는 경로를 줄이는 방어층에 가까워요. 네트워크 권한, 커널 설정, 런타임 구성, 파일 시스템 마운트 같은 다른 보안 조건은 여전히 따로 점검해야 합니다.
운영자는 무엇을 확인해야 할까?
- Kubernetes 1.37과 사용하는 Linux 커널이 사용자 네임스페이스 실행 조건을 만족하는지 확인해요.
- kubelet, CRI·OCI 런타임, CNI 플러그인, kube-proxy가 비root 환경에서 함께 동작하는 조합인지 시험해요.
- 호스트 경로 마운트, 네트워크 플러그인, 장치 접근처럼 root 권한을 전제로 한 워크로드를 따로 분류해요.
- 개발 클러스터에서 기능을 켠 뒤 로그, 이미지 풀, 볼륨, 네트워크, 노드 재시작을 차례로 확인하고 운영 클러스터에 확대해요.
아직 남은 불확실성
이번 발표만으로 특정 클라우드 서비스나 관리형 Kubernetes가 즉시 이 기능을 제공한다고 말할 수는 없어요. 실제 사용 가능 여부는 Kubernetes 버전뿐 아니라 노드 운영체제, 커널 설정, 런타임과 CNI 조합에 달려 있습니다. 호스트 사용자 네임스페이스를 지원하지 않는 환경이라면 베타 승격만으로 배포 방식이 바뀌지 않아요.
따라서 지금의 실용적인 해석은 rootless 노드 운영을 검토할 수 있는 단계가 한 칸 올라갔다는 정도예요. 기존 클러스터를 바로 전환하기보다, 권한이 큰 워크로드가 모여 있는 노드부터 별도 테스트하는 편이 안전합니다.
정리
Kubernetes 1.37의 KubeletInUserNamespace 베타는 컨테이너 안의 root와 호스트의 root를 분리하는 범위를 노드 구성 요소까지 넓히려는 변화예요. 보안 경계를 하나 더 두는 데 의미가 있지만, 호환성 검증과 운영 테스트를 생략해도 되는 기능은 아닙니다. 새 클러스터를 설계하거나 노드 권한을 줄이는 작업을 준비하고 있다면 사용자 네임스페이스 지원 여부부터 확인해 보세요.
