Kubernetes 1.37 rootless 모드 베타, 노드 권한을 낮추는 방법이 넓어졌다

AI를 활용하여 생성한 이미지입니다.

컴퓨팅 · 해외 이슈

Kubernetes 1.37에서 노드 구성 요소를 호스트의 일반 사용자 권한으로 실행하는 기능이 베타 단계로 올라갔습니다. 기능 게이트의 이름은 KubeletInUserNamespace이며, 컨테이너 내부의 root 권한이 호스트의 root 권한으로 바로 이어지는 경로를 줄이려는 rootless 운영과 연결됩니다.[1]

이 변화는 “베타가 됐으니 모든 클러스터에서 켜면 된다”는 뜻이 아닙니다. 사용자 네임스페이스는 컨테이너 안 UID 0을 네임스페이스 밖의 비root UID로 매핑하는 방어층입니다.[2] 런타임, 커널, CNI, 볼륨, 장치 접근이 모두 같은 가정을 공유해야 하므로, 보안 효과와 호환성을 함께 검증해야 합니다.

이번 베타가 넓힌 범위

Kubernetes 공식 발표에 따르면 이번 기능은 kubelet 하나만 낮은 권한으로 실행하는 설정이 아닙니다. kubelet을 비롯해 컨테이너 런타임과 OCI 런타임, CNI 플러그인, kube-proxy 같은 노드 구성 요소를 Linux 사용자 네임스페이스 안에서 호스트의 비root 사용자로 실행할 수 있도록 하는 기능 게이트입니다.[1]

이 작업은 2018년 실험에서 출발했고 Kubernetes 1.22에서 알파 기능으로 병합된 뒤 단계적으로 다듬어졌습니다.[1] 베타 승격은 더 넓은 사용과 피드백을 염두에 둔 성숙도 변화이지, 배포판·커널·런타임 조합에 대한 호환성 보증은 아닙니다.

보안상 어떤 방어층이 생기나

일반 컨테이너에서도 여러 격리 장치가 동작하지만, 런타임 취약점이나 잘못된 권한 조합이 생기면 컨테이너와 호스트 사이의 경계가 공격 대상이 될 수 있습니다. 사용자 네임스페이스는 컨테이너 안에서 root로 보이는 프로세스를 호스트에서는 권한 없는 사용자로 보이게 해, 침해가 곧바로 호스트 고권한 실행으로 이어지는 가능성을 낮춥니다.[2]

다만 이 기능이 취약점을 없애거나 모든 탈출 경로를 차단하는 것은 아닙니다. 네트워크 권한, 커널 취약점, 파일 시스템 마운트, 호스트 경로, 장치 접근, 런타임 설정은 별도로 관리해야 해요. 보안팀은 “rootless 사용 여부”를 단일 합격 기준으로 보지 말고, 노드의 전체 권한 경계를 다시 그려야 합니다.

도입 전 검증 순서

1. 지원 조건 기록: Kubernetes 1.37 버전, Linux 배포판, 커널 설정, CRI·OCI 런타임 버전을 고정해 기록합니다.
2. 노드 구성 확인: kubelet, 런타임, CNI 플러그인, kube-proxy가 사용자 네임스페이스 환경을 지원하는지 각 문서와 릴리스 노트로 확인합니다.
3. 워크로드 분류: 호스트 경로 마운트, 특권 컨테이너, 네트워크 장치, GPU·기타 장치 접근처럼 root를 전제로 한 워크로드를 따로 표시합니다.
4. 개발 클러스터 시험: 이미지 풀, 파드 생성·삭제, 서비스 네트워크, 볼륨 연결, 로그 수집, 노드 재시작을 차례로 재현합니다.
5. 실패 경로 준비: 기능을 끄고 노드를 되돌릴 방법, 문제 발생 시 격리할 라벨·풀, 로그 보존 위치를 먼저 정합니다.

처음부터 모든 노드를 바꾸기보다 권한이 큰 워크로드가 없는 별도 노드 풀에서 시험하는 편이 좋습니다. 성공 여부도 파드가 뜨는지 하나만 보지 말고, 이미지 캐시와 네트워크, 디스크 권한, 노드 업그레이드와 재부팅 뒤 상태까지 확인해야 합니다.

운영 환경에서 부딪힐 수 있는 예외

