26A09d
Operator가 필요한 리소스를 볼 수 있는 '눈(권한)'이 있는지 확인하는 과정입니다. 쿠버네티스에서 권한은 ServiceAccount -> RoleBinding -> ClusterRole의 연결 고리로 이어집니다.
다음 순서대로 터미널에서 입력하며 점검해 보세요.
1. Operator가 사용하는 ServiceAccount 찾기
먼저 MinIO Operator 포드가 어떤 계정으로 구동 중인지 확인합니다.
# minio-operator 네임스페이스(또는 설치한 네임스페이스)의 포드 확인
kubectl get pod -n minio-operator -o jsonpath='{.items[0].spec.serviceAccountName}'- 보통 결과로
minio-operator또는operator라는 이름이 나옵니다. 이를 [SA_NAME]이라고 하겠습니다.
2. 해당 계정에 연결된 ClusterRole 찾기
이제 그 계정에 어떤 권한 꾸러미(ClusterRole)가 묶여 있는지 확인합니다.
kubectl get clusterrolebinding -o json | jq -r '.items[] | select(.subjects[]?.name == "[SA_NAME]") | .roleRef.name'[SA_NAME]자리에 위에서 찾은 이름을 넣으세요.- 보통
minio-operator-role같은 이름이 출력될 것입니다. 이를 [ROLE_NAME]이라고 하겠습니다.
3. ClusterRole의 상세 권한(sts.min.io) 확인
가장 중요한 단계입니다. 해당 역할에 에러 메시지에 나온 sts.min.io 그룹과 policybindings 리소스 권한이 있는지 봅니다.
kubectl get clusterrole [ROLE_NAME] -o yaml출력 내용 중 rules: 섹션에 아래와 같은 내용이 반드시 포함되어 있어야 합니다.
- apiGroups:
- sts.min.io # 이 그룹이 정의되어 있는지 확인
resources:
- policybindings # 에러가 났던 리소스 이름
verbs:
- get
- list
- watch
- patch
- update4. 즉석 권한 테스트 (권한 시뮬레이션)
복잡하게 설정을 뒤지는 대신, 쿠버네티스의 auth can-i 명령어를 사용하면 Operator의 입장에서 권한을 바로 테스트해 볼 수 있습니다.
# "minio-operator" 네임스페이스의 "minio-operator" 서비스 계정이
# policybindings 리소스를 list 할 수 있는가?
kubectl auth can-i list policybindings.sts.min.io \
--as=system:serviceaccount:minio-operator:minio-operator \
--all-namespaces- 결과가
yes라면: 권한 문제는 아닙니다. CRD가 설치되지 않았거나 버전이 안 맞는 것입니다. - 결과가
no라면: RBAC(권한 설정) 문제입니다.ClusterRole을 수정하여 권한을 추가해야 합니다.
💡 해결 팁
만약 no가 나온다면, Operator 설치 시 사용한 Helm chart나 YAML 파일이 최신 버전인지 확인하고 다시 apply 하시는 것이 좋습니다. 수동으로 ClusterRole을 수정하면 나중에 업데이트할 때 설정이 꼬일 수 있기 때문입니다.
현재 auth can-i 결과가 어떻게 나오시나요? 결과에 따라 다음 조치를 알려드릴 수 있습니다.
engineer