역할 기반 접근 제어 (RBAC) 모범 사례
쿠버네티스 RBAC는 클러스터 사용자 및 워크로드가 자신의 역할을 수행하기 위해 필요한 자원에 대해서만 접근 권한을 가지도록 보장하는 핵심 보안 제어 방식이다. 클러스터 관리자가 클러스터 사용자 권한을 설정할 시에는, 보안 사고로 이어지는 과도한 접근 권한 부여의 위험을 줄이기 위해 권한 에스컬레이션 발생 가능성에 대해 이해하는 것이 중요하다.
여기서 제공하는 모범 사례는 RBAC 문서 와 함께 읽는 것을 권장한다.
보편적인 모범 사례
최소 권한
이상적으로는, 최소의 RBAC 권한만이 사용자 및 서비스 어카운트에 부여되어야 한다. 작업에 명시적으로 필요한 권한만 사용되어야 한다. 각 클러스터마다 경우가 다르겠지만, 여기서 적용해 볼 수 있는 보편적 규칙은 다음과 같다.
- 권한은 가능하면 네임스페이스 레벨에서 부여한다. 클러스터롤바인딩 대신 롤바인딩을 사용하여 특정 네임스페이스 내에서만 사용자에게 권한을 부여한다.
- 와일드카드(wildcard)를 사용한 권한 지정을 할 시에는, 특히 모든 리소스에 대해서는 가능하면 지양한다. 쿠버네티스는 확장성을 지니는 시스템이기 때문에, 와일드카드를 이용한 권한 지정은 현재 클러스터에 있는 모든 오브젝트 타입뿐만 아니라 모든 오브젝트 타입에 대해서도 권한을 부여하게 된다.
- 운영자는
cluster-admin계정이 필수로 요구되지 않을시에는 사용을 지양한다. 적은 권한을 가진 계정과 가장 (impersonation) 권한을 혼합하여 사용하면 클러스터 자원을 실수로 수정하는 일을 방지할 수 있다. system:masters그룹에 사용자 추가를 지양한다. 해당 그룹의 멤버는 누구나 모든 RBAC 권한 체크를 우회할 수 있으며 롤바인딩과 클러스터 롤바인딩을 통한 권한 회수가 불가능한 슈퍼유저 (superuser) 권한을 가지게 된다. 추가적으로 클러스터가 권한 웹훅을 사용할 시에는, 그룹의 멤버가 해당 웹훅도 우회할 수 있다. (그룹의 멤버인 사용자가 전송하는 요청은 웹훅에 전달되지 않는다.)
특권 토큰 분배 최소화
이상적인 상황에서는, 강력한 권한이 부여된 서비스 어카운트를 파드에게 지정해서는 안된다. (예를 들어, 권한 에스컬레이션 위험에 명시된 모든 권한) 워크로드가 강력한 권한을 요구하는 상황에서는 다음과 같은 사례를 고려해 보자.
- 강력한 권한을 가진 파드를 실행하는 노드의 수를 제한한다. 컨테이너 이스케이프의 영향 범위를 최소화하기 위해, 실행되고 있는 모든 데몬셋은 최소의 권한만을 가지도록 한다.
- 강력한 권한을 가진 파드를 신뢰되지 못하거나 외부로 노출된 파드와 함께 실행하는 것을 지양한다. 신뢰되지 못하거나 신뢰성이 적은 파드와 함께 실행되는 것을 방지하기 위해 테인트와 톨러레이션, 노드 어피니티, 혹은 파드 안티-어피니티를 사용해 보는 것도 고려해 보자. 신뢰성이 적은 파드가 제한된 파드 시큐리티 스탠다드에 부합하지 않을 시에는 더욱 조심해야 한다.
하드닝 (Hardening)
모든 클러스터에서 요구되지 않더라도, 쿠버네티스에서는 기본으로 제공하는 권한이 있다.
기본으로 부여되는 RBAC 권리에 대한 검토를 통해 보안 하드닝을 할 수 있다.
보편적으로는 system: 계정에 부여되는 권한을 수정하는 것은 지양한다.
클러스터 권한을 하드닝할 수 있는 방법은 다음과 같다.
system:unauthenticated그룹의 바인딩은 누구에게나 네트워크 레벨에서 API 서버와 통신할 수 있는 권한을 부여하므로, 바인딩을 검토해 보고 가능하면 제거한다.automountServiceAccountToken: false를 설정함으로써, 서비스 어카운트 토큰의 자동 마운트 사용을 지양한다. 더 자세한 내용은 기본 서비스 어카운트 토큰 사용법을 참고한다. 파드에서 위와 같은 설정을 하게 된다면, 서비스 어카운트 설정을 덮어쓰게 되며 서비스 어카운트 토큰을 요구하는 워크로드는 여전히 마운트가 가능하다.
주기적 검토
중복된 항목 및 권한 에스컬레이션에 대비하여, 쿠버네티스 RBAC 설정을 주기적으로 검토하는 일은 중요하다. 만일 공격자가 삭제된 사용자와 같은 이름으로 사용자 계정을 생성할 수 있다면, 삭제된 사용자의 모든 권한, 특히 해당 사용자에게 부여되었던 권한까지도 자동으로 상속받을 수 있게 된다.
쿠버네티스 RBAC - 권한 에스컬레이션 위험
쿠버네티스 RBAC 중, 부여받을 시 사용자 또는 서비스 어카운트가 권한 에스컬레이션을 통해 클러스터 밖의 시스템까지 영향을 미칠 수 있게끔 하는 권한이 몇 가지 존재한다.
해당 섹션은 클러스터 운영자가 실수로 클러스터에 의도되지 않은 접근 권한을 부여하지 않도록 하기 위해 신경 써야 할 부분에 대한 시야를 제공하는 것이 목적이다.
시크릿 나열
시크릿에 대해 get 권한을 부여하는 행위는 사용자에게 해당 내용에 대한 열람을 허용하는 일이라는 것은 명확히 알려져 있다.
list 및 watch 권한 또한 사용자가 시크릿의 내용을 열람할 수 있는 권한을 부여한다는 것을 알고 지나가는 것이 중요하다.
예를 들어 리스트 응답이 반환되면 (예를 들어, kubectl get secrets -A -o yaml을 통해),
해당 응답에는 모든 시크릿의 내용이 포함되어 있다.
워크로드 생성
네임스페이스에 워크로드(파드 혹은 파드를 관리하는 워크로드 리소스)를 생성할 수 있는 권한은 파드에 마운트할 수 있는 시크릿, 컨피그맵 그리고 퍼시스턴트볼륨(PersistentVolume)과 같은 해당 네임스페이스의 다른 많은 리소스에 대한 액세스 권한을 암묵적으로 부여한다. 또한 파드는 모든 서비스어카운트로 실행할 수 있기 때문에, 워크로드 생성 권한을 부여하면 해당 네임스페이스에 있는 모든 서비스어카운트의 API 액세스 수준도 암묵적으로 부여된다.
특권 파드 실행 권한을 가지는 사용자는 해당 노드에 대한 권한을 부여받을 수 있으며, 더 나아가 권한을 상승시킬 수 있는 가능성도 존재한다. 특정 사용자 혹은, 적절히 안정 및 격리 된 파드를 생성할 수 있는 자격을 가진 다른 주체를 완전히 신뢰하지 못하는 상황이라면, 베이스라인 혹은 제한된 파드 시큐리티 스탠다드를 사용해야 한다. 이는 파드 시큐리티 어드미션 또는 다른 (서드 파티) 매커니즘을 통해 시행할 수 있다.
이러한 이유로, 네임스페이스는 서로 다른 수준의 보안 또는 테넌시가 필요한 리소스들을 분리하는 데 사용해야 한다. 최소 권한 원칙을 따르고 권한을 가장 적게 할당하는 것이 바람직하지만, 네임스페이스 내의 경계는 약한 것으로 간주되어야 한다.
퍼시스턴트 볼륨 생성
파드시큐리티폴리시 문서에서도 언급이 되었듯이, 퍼시스턴트볼륨 생성 권한은 해당 호스트에 대한 권한 에스컬레이션으로 이어질 수 있다. 퍼시스턴트 스토리지에 대한 권한이 필요할 시에는 신뢰 가능한 관리자를 통해 퍼시스턴트볼륨을 생성하고, 제한된 권한을 가진 사용자는 퍼시스턴트볼륨클레임을 통해 해당 스토리지에 접근하는 것이 바람직하다.
노드의 proxy 하위 리소스에 대한 접근
노드 오브젝트의 하위 리소스인 프록시에 대한 접근 권한을 가지는 사용자는 Kubelet API에 대한 권한도 가지며, 이는 권한을 가지고 있는 노드에 위치한 모든 파드에서 명령어 실행 권한이 주어짐을 의미한다. 이러한 접근 권한을 통해 감시 로깅 및 어드미션 컨트롤에 대한 우회가 가능해짐으로, 해당 리소스에 대한 권한을 부여할 시에는 주의가 필요하다.
에스컬레이트 동사
사용자가 자신이 보유한 권한보다 더 많은 권한을 가진 클러스터롤을 생성하고자 할때, RBAC 시스템이 이를 막는 것이 보편적이다.
이와 관련하여, escalate 동사가 예외에 해당한다. RBAC 문서에서도 언급이 되었듯이,
해당 권한을 가진 사용자는 권한 에스컬레이션을 할 수 있다.
바인드 동사
해당 권한을 사용자에게 부여함으로써 escalate 동사와 유사하게
권한 에스컬레이션에 대한 쿠버네티스에 내장된 보호 기능을 우회할 수 있게 되며,
이는 사용자가 부여받지 않은 권한을 가진 롤에 대한 바인딩을 생성할 수 있게끔 한다.
가장 (Impersonate) 동사
사용자는 해당 동사를 통해 클러스터 내에서 다른 사용자를 가장하여 권한을 부여받을 수 있게 된다. 가장된 계정을 통해 필요 이상의 권한이 부여되지 않도록 해당 동사 부여시 주의를 기울일 필요가 있다.
CSR 및 증명서 발급
CSR API를 통해 CSR에 대한 create 권한 및 certificatesigningrequests/approval에 대한 update 권한을 가진 사용자가,
서명자가 kubernetes.io/kube-apiserver-client인 새로운 클라이언트 증명서를 생성할 수 있게 되며 이를 통해 사용자는 클러스터를 인증할 수 있게 된다.
해당 클라이언트 증명서는 임의의 이름을 가지게 되며, 이에 중복된 쿠버네티스 시스템 구성 요소도 포함 된다.
이는 권한 에스컬레이션 발생 가능성을 열어두게 된다.
토큰 요청
serviceaccounts/token에 대해 create 권한을 가지는 사용자는
기존의 서비스 어카운트에 토큰을 발급할 수 있는 토큰리퀘스트를 생성할 수 있다.
컨트롤 어드미션 웹훅
validatingwebhookconfigurations 혹은 mutatingwebhookconfigurations에 대한 제어권을 가지는 사용자는
클러스터가 승인한 모든 오브젝트를 열람할 수 있는 웹훅을 제어할 수 있으며,
변화하는 웹훅의 경우에는 승인된 오브젝트를 변화시킬 수도 있다.
쿠버네티스 RBAC - 서비스 거부 위험
객체 생성 서비스 거부
클러스터 내 오브젝트 생성 권한을 가지는 사용자는 쿠버네티스가 사용하는 etcd는 OOM 공격에 취약에서 언급 되었듯이, 서비스 거부 현상을 초래할 정도 규모의 오브젝트를 생성할 수 있다. 다중 테넌트 클러스터에서 신뢰되지 못하거나 신뢰성이 적은 사용자에게 시스템에 대해 제한된 권한이 부여된다면 해당 현상이 나타날 수 있다.
해당 문제의 완화 방안 중 하나로는, 리소스 쿼터를 사용하여 생성할 수 있는 오브젝트의 수량을 제한하는 방법이 있다.
다음 내용
- RBAC에 대한 추가적인 정보를 얻기 위해서는 RBAC 문서를 참고한다.