LabHub

CKA — 쿠버네티스 관리자 · 인증·인가와 RBAC · 실습

RBAC 로 권한 자르기

LabHub 에서 이어서 보기

목표

ServiceAccount 에 최소 권한을 주고, 그 권한이 네임스페이스 경계를 넘지 않는 것을 확인하고, 클러스터 스코프 권한과 Aggregated ClusterRole 까지 구성합니다.

왜 중요한가

RBAC 문제는 시험에서 배점이 확실합니다. 그런데 정답을 만드는 것보다 정답이 맞는지 확인하는 것이 더 중요합니다. kubectl auth can-i --as= 는 SubjectAccessReview 를 만들어 apiserver 에 물어볼 뿐 실제 요청을 보내지 않으므로, 부작용 없이 몇 번이고 확인할 수 있습니다.

이 실습은 특히 no 를 확인하는 단계를 넣었습니다. RBAC 는 누적만 되고 거부 규칙이 없어서, 실수로 ClusterRoleBinding 을 쓰면 의도한 것보다 훨씬 넓게 열립니다. 열렸는지는 쉽게 확인하지만 안 열렸는지는 잘 확인하지 않습니다. 최소 권한 원칙은 "안 되는 것을 확인하는 습관" 없이는 지켜지지 않습니다.

단계

1. 네임스페이스 cka-rbaccka-rbac-other 를 만든다. cka-rbac 에 ServiceAccount deploy-bot 을 만들고, cka-rbac-other 에는 경계 확인용 ConfigMap boundary-probe 를 하나 만든다.
2. cka-rbac 에 Role pod-reader 를 만든다. apiGroups 는 core (빈 문자열), resources 는 podspods/log, verbs 는 get, list, watch 만.
3. cka-rbac 에 RoleBinding pod-reader-bind 를 만들어 Role pod-reader 를 ServiceAccount cka-rbac/deploy-bot 에 연결한다.
4. deploy-bot 으로 가장한 권한 확인 결과를 /root/cka-rbac/can-i.txt 에 저장한다. cka-rbac 에서 파드 get 이 yes 여야 하고 delete 는 no 여야 한다.
5. 같은 계정으로 cka-rbac-other 에서 파드를 읽을 수 있는지 확인해 /root/cka-rbac/boundary.txt 에 저장한다. 결과는 no 여야 한다.
6. ClusterRole node-viewer (apiGroups core, resources nodes, verbs get/list/watch)와 ClusterRoleBinding node-viewer-bind 를 만들어 cka-rbac/deploy-bot 에 연결한다. 노드 list 가 yes 가 되어야 한다.
7. ClusterRole cka-monitoring-endpoints 를 만든다. 라벨 rbac.labhub.io/aggregate-to-monitoring=true, 규칙은 core 그룹의 servicesendpoints 에 대해 get, list. 그리고 ClusterRole cka-monitoring 을 만들어 aggregationRule 이 그 라벨을 셀렉터로 고르게 한다.
8. cka-rbac 에 ServiceAccount no-token 을 만들되 automountServiceAccountToken: false 로 둔다. 파드 locked-down (이미지 nginx:1.27)을 만들어 serviceAccountName 을 no-token 으로 하고 파드 스펙에서도 automountServiceAccountToken: false 를 명시한다. 이 계정에는 아무 권한도 바인딩하지 않는다.

참고

단계 8개

  1. 서비스어카운트와 실험용 네임스페이스
  2. 읽기 전용 Role 만들기
  3. RoleBinding 으로 연결하기
  4. 권한이 붙었는지 확인하기
  5. 네임스페이스 경계 넘기 실패 확인
  6. 클러스터 스코프 리소스 열어 주기
  7. Aggregated ClusterRole 구성하기
  8. 종합: 토큰이 없는 파드 만들기