Kubernetes 1.37 Rootless Kubelet Beta: 루트 권한을 줄이되 경계를 과신하지 않는 운영법

Kubernetes 1.37 Rootless Kubelet Beta

Kubernetes 1.37에서 KubeletInUserNamespace 기능이 beta로 승격됐다.[7] 한 문장으로 줄이면 적절한 user namespace 안에서 kubelet을 포함한 노드 구성 요소를 호스트의 비루트 사용자로 실행할 수 있게 하는 기능이다.[7] 그러나 이 설명만 보고 기존 노드의 kubelet이 업그레이드와 동시에 rootless로 바뀐다거나, Pod가 자동으로 격리된다거나, 커널 취약점까지 막힌다고 이해하면 운영 판단이 틀어진다.

이번 변화의 핵심은 “Kubernetes가 root를 없앴다”가 아니다. 노드 구성 요소가 호스트에서 사용하는 권한을 user namespace라는 경계 안으로 재배치할 수 있는 공식 경로가 beta 수준에 도달했다는 뜻이다. Kubernetes 1.37은 2026년 8월 26일 공개됐고, 전체 릴리스에는 67개 개선 사항이 포함됐다.[9] 그 가운데 rootless kubelet은 보안 효과가 분명하지만 전환 비용과 호환성 위험도 함께 가진 변화다.

운영팀이 물어야 할 질문은 기능을 켤 수 있는지가 아니다. 어떤 노드에서 어떤 워크로드를 대상으로, 어떤 의존성을 검증한 뒤, 어떤 관측 신호를 보며, 문제가 생기면 어디까지 되돌릴 것인가가 더 중요하다. 이 글은 rootless를 완전한 sandbox로 포장하지 않고 그 경계와 도입 절차를 운영 관점에서 정리한다.

beta가 의미하는 것과 의미하지 않는 것

KubeletInUserNamespace의 beta 승격은 Kubernetes 프로젝트가 이 실행 모드를 더 넓게 시험할 단계로 올렸다는 신호다.[7] 기능 gate도 기본 활성화 상태다.[7] 하지만 “gate가 켜져 있다”와 “kubelet이 user namespace 안에서 실행 중이다”는 전혀 다른 상태다.

기능 gate는 kubelet이 해당 실행 모델을 이해하고 관련 동작을 허용한다는 뜻에 가깝다. 기존 rootful 노드에 Kubernetes 1.37 바이너리를 배포하는 것만으로 프로세스가 새로운 user namespace로 이동하지 않는다. 공식 설명도 기존 rootful 클러스터는 그대로 rootful로 남는다고 명시한다.[7] 따라서 버전 업그레이드 결과를 곧바로 권한 축소 결과로 보고해서는 안 된다.

이 구분은 변경 관리에서 중요하다. “1.37 업그레이드”와 “rootless 노드 전환”은 같은 작업 묶음에 넣기보다 별도의 변경으로 관리하는 편이 안전하다. 전자는 제어면과 노드 버전, API 호환성, 일반 회귀를 확인하는 작업이다. 후자는 호스트의 프로세스 실행 방식, user namespace 준비, 런타임과 네트워크·스토리지 의존성, 워크로드 적합성을 함께 검증하는 작업이다. 장애가 발생했을 때 원인이 버전 변경인지 권한 모델 변경인지 분리할 수 있어야 한다.

운영 완료 조건도 “feature gate가 기본값인지 확인”으로 끝나면 안 된다. 노드가 실제로 어떤 모드에서 실행되는지 확인하고, 그 상태가 인벤토리와 대시보드, 배포 정책에 반영됐는지까지 검증해야 한다.

노드 구성 요소 rootless와 Pod user namespace는 다르다

가장 먼저 끊어야 할 오해는 rootless kubelet과 Pod user namespace를 같은 기능으로 보는 것이다. KubeletInUserNamespace는 kubelet 같은 노드 구성 요소의 호스트 권한을 줄이기 위한 실행 모델이다. 반면 Pod 명세의 hostUsers: false는 Pod가 호스트 user namespace를 공유하지 않도록 하는 워크로드 단위 기능이다. 공식 문서도 두 개념을 혼동하지 말라고 강조한다.[7]

둘은 적용 대상과 질문이 다르다.

노드 구성 요소 rootless는 “kubelet 프로세스가 호스트에서 누구로 실행되는가”를 다룬다.
Pod user namespace는 “컨테이너 내부 사용자 ID가 호스트 사용자 ID와 어떻게 분리되는가”를 다룬다.
전자는 노드 프로비저닝과 서비스 실행 환경의 책임이다.
후자는 Pod 명세, 워크로드 호환성, 배포 정책의 책임이다.

