개요

쿠버 RBAC#권한 상승 방지(privilege escalation prevention)에 나오는 내용을 실습해보고자 한다.

세팅

Vagrant로 Kubernetes v1.32 - Penelope를 구축해 사용한다.

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: sam
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]
- apiGroups: ["rbac.authorization.k8s.io"]
  resources: ["roles"]
  verbs: ["get", "create", "delete", "update", "list"]
- apiGroups: ["rbac.authorization.k8s.io"]
  resources: ["rolebindings"]
  verbs: ["get", "create", "delete", "update", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: sam
subjects:
- kind: User
  name: sam
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: sam
  apiGroup: rbac.authorization.k8s.io

sam이라는 유저에 대해 Authentication#유저 흉내(impersonation)를 사용하여 실습을 진행할 것이다.
위의 설정에 의해 sam은 파드를 조회만 할 수 있다.
추가적으로 sam은 롤과 롤 바인딩을 만들거나 조회하거나, 삭제할 수 있는 상태이다.

이렇게 만들어도 system:authenticated 그룹은 자신에 대한 인증과 인가를 확인하는 SelfSubjectReview, SubjectAccessReview 리소스를 사용할 수 있다.
그래서 자신이 누군지 알 수 있다.

이렇게 권한 체크도 가능하다!
보다시피 보기만 가능하고 만들지는 못 하는 불쌍한 sam...

k access-matrix --as sam -n default

이건 krew 플러그인을 이용해서 설치한 플러그인이다.

보다시피 sam은 별로 할 수 있는 게 없는 친구다.

이때, sam은 다른 사람들이 파드를 만드는 것을 보고 승이 나서 자신도 마음대로 파드를 만들거나 지우고 싶어졌다!!!
과연 우리 친구 sam이 파드를 만드려면 어떻게 해야 할까?

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: sam-escalate
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["create", "delete"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: sam-escalate
subjects:
- kind: User
  name: sam
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: sam-escalate
  apiGroup: rbac.authorization.k8s.io

단순하게는, sam이 이렇게 직접 롤과 롤바를 만들면 될 것이다.

불가능한 방법

kaf sams-escalate.yaml --as sam

불쌍한 sam은 자신의 권한을 벗어난 롤을 만들 수 없다.

(관리자 권한으로 이번엔 먼저 sams-escalate 롤을 만든 상태)
그럼 이미 롤이 있다면 그것에 바인딩을 할 수 있냐, 그것도 아니다.
결국 함부로 권한이 상승되는 것이 원천적으로 막혀있는 것이다!

명시적으로 권한 주기

(미리 만든 롤과 롤바를 적절하게 삭제하는 작업을 해주자.)
이제 sam을 그만 괴롭히고 파드를 만들 수 있게 해주자.

- apiGroups: ["rbac.authorization.k8s.io"]
  resources: ["roles"]
  verbs: ["get", "create", "delete", "update", "list", "bind"]

먼저 이미 만들어진 롤에 대해 바인딩을 할 수 있도록 bind 동사를 준다.
이 동사는 롤에 주는 거지 바인딩에 주는 게 아니란 걸 유의하자.

이번에는 정상적으로 롤바인딩이 이뤄진다.
(롤은 이미 만들어진 상태)

비로소 sam은 파드를 만들 수 있게 됐다.

- apiGroups: ["rbac.authorization.k8s.io"]
  resources: ["roles"]
  verbs: ["get", "create", "delete", "update", "list", "bind", "escalate"]

이번에는 sam이 아예 롤을 만들 수도 있게 권한을 줘보도록 한다.

이번에는 롤까지도 sam이 직접 만들 수 있게 된다.

와일드카드를 사용한다면?

- apiGroups: ["rbac.authorization.k8s.io"]
  resources: ["roles"]
  verbs: ["*"]
- apiGroups: ["rbac.authorization.k8s.io"]
  resources: ["rolebindings"]
  verbs: ["*"]

귀찮은 관리자가 대충 와일드 카드로 모든 권한을 주게되면, sam은 마음대로 권한 상승을 할 수 있을까?

오우.. 가능하다.
권한 상승을 함부로 가능하게 하고 싶지 않았던 관리자는 대충 설정했다가 큰 낭패를 보게 될 수도 있다.

결론

기본적으로 롤과 롤바에 대한 권한을 받을 유저라면 대체로 충분한 권한을 이미 가지고 있을 것이다.
다만 멀티 테넌시 환경에서 네임스페이스 별로 클러스터를 서비스로 제공하거나, 운영 조직의 세분화로 인해 네임스페이스별 관리자를 설정하는 등 적절한 권한 세팅이 필요한 경우가 있을 수 있다.
이 경우 함부로 와일드카드를 쓰는 것은 매우 위험한 일이 될 수 있다.

이를 해소할 수 있는 좋은 방법은 이미 쿠버네티스에서 제공을 하고 있다.
쿠버 RBAC#사용자 중심 롤(user-facing role)에서는 이미 네임스페이스별 관리자를 위한 적절한 권한 부여가 돼있다.
그러므로 네임스페이스 별 운영 권한을 분배해야 하는 경우, 직접 잘 커스텀하여 권한을 설정해주거나, 아니면 최소한 사용자 중심 롤을 이용하자.

관련 문서

참고