KubeVirt Blog를 보다가 관심 가는 글이 보여서 AI번역+약간 교정해 보았습니다.
출처: https://kubevirt.io/2025/Hardening-VMIM.html
컨텍스트
VM 라이브 마이그레이션 요청은 VirtualMachineInstanceMigration 인스턴스로 표현됩니다. VirtualMachineInstanceMigration(VMIM)은 네임스페이스가 지정된 CRD이며, 해당 인스턴스는 참조하는 VM의 네임스페이스에 있어야 합니다.
KubeVirt v1.4 이전 버전에서는 기본적으로 네임스페이스 관리자(일반적으로 덜 공식적인 정의에서는 네임스페이스 “소유자”)가 VM을 생성하고 VMIM 객체를 생성하여 네임스페이스 내 VM에 대한 라이브 마이그레이션 요청을 큐에 추가할 수 있었습니다. 동시에, 라이브 마이그레이션은 노드 드레이닝이나 업그레이드와 같은 중요한 인프라 작업의 일부로 트리거될 수 있으며, 이러한 작업은 클러스터 관리자의 영역입니다.
따라서 네임스페이스 관리자가 진행 중인 인프라 중요 작업에 필요한 마이그레이션 요청을 지속적으로 큐에 추가하거나 예약된 VMIM 객체를 삭제할 수 있다면, 더 큰 권한을 가진 클러스터 관리자가 시작하는 클러스터 중요 작업을 지연시키거나 심지어 차단할 수도 있습니다.
따라서 권한이 낮은 악의적인 사용자가 이를 악용하여 클러스터 수준에서 일종의 서비스 거부(DoS)를 유발할 가능성이 있었습니다. 더 심각한 문제는 Kubernetes RBAC 권한이 순전히 가산적(“거부” 규칙이 없음)이고 KubeVirt 역할은 virt-operator에 의해 지속적으로 조정되기 때문에, 문제를 인지하고 있던 클러스터 관리자조차도 예방 조치로 이러한 권한을 거부할 수 없었다는 것입니다.
이러한 이유로 KubeVirt v1.5부터 최소 권한 원칙에 따라 모든 네임스페이스 관리자에게 생성/삭제/업데이트 권한이 기본적으로 부여되지 않습니다. 클러스터 관리자가 선택한 사용자에게 이 권한을 쉽게 부여할 수 있도록 새로운 편리한 kubevirt.io:migrate라는 이름의 ClusterRole이 도입되었습니다.
핫플러그 작업에 대한 부작용
CPU와 메모리에 대한 장치 핫플러그 작업은 사용자를 대신하여 virt-controller가 실행하는 라이브 마이그레이션을 암시적으로 트리거합니다. 이러한 작업은 이 변경 사항의 영향을 받지 않습니다. 일부 상황이나 클러스터 구성에서는 NIC 장치가 핫플러그될 때 라이브 마이그레이션이 자동으로 트리거되지 않습니다. 이러한 경우 네임스페이스 관리자가 사용할 수 있는 유일한 옵션은 클러스터 관리자에게 VMIM 권한을 요청하여 마이그레이션을 수동으로 트리거하거나 두 개의 장치 핫플러그 작업을 연결하는 것입니다(두 번째 작업은 NIC 핫플러그를 암시적으로 완료합니다).
클러스터 관리 작업
클러스터 관리자는 다음을 사용하여 네임스페이스 범위에서 선택한 신뢰할 수 있는 사용자/그룹에 새 kubevirt.io:migrate ClusterRole을 바인딩할 수 있습니다.
kubectl create -n usernamespace rolebinding kvmigrate --clusterrole=kubevirt.io:migrate --user=user1 --user=user2 --group=group1또는 클러스터 범위에서:
kubectl create clusterrolebinding kvmigrate --clusterrole=kubevirt.io:migrate --user=user1 --user=user2 --group=group1클러스터 관리자는 다음을 사용하여 이전 동작(모든 네임스페이스 관리자가 마이그레이션을 관리할 수 있음)을 복원할 수도 있습니다.
kubectl label --overwrite clusterrole kubevirt.io:migrate rbac.authorization.k8s.io/aggregate-to-admin=true업그레이드 프로세스로 인한 중단을 원치 않는 매우 신중한 클러스터 관리자는 업그레이드 전에 마이그레이션을 위한 임시 ClusterRole을 생성하고 rbac.authorization.k8s.io/aggregate-to-admin=true로 레이블을 지정할 수 있습니다 . 예를 들어 다음과 같습니다.
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
labels:
rbac.authorization.k8s.io/aggregate-to-admin=true
name: kubevirt.io:upgrademigrate
rules:
- apiGroups:
- subresources.kubevirt.io
resources:
- virtualmachines/migrate
verbs:
- update
- apiGroups:
- kubevirt.io
resources:
- virtualmachineinstancemigrations
verbs:
- get
- delete
- create
- update
- patch
- list
- watch
- deletecollection이 ClusterRole은 KubeVirt 업그레이드 전에 역할에 집계되며 admin, 업그레이드 프로세스는 이를 수정하지 않으므로 이전 동작이 유지됩니다. 업그레이드 후 클러스터 관리자는 임시 ClusterRole을 제거하기 전에 새 kubevirt.io:migrate ClusterRole을 선택한 사용자에게 바인딩할 충분한 시간을 갖게 됩니다.
