이름은 같은데 권한이 다르다

목표

서비스어카운트 reader 하나에 Role·RoleBinding·ClusterRole·ClusterRoleBinding 을 차례로 붙이며,
권한이 어디까지(네임스페이스/클러스터) 그리고 무엇까지(동사·리소스) 미치는지를
kubectl auth can-i --as 로 직접 확인합니다. 토큰 자동 마운트를 끄는 법도 함께 봅니다.

왜 중요한가

쿠버네티스 API 서버에 들어오는 모든 요청은 "누가(주체) 무엇을(동사) 어디에(리소스·네임스페이스)" 로
판정됩니다. RBAC 은 허용 목록만 있고 거부 규칙이 없어서, 권한은 바인딩이 늘수록 합집합으로만 커집니다.
이름이 같은 reader 라도 어떤 바인딩이 어느 범위에 붙었느냐에 따라 할 수 있는 일이 완전히 달라집니다.

Role 은 한 네임스페이스 안에서만 유효하고, 노드처럼 네임스페이스가 없는 리소스는 ClusterRole 과
ClusterRoleBinding 으로만 권한을 줄 수 있습니다. 또 파드는 기본으로 서비스어카운트 토큰을 받으므로,
API 를 쓰지 않는 파드에서 이를 끄는 것이 최소 권한의 첫걸음입니다.

단계

1. 네임스페이스 kcna-rbac 와 서비스어카운트 reader 를 만듭니다.
2. Role pod-viewer(pods get/list/watch)와 RoleBinding reader-pods 를 만듭니다.
3. 같은 권한이 default 네임스페이스에서는 통하지 않음을 확인해 scope.txt 에 적습니다.
4. 별도의 Role cm-viewer(configmaps get/list)와 RoleBinding reader-cms 를 만듭니다.
5. ClusterRole node-viewer 와 ClusterRoleBinding reader-nodes 로 노드 조회를 허용합니다.
6. 파드 app 을 reader 로 돌리되 토큰 자동 마운트를 끕니다.
7. reader 가 파드를 만들거나 와일드카드 권한을 쓰지 못함을 확인해 write-check.txt 에 적습니다.
8. 네 가지 can-i 결과를 /root/kcna-rbac/report.txt 에 장부로 남깁니다.

참고

• 서비스어카운트로 가장할 때 주체 이름은 system:serviceaccount:<네임스페이스>:<이름> 형식입니다.
• kubectl auth can-i --list -n kcna-rbac --as=... 로 그 주체가 가진 권한 전체를 볼 수 있습니다.
• 공식 문서: [RBAC 인가 사용하기](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) ·

[RBAC 모범 사례](https://kubernetes.io/docs/concepts/security/rbac-good-practices/).

단계 8개

1. 권한 없는 신입 계정이 도착하다
2. 파드를 보게만 해 주고 지우지는 못하게
3. 옆 네임스페이스에서는 아무것도 안 보인다
4. 권한은 덧붙이는 게 아니라 따로 묶는다
5. 노드는 네임스페이스 밖에 산다
6. API 를 쓸 일 없는 파드에 열쇠를 쥐여 주지 않는다
7. 읽기 전용 계정이 파드를 만들려 한다면
8. reader 의 권한 지도를 장부로 남기기