따라서 rootless kubelet 노드에서 모든 Pod가 자동으로 hostUsers: false가 되는 것은 아니다. 반대로 Pod user namespace를 사용하는 워크로드가 있다고 해서 kubelet 자체가 비루트 호스트 사용자로 실행되는 것도 아니다.[7] 두 기능은 함께 사용할 수 있는 보안 계층이지만, 하나가 다른 하나를 암시하지 않는다.

이 차이를 문서와 대시보드에서도 유지해야 한다. “user namespace 사용”이라는 하나의 필드로 합치면 노드 상태와 워크로드 상태가 뒤섞인다. 최소한 노드 실행 모드, Pod의 user namespace 요청 여부, 실제 스케줄된 노드 풀을 별도 축으로 기록하는 편이 낫다. 보안 리뷰에서도 “rootless 지원”이라는 체크 하나 대신 노드와 Pod를 따로 판정해야 한다.

실제 상태는 `runningInUserNamespace`로 확인한다

Kubernetes 1.37 노드는 .status.nodeInfo.runningInUserNamespace를 통해 노드가 해당 모드로 동작하는지 보고한다.[7] 이 값은 선언한 의도보다 실제 상태에 가까운 확인 지점이다. 운영 자동화는 설치 스크립트가 성공했다는 기록이나 feature gate 설정만 보지 말고 Node 상태를 읽어야 한다.

예를 들어 점검 절차는 다음 질문에 답해야 한다.

rootless 전용으로 준비한 노드가 runningInUserNamespace 상태를 보고하는가.
일반 rootful 노드는 의도한 대로 기존 상태를 유지하는가.
재부팅하거나 kubelet 서비스를 재시작한 뒤에도 상태가 유지되는가.
노드 교체와 자동 확장으로 새로 들어온 인스턴스도 같은 상태를 보고하는가.
상태가 기대와 다르면 워크로드가 유입되기 전에 격리되는가.

여기서 중요한 것은 이 필드를 단순 표시용으로 끝내지 않는 것이다. 인벤토리 수집, 알림, 노드 풀 적합성 검사에 연결해야 한다. rootless 풀로 선언된 노드가 실제 상태를 보고하지 않으면 준비 실패로 취급하고, 일반 워크로드를 받기 전에 조사하는 방식이 합리적이다.

다만 상태 필드 하나가 전체 호환성을 증명하지는 않는다. user namespace 안에서 실행된다는 사실은 확인할 수 있어도 CNI 경로, CSI 볼륨, 런타임 동작, 개별 워크로드가 정상이라는 결론까지 대신하지 않는다. 상태 확인은 출발점이지 합격 판정의 전부가 아니다.

user namespace는 Kubernetes 밖에서 준비한다

rootless kubelet을 실제로 사용하려면 적절한 user namespace를 Kubernetes 외부에서 만들어야 한다.[7] 이것은 기능 gate를 활성화하는 일과 실행 환경을 구성하는 일이 분리돼 있다는 뜻이다. Kubernetes API에 Node 객체를 만들거나 kubelet 옵션을 추가하는 것만으로 호스트의 namespace가 준비되지는 않는다.

운영 책임은 이미지 빌드, 부팅 스크립트, 서비스 관리자, 노드 프로비저닝 계층으로 이동한다. 어떤 방식이든 조직은 다음 항목을 명시해야 한다.

user namespace를 누가, 어느 부팅 단계에서 생성하는가.
kubelet과 관련 노드 구성 요소가 그 namespace 안에서 시작되는가.
서비스 재시작과 호스트 재부팅 뒤에도 같은 실행 모델이 재현되는가.
실패했을 때 rootful로 조용히 기동하는지, 아니면 노드를 실패 처리하는지.
노드 이미지 버전과 namespace 구성 버전을 어떻게 함께 추적하는가.
자동 확장기가 만든 새 노드도 동일한 절차를 거치는가.

특히 조용한 fallback은 피하는 편이 좋다. rootless 풀로 분류된 노드가 준비 실패 뒤 rootful로 올라오면 워크로드는 정상 실행될 수 있어 장애 신호가 약하다. 그러나 기대한 권한 경계는 사라진다. 서비스 가용성만 보는 모니터링으로는 이 구성을 발견하기 어렵다. runningInUserNamespace 상태와 노드 풀의 선언을 대조해야 하는 이유다.

