01
네임스페이스를 적기
오프라인 Role과 RoleBinding에는 metadata.namespace가 필요합니다. ClusterRole을 참조하는 RoleBinding도 자신의 네임스페이스 밖으로 확장되지 않습니다.
Kubernetes
쿠버네티스 RBAC 권한 분석권한을 부여한 경로 확인
역할과 바인딩 매니페스트를 붙여 넣고 준비되면 직접 분석하세요.
쿠버네티스 RBAC 권한 분석
관계와 발견 항목
RBAC 매니페스트를 붙여 넣고 분석하세요.
입력은 이 브라우저에서만 처리하며 클러스터 연결이나 네트워크 요청을 하지 않습니다.
권한 질의
*는 클러스터 범위입니다. 그래프만 보려면 질의 필드를 비워 두세요.
매니페스트를 붙여 넣으세요.
Role 하나만 읽으면 어떤 서비스 어카운트가 실제로 권한을 얻었는지 알기 어렵습니다. 쿠버네티스 RBAC 권한 분석은 주체와 롤바인딩을 이어 각 규칙의 출처를 보여 줍니다.
쿠버네티스 RBAC 권한 분석은 제공한 매니페스트만 봅니다. 실제 사용자 그룹, 기본 역할 및 다른 인가 방식이 빠졌다면 결과에 그 한계를 남깁니다.
쿠버네티스 RBAC 권한 분석이 필요한 이유
연결된 권한과 확인되지 않은 부분을 구분합니다.
허가마다 바인딩을 추적
RBAC 시각화는 User·Group·ServiceAccount에서 Binding과 Role, 규칙으로 이어집니다. ClusterRole을 RoleBinding으로 연결해도 권한은 그 네임스페이스에만 적용됩니다. 클러스터롤바인딩은 클러스터 전체에 적용됩니다.
위험 신호의 근거 표시
시크릿 전체 읽기, 와일드카드, 권한 상승 동사는 실제로 연결된 주체와 함께 표시됩니다. 누락된 역할이나 집계 역할은 거부로 단정하지 않고 정보 부족으로 분류합니다.
일치 여부보다 먼저 범위를 확인하세요
02
주체를 정확히 선택하기
User, Group, ServiceAccount는 서로 다른 주체입니다. 서비스 어카운트는 네임스페이스까지 구분하고 사용자 이름만으로 그룹 소속을 추측하지 않습니다.
03
이름 제한 확인하기
resourceNames가 있으면 리소스 이름을 넣으세요. list/watch는 일치하는 필드 셀렉터도 필요하지만 이 정적 질의는 실제 요청을 검사하지 못합니다.
권한 경로와 질의를 함께 검토
클릭 가능한 출처 경로
롤바인딩 권한을 주체 → 바인딩 → 역할 → 규칙으로 표시합니다. 노드를 선택하면 관련 경로를 모아 보고 범위와 API 그룹도 확인할 수 있습니다.
리소스·동사 질의
선택한 주체, 네임스페이스 또는 클러스터 범위, API 그룹, 리소스/하위 리소스, 동사를 입력해 붙여 넣은 규칙과 대조합니다.
근거가 남는 보고서
쿠버네티스 RBAC 권한 분석 보고서는 와일드카드, 시크릿 읽기, bind·escalate·impersonate 및 pods/exec의 출처 바인딩을 적습니다.
정적 매니페스트의 판단 범위
- 운영 클러스터 판정 아님
- 쿠버네티스 RBAC 권한 분석은 클러스터에 연결하거나 SubjectAccessReview를 실행하지 않습니다. 매니페스트에서 일치하지 않아도 운영 요청이 거부된다는 뜻은 아닙니다.
- 빠진 관계를 가정하지 않음
- 참조한 Role이 없거나 집계 ClusterRole의 대상이 모두 제공되지 않으면 불완전으로 표시합니다. User와 Group 사이의 멤버십도 추론하지 않습니다.
- 리소스 규칙만 질의
- nonResourceURLs는 평가되지 않은 항목으로 남습니다. 사용자 정의 리소스의 실제 범위 발견, 정책 생성·적용, pods를 pods/exec로 확대하는 처리는 하지 않습니다.
쿠버네티스 RBAC 권한 분석 자주 묻는 질문
RoleBinding으로 한 네임스페이스는 되는데 전체 네임스페이스는 왜 안 되나요?
RoleBinding은 ClusterRole을 참조해도 자신이 속한 네임스페이스에만 허가합니다. 클러스터 전체에는 ClusterRoleBinding이 필요합니다.
한 ServiceAccount에 RoleBinding을 여러 개 연결할 수 있나요?
네. RBAC 허가는 합쳐집니다. 도구는 한 역할만 고르지 않고 모든 바인딩의 출처를 따로 보여 줍니다.
Secrets의 list 권한만 있어도 내용이 보이나요?
list 응답에는 Secret 객체와 데이터가 포함될 수 있습니다. 개별 Secret의 get이 없어도 주의해야 합니다. resourceNames가 있으면 list/watch에 필드 셀렉터가 필요합니다.
다른 네임스페이스의 ServiceAccount가 Secret을 읽을 수 있나요?
대상 네임스페이스의 RoleBinding에서 다른 네임스페이스의 ServiceAccount를 지정할 수 있습니다. 주체의 namespace를 명시하세요.
쿠버네티스 RBAC에서 명시적으로 거부할 수 있나요?
아니요. RBAC는 허가를 더하는 방식입니다. 이 페이지는 입력에 있는 연결만 찾으며 실제 클러스터의 최종 인가 결과는 판정하지 않습니다.
다른 권한 질문이 있나요?