기존 이미지는 컨테이너 안에서 root로 시작한 뒤 특정 호스트 기능에 접근한다고 가정할 수 있습니다. 사용자 네임스페이스에서는 파일 소유자 매핑이 달라져 권한 오류가 나타날 수 있고, 호스트 경로에 기록하는 로그나 캐시가 예상과 다르게 동작할 수 있어요. CNI가 네트워크 네임스페이스와 권한을 처리하는 방식도 배포판마다 차이가 날 수 있습니다.

관리형 Kubernetes도 버전 번호만 같다고 같은 기능을 제공하지 않습니다. 클라우드 사업자가 노드 커널과 런타임을 관리하거나 기능 게이트를 제한할 수 있으므로, 공급자의 공식 지원 범위를 먼저 확인하세요. 이번 베타 발표만으로 특정 서비스에서 즉시 활성화됐다고 말할 수는 없습니다.

rootless 전환 전에 정리할 운영 기준

테스트 계획은 기능을 켜는 방법보다 중단 조건을 먼저 적는 편이 좋습니다. 예를 들어 이미지 풀은 성공하지만 CNI 초기화가 늦어지거나, 파드는 실행되는데 로그 수집 에이전트가 호스트 경로에 쓰지 못할 수 있습니다. 각 단계에 성공 기준과 되돌릴 기준을 함께 두면 “일단 켜 보고 문제가 생기면 고친다”는 식의 전환을 피할 수 있어요.

감사와 사고 대응도 설계에 포함해야 합니다. 노드 구성 요소가 어떤 사용자로 실행되는지, 기능 게이트를 언제 바꿨는지, 권한 오류가 어느 워크로드에서 발생했는지를 로그로 남겨야 합니다. 보안 개선을 위해 도입했는데 진단 로그가 사라지면 장애 대응이 늦어질 수 있어요. 운영팀과 보안팀이 같은 체크리스트를 보고 승인하도록 하는 것이 좋습니다.

보안 효과를 다른 통제와 연결하기

사용자 네임스페이스를 도입하더라도 파드 보안 표준, 최소 권한 RBAC, 이미지 출처 검증, 커널 패치, 네트워크 정책을 약화해서는 안 됩니다. rootless 노드가 침해 가능성을 낮추는 한 층이라면, 나머지 통제는 침해가 발생했을 때 움직임과 피해 범위를 제한하는 층입니다. 보안 검토 문서에는 어떤 위협을 줄이고 어떤 위협은 그대로 남는지 구분해 적으세요.

운영 중에는 기능 게이트 변경과 노드 교체를 같은 배포로 묶지 않는 편이 좋습니다. 먼저 한 노드에서 관찰하고, 문제가 없을 때 동일한 이미지와 설정으로 범위를 늘려야 원인 추적이 가능합니다. 버전 업그레이드 때 기능 기본값이나 런타임 동작이 변할 수 있으므로 릴리스 노트를 다시 읽는 것도 잊지 마세요.

특히 특권 컨테이너와 호스트 네트워크를 쓰는 워크로드는 일반 애플리케이션과 같은 성공 기준으로 평가하면 안 됩니다. 기능을 켠 노드에 배치하지 않거나 별도 정책으로 관리할지 결정하고, 예외를 만들었다면 소유자와 만료 시점을 기록하세요. 예외가 계속 늘어나면 rootless 전환의 실제 범위를 다시 계산해야 합니다.

이런 기록은 보안 개선의 근거이면서 장애 대응 자료이기도 합니다. 팀 문서에 테스트한 커널과 런타임 버전을 남겨 두면 다음 업그레이드 때 같은 검증을 반복하기 쉽습니다.

검증 결과는 기능 활성화 여부와 함께 운영 승인 기록에 남기세요.

자주 묻는 질문

rootless면 컨테이너 안에서 root를 쓸 수 없나요?

컨테이너 내부의 UID 0과 호스트의 UID 0을 분리하는 방식입니다. 애플리케이션 안에서는 root처럼 보일 수 있지만 호스트에서는 비root로 매핑될 수 있어요.

보안팀은 무엇을 성과로 봐야 하나요?

기능을 켠 사실보다 권한 상승 경로 감소, 특권 워크로드 목록, 실패 시 복구 시간, 감사 로그 확보 여부를 기준으로 삼는 편이 현실적입니다.

기존 운영 클러스터에 바로 적용해도 되나요?

권장하기 어렵습니다. 노드와 런타임 조합을 복제한 테스트 환경에서 워크로드별 호환성을 확인하고 점진적으로 범위를 넓히세요.

Sources

1. [1] Kubernetes v1.37: KubeletInUserNamespace (aka Rootless mode) Graduates to Beta
2. [2] Use a User Namespace With a Pod