user namespace 생성 절차는 클러스터 매니페스트와 별개이므로 GitOps 범위 밖에 놓일 수도 있다. 그렇다면 머신 이미지, IaC, 부팅 설정, 서비스 단위 파일 중 실제 소유 위치를 명확히 정하고 리뷰와 변경 이력을 남겨야 한다. “클러스터 설정은 코드로 관리한다”는 문장만으로 호스트 준비 단계까지 관리되고 있다고 가정해서는 안 된다.

kernel과 container runtime을 먼저 검증한다

이 기능은 “적절한 user namespace”가 있다는 전제 위에서 동작한다.[7] 따라서 커널과 container runtime을 일반적인 Kubernetes 버전 호환성 표만으로 판단하면 부족하다. 실제 노드 이미지와 실제 런타임 조합에서 rootless 실행 경로를 시험해야 한다.

커널 측 검증은 user namespace가 생성되고 유지되는지, 재부팅 후 같은 구성이 재현되는지, 노드 구성 요소가 필요한 작업을 수행하는지에 초점을 둔다. 배포 이미지가 서로 다르면 같은 Kubernetes 1.37이라도 결과를 하나로 일반화하지 말아야 한다. 개발용 이미지에서 성공한 결과를 별도 커널 설정을 쓰는 운영 이미지에 그대로 적용하는 것도 피해야 한다.

런타임 검증은 kubelet이 시작된다는 사실보다 Pod 생명주기가 끝까지 동작하는지를 봐야 한다. 이미지 준비, Pod 생성과 종료, 재시작, 노드 drain, 노드 재가입처럼 운영 중 반복되는 경로를 시험한다. 실패가 권한 문제로 나타나는지, 재시도가 무한히 이어지는지, 이벤트와 로그가 원인 분석에 충분한지도 확인한다.

여기서 중요한 원칙은 “지원한다고 알려진 조합”과 “우리 환경에서 검증한 조합”을 구분하는 것이다. beta 도입 초기에 지원 범위를 넓게 선언하기보다 검증한 커널 이미지와 런타임 버전을 좁게 고정하는 편이 낫다. 조합을 바꿀 때마다 rootless 회귀 테스트를 다시 실행하면 문제 범위를 줄일 수 있다.

CNI와 CSI는 데이터 경로로 시험한다

공식 설명은 일부 CNI와 CSI 드라이버에 호환성 주의점이 남아 있다고 밝힌다.[7] 이 문장은 단순히 설치가 실패할 수 있다는 의미로만 읽으면 안 된다. 네트워크와 스토리지는 워크로드가 실제 트래픽과 데이터를 처리하는 경로이므로, 플러그인 DaemonSet이 Running인지 확인하는 것만으로는 충분하지 않다.

CNI 검증은 최소한 서로 다른 노드 사이의 통신, 서비스 경유 통신, DNS 조회, Pod 생성과 삭제 뒤의 정리, 노드 drain 뒤 재스케줄 경로를 포함해야 한다. 조직이 네트워크 정책을 사용한다면 허용과 차단이 기존 노드와 동일하게 적용되는지도 확인한다. rootless 노드에서만 간헐적인 연결 실패가 발생할 때 식별할 수 있도록 노드 풀과 네트워크 지표를 연결해 두는 것이 좋다.

CSI 검증은 사용하는 스토리지 클래스마다 수행해야 한다. 볼륨 생성, attach와 mount, 읽기와 쓰기, Pod 재시작, 노드 이동, detach와 삭제를 순서대로 확인한다. 상태를 가진 워크로드는 정상 경로뿐 아니라 중단과 복구 경로가 중요하다. 테스트용 빈 볼륨에서 성공했다고 기존 데이터와 복구 절차까지 안전하다고 결론 내리면 안 된다.

플러그인 호환성은 이름만으로 관리하기보다 버전과 설정을 포함한 조합으로 기록해야 한다. 같은 CNI나 CSI라도 배포 방식과 버전이 다르면 검증 결과의 적용 범위가 달라질 수 있다. 검증되지 않은 드라이버가 필요한 워크로드는 처음부터 rootful 풀에 남겨 두는 것이 안전하다.

rootless는 완전한 sandbox가 아니다

rootless kubelet의 분명한 장점은 노드 구성 요소가 호스트의 비루트 사용자로 실행될 수 있다는 데 있다.[7] 이는 노드 프로세스가 처음부터 호스트 root로 동작하는 모델과 다른 권한 경계를 만든다. 그러나 경계 하나가 추가됐다는 사실을 완전한 격리로 번역해서는 안 된다.

