[juu-n-oo]

Summary

• PM·PD 사용자별 ClusterRole 에 ibnetworks·sriovnodestates 의 get 권한을 추가한다.
• InfiniBand 화면(AIP-3537, aipub-web #1813)에서 PM·PD 가 두 CR 조회에 403 을 받는다. aipub-admin 만 cluster-admin 이라 Admin 만 통과하고, 사용자별 ClusterRole 에는 두 CR 규칙이 없었다.
• 정책서(Project Detail > Management 탭 — 2 Nodes, 2-2)는 InfiniBand 요약과 장치 막대를 모든 Role 에게 조회로 제공하고, 개수 배정만 Admin 전용으로 정하고 있다. 그래서 읽기만 준다.
• 두 CR 모두 Cluster scope 라 list 는 resourceNames 로 좁혀지지 않는다. 주면 전 프로젝트의 배정과 전 노드의 장치 상태가 열리므로 이름으로 좁힌 get 만 준다. 이름은 프론트가 안다 — IBNetwork 는 프로젝트 이름, SriovNodeState 는 노드 이름이고, IB 노드 여부는 get 의 200/404 로 가른다.
• 관련 티켓: AIP-3631

Changes

• RBAC (ReconciliationService#reconcileClusterRoleRules): nodeGpuUsages 규칙 뒤, PM 전용 블록 앞에 두 규칙을 추가했다. PM·PD 동일하게 verbs: ["get"] 이고, ibnetworks 는 resourceNames 를 프로젝트 이름으로, sriovnodestates 는 바인딩 노드 이름들로 좁힌다. 메서드 시그니처는 그대로다(project·bindingNodes 가 이미 인자).
• RBAC (빈 resourceNames 가드): 바인딩 노드가 없으면 sriovnodestates 규칙을 넣지 않는다. RBAC 에서 빈 resourceNames 는 전체 허용이라, 그대로 두면 노드가 0개인 프로젝트의 PM·PD 에게 전 노드가 열린다. 기존 nodes·nodegroups 규칙이 같은 이유로 쓰는 가드를 따랐다.
• 상수 (ProjectApiConstants): IB_NETWORK_RESOURCE_KIND/PLURAL, SRIOV_NODE_STATE_RESOURCE_KIND/PLURAL 추가.
• 테스트 (ReconciliationServiceInfinibandRulesTest): 신규 5건 — 프로젝트 이름으로 좁힌 IBNetwork get, 바인딩 노드로 좁힌 SriovNodeState get, 두 규칙이 get 외 verb 를 주지 않음, 바인딩 노드 0개면 SriovNodeState 규칙 생략, 반복 reconcile 결과 동일(reconcileExistingRole 의 List.equals 비교 통과).

Test plan

• ./gradlew compileJava compileTestJava test
• kubectl get clusterrole <PM·PD 사용자 ClusterRole> -o yaml — ibnetworks 는 resourceNames 가 프로젝트 이름 1건, sriovnodestates 는 바인딩 노드 목록, 둘 다 verbs: [get] 인지 확인
• kubectl auth can-i get ibnetworks/<프로젝트> --as=oidc:<PM 계정> → yes / kubectl auth can-i list ibnetworks --as=oidc:<PM 계정> → no
• kubectl auth can-i get sriovnodestates/<바인딩 노드> --as=oidc:<PD 계정> → yes / <바인딩되지 않은 노드> → no / list → no
• kubectl auth can-i patch ibnetworks/<프로젝트> --as=oidc:<PM 계정> → no (배정은 Admin 전용)
• 노드를 프로젝트에 연결·해제한 뒤 ClusterRole 의 sriovnodestates resourceNames 가 따라 갱신되고, 변경 없는 상태에서 반복 갱신되지 않는지 확인
• 바인딩 노드가 0개인 프로젝트의 PM·PD ClusterRole 에 sriovnodestates 규칙이 없는지 확인

여기만은 꼭 봐주세요

• 빈 resourceNames 가드의 범위 — 이번에는 sriovnodestates 에만 넣었다. 같은 함정이 기존 noderesources·gpuconfigs·nodegpuusages 에 남아 있다(가드 없이 withResourceNames(nodes)). 바인딩 노드가 0개인 프로젝트의 PM·PD 는 지금도 전 노드의 그 CR 들을 읽을 수 있다. 이번 티켓 범위 밖이라 건드리지 않았는데, 별도 티켓으로 끊을지 의견 부탁드린다.
• SriovNodeState 원본의 노출 범위 — CR 에는 spec.vfs[].owner.name(다른 프로젝트 이름), spec.vfs[].pkey, nodeGuid·portGuid, spec.pfs[].bdf 가 들어 있다. 정책서는 "다른 프로젝트 할당 {n}" 이라는 합계만 화면에 보이게 정하고 있어서, get 을 주면 화면에 그리지 않더라도 API 로는 그보다 많은 정보가 보인다. 이번 작업은 이를 허용하는 선택이다. 더 좁히려면 IB operator 가 IBNetwork.status.nodes[] 에 집계 필드(total·otherProjects·unassigned)를 넣어 SriovNodeState 조회 자체를 없애는 방향이 대안이다.
• 규칙 추가 위치 — reconcileExistingRole 이 List.equals(순서 비교)로 갱신 여부를 판단한다. 위치를 옮기면 기존 ClusterRole 이 한 번 갱신된다.

범위 밖 (후속)

• SM 없음 안내: 같은 subnet 의 프로젝트 밖 노드까지 봐야 master 유무를 판정할 수 있어 resourceNames 로 좁힐 수 없다. RBAC 으로는 풀 수 없고, IBNetwork.status 에 SM 요약 필드를 넣거나 프로젝트 범위 API 가 필요하다.
• aipub-web 의 list → 이름별 get 전환: 현재 프론트는 fetchSriovNodeStates()·fetchIbNetworks() 로 목록을 조회한다. 이 PR 만으로는 화면이 복구되지 않는다. FE 후속 티켓이 필요하다.

🚀 Release Version

v5.2.0