Kubernetes Dashboard의 인증과 RBAC 권한 확인

Kubernetes Dashboard의 기본 권한 문서를 찾아보며 남긴 메모입니다. 화면에 접속하는 것과 Kubernetes 리소스를 조회·변경하는 것은 별도 권한이 필요해 구분해서 봐야 했습니다.

현재 공식 문서는 Kubernetes Dashboard가 보관 처리돼 유지보수되지 않는다고 안내합니다. 이 글은 당시 권한 구조를 정리한 내용이며, 새 설치 방법을 안내하는 글은 아닙니다.

인증과 인가 구분

토큰 등으로 요청자의 신원을 확인하는 과정이 인증입니다. 그 신원으로 어떤 API 작업을 할 수 있는지 판단하는 것이 인가입니다.

로그인에 성공했더라도 Pod 목록이나 로그를 볼 권한이 없을 수 있습니다. 반대로 목록이 보인다는 이유만으로 삭제나 설정 변경까지 허용된 것은 아닙니다. 오류를 볼 때는 대상 네임스페이스와 리소스, 요청한 동작을 함께 확인해야 합니다.

RBAC 리소스의 역할

Dashboard에서 조회가 안 된다고 곧바로 cluster-admin을 연결할 필요는 없습니다. 필요한 작업과 범위에 맞는 권한부터 확인할 수 있습니다.

네임스페이스 조회 권한 예시

다음은 이미 존재하는 example 네임스페이스에서 Pod·Service·Deployment와 Pod 로그를 읽는 설정 예시입니다. 실제로 사용했던 설정의 복사본이 아니라 권한 범위를 설명하기 위한 매니페스트입니다.

apiVersion: v1
kind: ServiceAccount
metadata:
  name: dashboard-reader
  namespace: example
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: dashboard-reader
  namespace: example
rules:
  - apiGroups: [""]
    resources: ["pods", "services"]
    verbs: ["get", "list", "watch"]
  - apiGroups: [""]
    resources: ["pods/log"]
    verbs: ["get"]
  - apiGroups: ["apps"]
    resources: ["deployments"]
    verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: dashboard-reader
  namespace: example
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: dashboard-reader
subjects:
  - kind: ServiceAccount
    name: dashboard-reader
    namespace: example

Secret 읽기나 Pod 삭제, 클러스터 전체의 목록 조회는 포함하지 않았습니다. Dashboard의 모든 화면이 이 권한만으로 동작한다는 뜻도 아닙니다. 필요한 API가 무엇인지 확인하며 범위를 정해야 합니다.

권한 확인과 토큰 발급

현재 kubectl auth can-i로 특정 작업의 허용 여부를 확인할 수 있습니다. 다른 신원을 지정하는 다음 조회에는 명령 실행자에게 impersonation 권한이 필요합니다.

kubectl auth can-i list pods -n example --as=system:serviceaccount:example:dashboard-reader
kubectl auth can-i delete pods -n example --as=system:serviceaccount:example:dashboard-reader

지원하는 현재 버전에서는 ServiceAccount용 토큰을 다음처럼 요청할 수 있습니다.

kubectl create token dashboard-reader -n example --duration=10m

유효기간은 서버 정책에 따라 조정될 수 있습니다. 토큰 발급은 권한을 새로 부여하는 작업이 아니며, 앞서 연결한 RBAC 범위가 적용됩니다. 발급한 값은 로그인 자격 증명이므로 로그나 공유 문서에 남기지 않습니다.

당시 버전에서 사용하던 자동 생성 Secret 토큰과 현재 TokenRequest 방식은 다릅니다. ServiceAccount를 만들면 토큰 Secret이 항상 생긴다고 가정하지 않아야 합니다.

참고 자료

• Dashboard의 현재 유지보수 상태 
• Kubernetes RBAC 
• kubectl create token