user namespace는 커널 취약점을 완화하지 않는다.[7] 노드 구성 요소와 컨테이너가 결국 같은 호스트 커널에 의존한다는 점은 변하지 않는다. rootless 전환 뒤에도 seccomp와 다른 하드닝을 계속 적용해야 한다는 것이 공식 권고다.[7]

따라서 보안 문서에서 “rootless이므로 host compromise가 불가능하다”거나 “sandbox가 제공된다”고 쓰면 과장이다. 더 정확한 표현은 “호스트에서 노드 구성 요소가 사용하는 기본 권한을 줄이는 계층”이다. 이 계층은 패치 관리, seccomp, 최소 권한, 네트워크 정책, 이미지 관리, 런타임 보호를 대체하지 않는다.

위협 모델도 구분해야 한다. 잘못된 kubelet 동작이나 노드 구성 요소 침해가 곧바로 호스트 root 권한과 같아지는 경로를 줄이는 것이 목표일 수 있다. 그러나 커널 자체의 결함을 이용하는 공격까지 같은 경계가 막는다고 가정할 수는 없다. 보안 효과를 설명할 때 “무엇의 권한을 줄였는가”와 “무엇은 여전히 공유되는가”를 한 문단 안에 함께 적는 편이 좋다.

감사 항목 역시 rootless 여부 하나로 끝나지 않아야 한다. 노드 패치 수준, seccomp 적용, 워크로드 권한, 플러그인 호환성, 런타임 설정을 별도로 추적해야 한다. rootless는 방어 심층화의 한 층이지 다른 층을 제거할 면허가 아니다.

별도 node pool로 실패 범위를 제한한다

기존 노드를 제자리에서 모두 바꾸기보다 rootless 전용 node pool을 새로 만드는 접근이 운영상 유리하다. 기존 rootful 풀을 기준선과 롤백 목적지로 유지하면 권한 모델 변경 때문에 생긴 문제를 비교하기 쉽다. 또한 호환성이 확인된 워크로드만 선택적으로 이동할 수 있다.

전용 풀에는 실행 모드를 나타내는 label을 붙이고, 검증 전에는 taint로 일반 워크로드 유입을 막는 편이 좋다. 다만 label 이름 자체가 보안을 만들지는 않는다. 실제 runningInUserNamespace 상태와 선언된 label이 일치하는지 자동으로 검사해야 한다. 사람이 붙인 label만 신뢰하면 잘못 준비된 노드가 rootless로 분류될 수 있다.

스케줄링 정책은 두 단계로 나누면 명확하다.

초기 단계에서는 rootless 검증용 taint를 두고, 명시적인 toleration과 node affinity가 있는 canary 워크로드만 받는다.
검증이 끝난 뒤에도 호환성 등급에 따라 대상 워크로드를 제한하고, 검증되지 않은 워크로드가 우연히 들어오지 않도록 정책을 유지한다.

rootful과 rootless 풀의 capacity도 따로 본다. rollback 때 모든 canary 워크로드를 rootful 풀로 되돌릴 여유가 없다면 롤백 계획은 문서상 계획일 뿐이다. 반대로 rootless 풀을 너무 작게 만들면 스케줄 실패가 기능 문제인지 단순 자원 부족인지 헷갈린다. 시험 규모와 복구 여유를 함께 계산해야 한다.

workload compatibility를 등급으로 관리한다

rootless 전환은 노드 기능이지만 성공 여부는 결국 워크로드에서 드러난다. 모든 Deployment가 동일한 네트워크, 스토리지, 권한 요구를 갖지 않으므로 한 번의 샘플 테스트로 전체 호환성을 선언할 수 없다.

먼저 워크로드를 다음처럼 분류할 수 있다.

상태가 없고 외부 의존성이 단순한 서비스
일반적인 Service 통신과 네트워크 정책을 사용하는 서비스
CSI 영구 볼륨을 사용하는 상태 저장 서비스
노드 동작과 밀접한 운영 에이전트
검증되지 않은 CNI·CSI 경로나 특수한 호스트 의존성을 가진 서비스

초기 canary는 첫 번째 그룹에서 고르는 편이 낫다. 다음 단계에서 실제 네트워크 정책을 쓰는 서비스와 비핵심 상태 저장 워크로드를 추가한다. 노드에 밀접하게 결합된 구성 요소와 중요한 데이터 워크로드는 마지막까지 별도 검증한다.

