설명
ClusterRoleBinding이 cluster-admin 역할을 연결하면 해당 주체는 클러스터 전체에 대해 거의 모든 권한을 갖게 됩니다. 이 권한은 설정 조회, 변경, 삭제뿐 아니라 다른 주체의 권한을 바꾸는 데도 쓰일 수 있습니다. 운영 환경에서는 꼭 필요한 주체에만 최소 범위 권한을 부여해야 합니다.
잠재적 영향
- 계정 하나가 침해되면 클러스터 전체 자원이 영향을 받을 수 있습니다.
- 실수로 중요한 리소스를 변경하거나 삭제할 위험이 커집니다.
해결 방법
- 기존 cluster-admin 바인딩의 주체와 필요한 작업을 검토하세요. 조회만 필요하면 view 또는 필요한 리소스·작업만 허용한 사용자 정의 역할을 사용하고, 네임스페이스 범위 작업에는 RoleBinding을 사용하세요.
- 새 바인딩만 추가해도 기존 관리자 권한은 남습니다. roleRef는 변경할 수 없으므로 필요한 관리자 접근을 확보한 뒤 기존 바인딩을 계획적으로 제거·교체하고 실제 권한을 확인하세요.
예시
역할 차이를 비교하는 기존 예시이며 tiller는 과거 Helm 2 서비스 계정 이름입니다. 새 Tiller 배포를 권장하는 예시는 아닙니다.
변경 전
yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: admin-binding
subjects:
- kind: ServiceAccount
name: tiller
namespace: kube-system
roleRef:
kind: ClusterRole
name: cluster-admin
apiGroup: rbac.authorization.k8s.io
tiller 서비스 계정에 클러스터 전체 관리자 권한을 부여합니다.
변경 후
yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: view-binding
subjects:
- kind: ServiceAccount
name: tiller
namespace: kube-system
roleRef:
kind: ClusterRole
name: view
apiGroup: rbac.authorization.k8s.io
별도 view-binding을 추가합니다. view도 이 ClusterRoleBinding을 통해 클러스터 전체에 적용되며, 기존 admin-binding은 따로 제거해야 합니다.