롤을 만들 수 있으면 관리자가 될 수 있을까

목표

낮은 권한 서비스어카운트로 RBAC 권한 상승을 시도해, apiserver 의 권한 상승 방지(escalate/bind)가
실제로 그 시도를 막는 것을 관찰합니다. 그리고 정당한 관리자만이 권한을 넘길 수 있으며, 임퍼소네이션
역시 별도로 보호되는 권한임을 확인해 리포트로 남깁니다.

왜 중요한가

RBAC 에서 가장 위험한 실수는 "롤을 만들 수 있는 권한" 을 준 것이 사실상 "무엇이든 될 수 있는 권한" 을
준 것과 같아지는 경우입니다. 만약 롤 생성 권한만 있으면 자기에게 시크릿 권한을 담은 롤을 만들어 붙일 수
있다면, 그 서비스어카운트는 곧 클러스터 관리자입니다.

쿠버네티스는 이를 apiserver 수준에서 막습니다 — **자기가 현재 갖지 않은 권한을 담은 롤을 만들거나
바인딩할 수 없습니다**(권한 상승 방지). 그래서 롤 생성 권한을 줘도 그것이 곧바로 특권 확대로 이어지지
않습니다. 이 경계가 코드가 아니라 apiserver 의 승인 단계에 있다는 것을, 그리고 impersonate 같은
동사가 왜 따로 위험 동사로 취급되는지를 직접 눈으로 보는 것이 이 실습의 핵심입니다.

단계

1. 네임스페이스 kcsa-priv 와 서비스어카운트 lowpriv 를 만듭니다.
2. lowpriv 에게 롤·롤바인딩 생성 권한만 주는 Role rolemaker 를 바인딩합니다.
3. 관리자로 표적 ClusterRole secret-admin(시크릿 get/list)을 만듭니다.
4. lowpriv 인 척 시크릿 권한 롤을 만들려다 거절되는 것을 확인해 저장합니다.
5. lowpriv 인 척 secret-admin 을 자신에게 바인딩하려다 거절되는 것을 확인해 저장합니다.
6. 관리자가 정식으로 secret-admin 을 lowpriv 에 바인딩해, 이제 시크릿을 읽을 수 있게 합니다.
7. 임퍼소네이션 권한 없는 서비스어카운트 auditor2 가 남인 척 못한다는 것을 확인합니다.
8. 무엇이 막히고 무엇이 통했는지 report.txt 에 기록합니다.

참고

• kubectl auth can-i <동사> <리소스> --as=<주체> 로 관리자 권한에서 다른 주체의 권한을 확인합니다.
• 자기-상승 시도는 실패가 정상이므로 명령 뒤에 2>&1 로 표준 에러까지 파일로 받으세요.
• 거절 메시지의 'is attempting to grant RBAC permissions not currently held' 가 권한 상승 방지의 증거입니다.
• 공식 문서: [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. 관리자가 정식으로 권한을 넘기다
7. 남인 척하는 권한도 따로 지켜진다
8. 무엇이 막히고 무엇이 통했는지 장부로