호환성 표에는 단순한 가능·불가능 대신 조건을 적는다. 검증한 노드 이미지, runtime, CNI, CSI, Kubernetes patch 버전, 워크로드 릴리스와 시험 날짜를 남긴다. “rootless 지원”이라는 셀 하나는 주변 조합이 바뀌었을 때 의미를 잃는다.

또한 애플리케이션 성공률만 보지 말고 운영 작업을 포함해야 한다. 배포, autoscaling, 재시작, drain, 노드 교체, 볼륨 재연결, 장애 조사, 로그 수집이 기존 방식으로 가능한지 확인한다. 평상시 요청은 처리하지만 drain 뒤 복구되지 않는 워크로드는 운영 관점에서 호환된 것이 아니다.

단계적 rollout 절차

실제 도입은 작은 검증에서 시작해 실패 범위를 통제하며 넓혀야 한다. 다음 순서는 rootless를 별도 보안 프로젝트가 아니라 노드 플랫폼 변경으로 다루는 예시다.

1. 기준선 수집

기존 rootful 노드에서 Pod 시작 시간, 실패율, 재시작, 네트워크 오류, 볼륨 작업, drain 소요 시간을 기록한다. 비교 기준이 없으면 rootless 풀의 문제가 기존에도 있던 현상인지 판단하기 어렵다. 장애 대응팀이 평소 보는 로그와 이벤트 경로도 함께 확인한다.

2. 고정된 검증 조합 선정

한 종류의 노드 이미지, 커널 구성, container runtime, CNI, CSI 조합을 선정한다. rootless 전용 이미지와 프로비저닝 절차를 버전으로 관리한다. user namespace가 외부에서 생성되고 노드 구성 요소가 그 안에서 시작되는지 확인한다.[7]

3. 빈 노드 검증

워크로드를 받기 전에 kubelet 시작, 재시작, 호스트 재부팅, 클러스터 재가입을 시험한다. Node의 .status.nodeInfo.runningInUserNamespace가 기대한 상태인지 확인한다.[7] 선언과 실제 상태가 다르면 taint를 제거하지 않는다.

4. 플랫폼 smoke test

일회성 테스트 Pod로 이미지 실행, DNS, Service 통신, 노드 간 통신, 종료와 정리를 확인한다. 사용하는 스토리지 클래스마다 볼륨 생명주기를 시험한다. 이 단계에서 CNI·CSI의 명백한 비호환성을 먼저 걸러낸다.

5. canary 워크로드 배치

데이터 손실 위험이 낮고 트래픽을 쉽게 우회할 수 있는 워크로드를 선택한다. toleration과 affinity로 rootless 풀에만 배치한다. 애플리케이션 지표뿐 아니라 kubelet 이벤트, runtime 오류, 네트워크와 볼륨 지표를 함께 본다.

6. 운영 시나리오 실행

단순히 며칠 기다리지 말고 재배포, Pod 강제 종료, 노드 drain, 노드 교체, autoscaling을 의도적으로 실행한다. 정상 기동만 확인해서는 실제 장애와 유지보수 경로를 검증할 수 없다. 야간 대응자가 문제를 식별하고 원인을 찾을 수 있는지도 점검한다.

7. 범위 확대

호환성 표에 통과한 워크로드 유형을 하나씩 추가한다. 각 확대 단계는 이전 단계보다 하나의 주요 변수를 추가하는 방식이 좋다. 예를 들어 네트워크 정책 워크로드를 검증한 뒤 CSI 워크로드로 넘어가면 실패 영역을 좁힐 수 있다.

8. 기본 정책 재검토

충분한 운영 기간과 시나리오 검증을 거친 뒤에만 새 워크로드의 기본 풀로 고려한다. 그때도 kernel 취약점 대응, seccomp와 다른 하드닝은 유지한다.[7] rootless 확대를 이유로 기존 방어 계층을 제거하지 않는다.

rollback은 기능 gate가 아니라 워크로드 이동 계획이다

rootless 전환의 롤백을 KubeletInUserNamespace gate 비활성화로만 생각하면 부족하다. gate가 기본 활성화돼 있어도 기존 노드는 자동 전환되지 않으며, 실제 실행 모드는 외부에서 준비한 user namespace와 노드 기동 방식에 달려 있다.[7] 따라서 롤백 단위는 설정 한 줄보다 노드 이미지와 node pool에 가깝다.

안전한 롤백은 rootless 노드를 현장에서 급히 rootful로 바꾸는 것보다 검증된 rootful 풀로 워크로드를 이동하고 문제가 있는 노드를 교체하는 방식이 단순하다. 권한 모델을 제자리에서 바꾸면 동일 노드의 잔여 상태와 실패 원인을 해석하기 어려울 수 있다.

롤백 조건은 사전에 수치와 사건으로 정한다. 예를 들면 Pod 생성 실패 증가, CNI 정리 실패, 볼륨 attach·mount 이상, drain 실패, runningInUserNamespace 상태 불일치, 노드 재부팅 후 복구 실패가 기준이 될 수 있다. 중요한 것은 장애가 커진 뒤 회의에서 기준을 만드는 것이 아니라 canary 이전에 합의하는 것이다.

rollout 체크리스트

rollback 체크리스트

운영 지표와 책임 경계를 다시 설계한다

rootless 노드를 도입하면 기존 모니터링의 사각지대가 드러날 수 있다. 애플리케이션 SLO만 보면 요청이 정상인 동안 실행 모드 불일치를 놓친다. 반대로 kubelet 프로세스가 살아 있다는 지표만 보면 실제 네트워크와 볼륨 실패를 놓친다. 노드 상태, 플랫폼 데이터 경로, 워크로드 결과를 세 층으로 나눠 관측해야 한다.

노드 층에서는 runningInUserNamespace, 노드 준비 상태, 재부팅과 재가입 결과를 본다. 플랫폼 층에서는 runtime 작업, CNI 연결과 정리, CSI attach와 mount 경로를 본다. 워크로드 층에서는 시작 지연, 오류율, 재시작, 재스케줄 결과를 본다. 세 층을 같은 node pool label로 연결하면 rootless 풀과 rootful 풀을 비교하기 쉬워진다.

책임 경계도 명확히 해야 한다. 노드 플랫폼 팀은 user namespace 생성, 이미지, runtime, 실제 실행 상태를 소유한다. 네트워크와 스토리지 팀은 사용 중인 CNI·CSI 조합의 검증 결과와 예외를 관리한다. 애플리케이션 팀은 워크로드 호환성과 canary 결과를 확인한다. 보안팀은 rootless가 줄이는 권한과 줄이지 못하는 커널 위험을 구분해 통제 기준을 유지한다.

결론

Kubernetes 1.37의 KubeletInUserNamespace beta는 kubelet 같은 노드 구성 요소를 호스트 비루트 사용자로 실행하는 경로가 한 단계 성숙했다는 의미다.[7] 하지만 feature gate의 기본 활성화가 실제 rootless 전환을 의미하지 않으며, 기존 rootful 클러스터는 자동으로 바뀌지 않는다.[7] 실제 상태는 runningInUserNamespace로 확인하고, user namespace는 Kubernetes 밖에서 준비해야 한다.[7]

도입의 핵심은 기능을 켜는 명령보다 호환성 경계를 관리하는 데 있다. 커널과 runtime 조합을 고정해 검증하고, CNI와 CSI를 실제 데이터 경로로 시험하며, 별도 node pool과 label·taint로 워크로드 유입을 통제해야 한다. Pod user namespace와 노드 구성 요소 rootless를 분리해 설명하고, 워크로드별 호환성을 단계적으로 넓혀야 한다.

무엇보다 rootless를 완전한 sandbox로 과장해서는 안 된다. user namespace는 커널 취약점을 막지 않으며 seccomp와 다른 하드닝은 계속 필요하다.[7] 현실적인 목표는 하나의 거대한 보안 약속이 아니라, 노드 구성 요소의 기본 권한을 줄이고 실패 범위를 작은 풀에 가두며 검증된 조합을 점진적으로 늘리는 것이다.

성공적인 rollout의 기준은 모든 노드에 빠르게 적용하는 것이 아니다. 어떤 노드가 실제 rootless인지 증명할 수 있고, 어떤 워크로드와 플러그인이 호환되는지 기록돼 있으며, 문제가 생겼을 때 rootful 기준선으로 예측 가능하게 돌아갈 수 있는 상태가 성공이다. beta는 출발 허가이지 전면 전환 명령이 아니다.

Sources

[7] https://kubernetes.io/blog/2026/09/04/kubernetes-v1-37-rootless-beta — Kubernetes v1.37 rootless mode graduates to Beta [9] https://kubernetes.io/blog/2026/08/26/kubernetes-v1-37-release — Kubernetes v1.37 release