189 lines
13 KiB
Markdown
189 lines
13 KiB
Markdown
---
|
|
reviewers:
|
|
title: 역할 기반 접근 제어 (RBAC) 모범 사례
|
|
description: >
|
|
클러스터 운영자를 위한 모범 RBAC 설정 규칙 및 사례
|
|
content_type: concept
|
|
weight: 60
|
|
---
|
|
|
|
<!-- overview -->
|
|
|
|
쿠버네티스 {{< glossary_tooltip text="RBAC" term_id="rbac" >}}는
|
|
클러스터 사용자 및 워크로드가 자신의 역할을 수행하기 위해 필요한 자원에 대해서만
|
|
접근 권한을 가지도록 보장하는 핵심 보안 제어 방식이다. 클러스터 관리자가 클러스터 사용자 권한을 설정할 시에는,
|
|
보안 사고로 이어지는 과도한 접근 권한 부여의 위험을 줄이기 위해
|
|
권한 에스컬레이션 발생 가능성에 대해 이해하는 것이 중요하다.
|
|
|
|
여기서 제공하는 모범 사례는 [RBAC 문서](/docs/reference/access-authn-authz/rbac/#restrictions-on-role-creation-or-update)
|
|
와 함께 읽는 것을 권장한다.
|
|
|
|
<!-- body -->
|
|
|
|
## 보편적인 모범 사례
|
|
|
|
### 최소 권한
|
|
|
|
이상적으로는, 최소의 RBAC 권한만이 사용자 및 서비스 어카운트에 부여되어야 한다.
|
|
작업에 명시적으로 필요한 권한만 사용되어야 한다.
|
|
각 클러스터마다 경우가 다르겠지만, 여기서 적용해 볼 수 있는 보편적 규칙은 다음과 같다.
|
|
|
|
- 권한은 가능하면 네임스페이스 레벨에서 부여한다.
|
|
클러스터롤바인딩 대신 롤바인딩을 사용하여 특정 네임스페이스 내에서만 사용자에게 권한을 부여한다.
|
|
- 와일드카드(wildcard)를 사용한 권한 지정을 할 시에는, 특히 모든 리소스에 대해서는 가능하면 지양한다.
|
|
쿠버네티스는 확장성을 지니는 시스템이기 때문에,
|
|
와일드카드를 이용한 권한 지정은 현재 클러스터에 있는 모든 오브젝트 타입뿐만 아니라
|
|
모든 오브젝트 타입에 대해서도 권한을 부여하게 된다.
|
|
- 운영자는 `cluster-admin` 계정이 필수로 요구되지 않을시에는 사용을 지양한다.
|
|
적은 권한을 가진 계정과
|
|
[가장 (impersonation) 권한](/docs/reference/access-authn-authz/authentication/#user-impersonation)을
|
|
혼합하여 사용하면 클러스터 자원을 실수로 수정하는 일을 방지할 수 있다.
|
|
- `system:masters` 그룹에 사용자 추가를 지양한다.
|
|
해당 그룹의 멤버는 누구나 모든 RBAC 권한 체크를 우회할 수 있으며 롤바인딩과 클러스터 롤바인딩을
|
|
통한 권한 회수가 불가능한 슈퍼유저 (superuser) 권한을 가지게 된다.
|
|
추가적으로 클러스터가 권한 웹훅을 사용할 시에는,
|
|
그룹의 멤버가 해당 웹훅도 우회할 수 있다. (그룹의 멤버인 사용자가 전송하는 요청은 웹훅에 전달되지 않는다.)
|
|
|
|
### 특권 토큰 분배 최소화
|
|
|
|
이상적인 상황에서는, 강력한 권한이 부여된 서비스 어카운트를 파드에게 지정해서는 안된다.
|
|
(예를 들어, [권한 에스컬레이션 위험](#privilege-escalation-risks)에 명시된 모든 권한)
|
|
워크로드가 강력한 권한을 요구하는 상황에서는 다음과 같은 사례를 고려해 보자.
|
|
|
|
- 강력한 권한을 가진 파드를 실행하는 노드의 수를 제한한다.
|
|
컨테이너 이스케이프의 영향 범위를 최소화하기 위해, 실행되고 있는 모든 데몬셋은 최소의 권한만을 가지도록 한다.
|
|
- 강력한 권한을 가진 파드를 신뢰되지 못하거나 외부로 노출된 파드와 함께 실행하는 것을 지양한다.
|
|
신뢰되지 못하거나 신뢰성이 적은 파드와 함께 실행되는 것을 방지하기 위해
|
|
[테인트와 톨러레이션](/ko/docs/concepts/scheduling-eviction/taint-and-toleration/),
|
|
[노드 어피니티](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#node-affinity), 혹은
|
|
[파드 안티-어피니티](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#inter-pod-affinity-and-anti-affinity)를 사용해 보는 것도 고려해 보자.
|
|
신뢰성이 적은 파드가 **제한된** 파드 시큐리티 스탠다드에 부합하지 않을 시에는 더욱 조심해야 한다.
|
|
|
|
### 하드닝 (Hardening)
|
|
|
|
모든 클러스터에서 요구되지 않더라도, 쿠버네티스에서는 기본으로 제공하는 권한이 있다.
|
|
기본으로 부여되는 RBAC 권리에 대한 검토를 통해 보안 하드닝을 할 수 있다.
|
|
보편적으로는 `system:` 계정에 부여되는 권한을 수정하는 것은 지양한다.
|
|
클러스터 권한을 하드닝할 수 있는 방법은 다음과 같다.
|
|
|
|
- `system:unauthenticated` 그룹의 바인딩은 누구에게나
|
|
네트워크 레벨에서 API 서버와 통신할 수 있는 권한을 부여하므로, 바인딩을 검토해 보고 가능하면 제거한다.
|
|
- `automountServiceAccountToken: false`를 설정함으로써, 서비스 어카운트 토큰의 자동 마운트 사용을 지양한다.
|
|
더 자세한 내용은
|
|
[기본 서비스 어카운트 토큰 사용법](/docs/tasks/configure-pod-container/configure-service-account/#use-the-default-service-account-to-access-the-api-server)을 참고한다.
|
|
파드에서 위와 같은 설정을 하게 된다면,
|
|
서비스 어카운트 설정을 덮어쓰게 되며 서비스 어카운트 토큰을 요구하는 워크로드는 여전히 마운트가 가능하다.
|
|
|
|
### 주기적 검토
|
|
|
|
중복된 항목 및 권한 에스컬레이션에 대비하여,
|
|
쿠버네티스 RBAC 설정을 주기적으로 검토하는 일은 중요하다.
|
|
만일 공격자가 삭제된 사용자와 같은 이름으로 사용자 계정을 생성할 수 있다면,
|
|
삭제된 사용자의 모든 권한, 특히 해당 사용자에게 부여되었던 권한까지도
|
|
자동으로 상속받을 수 있게 된다.
|
|
|
|
## 쿠버네티스 RBAC - 권한 에스컬레이션 위험 {#privilege-escalation-risks}
|
|
|
|
쿠버네티스 RBAC 중, 부여받을 시 사용자 또는 서비스 어카운트가 권한 에스컬레이션을 통해
|
|
클러스터 밖의 시스템까지 영향을 미칠 수 있게끔 하는 권한이 몇 가지 존재한다.
|
|
|
|
해당 섹션은 클러스터 운영자가 실수로 클러스터에 의도되지 않은 접근 권한을
|
|
부여하지 않도록 하기 위해 신경 써야 할 부분에 대한 시야를 제공하는 것이 목적이다.
|
|
|
|
### 시크릿 나열
|
|
|
|
시크릿에 대해 `get` 권한을 부여하는 행위는 사용자에게 해당 내용에 대한 열람을 허용하는 일이라는 것은 명확히 알려져 있다.
|
|
`list` 및 `watch` 권한 또한 사용자가 시크릿의 내용을 열람할 수 있는 권한을 부여한다는 것을 알고 지나가는 것이 중요하다.
|
|
예를 들어 리스트 응답이 반환되면 (예를 들어, `kubectl get secrets -A -o yaml`을 통해),
|
|
해당 응답에는 모든 시크릿의 내용이 포함되어 있다.
|
|
|
|
### 워크로드 생성
|
|
|
|
네임스페이스에 워크로드(파드 혹은 파드를 관리하는
|
|
[워크로드 리소스](/ko/docs/concepts/workloads/controllers/))를 생성할 수 있는 권한은
|
|
파드에 마운트할 수 있는 시크릿, 컨피그맵 그리고 퍼시스턴트볼륨(PersistentVolume)과 같은 해당 네임스페이스의 다른 많은 리소스에 대한
|
|
액세스 권한을 암묵적으로 부여한다. 또한 파드는 모든 [서비스어카운트](/ko/docs/reference/access-authn-authz/service-accounts-admin/)로
|
|
실행할 수 있기 때문에, 워크로드 생성 권한을 부여하면
|
|
해당 네임스페이스에 있는 모든 서비스어카운트의 API 액세스 수준도 암묵적으로
|
|
부여된다.
|
|
|
|
특권 파드 실행 권한을 가지는 사용자는 해당 노드에 대한 권한을 부여받을 수 있으며,
|
|
더 나아가 권한을 상승시킬 수 있는 가능성도 존재한다.
|
|
특정 사용자 혹은, 적절히 안정 및 격리 된 파드를 생성할 수 있는 자격을 가진 다른 주체를 완전히 신뢰하지 못하는 상황이라면,
|
|
**베이스라인** 혹은 **제한된** 파드 시큐리티 스탠다드를 사용해야 한다.
|
|
이는 [파드 시큐리티 어드미션](/ko/docs/concepts/security/pod-security-admission/)
|
|
또는 다른 (서드 파티) 매커니즘을 통해 시행할 수 있다.
|
|
|
|
이러한 이유로, 네임스페이스는 서로 다른 수준의 보안 또는 테넌시가 필요한 리소스들을 분리하는 데 사용해야
|
|
한다. [최소 권한](#least-privilege) 원칙을 따르고 권한을 가장 적게 할당하는 것이
|
|
바람직하지만, 네임스페이스 내의 경계는 약한 것으로 간주되어야
|
|
한다.
|
|
|
|
### 퍼시스턴트 볼륨 생성
|
|
|
|
[파드시큐리티폴리시](/ko/docs/concepts/security/pod-security-policy/#volumes-and-file-systems) 문서에서도 언급이 되었듯이,
|
|
퍼시스턴트볼륨 생성 권한은 해당 호스트에 대한 권한 에스컬레이션으로 이어질 수 있다.
|
|
퍼시스턴트 스토리지에 대한 권한이 필요할 시에는 신뢰 가능한 관리자를 통해 퍼시스턴트볼륨을 생성하고,
|
|
제한된 권한을 가진 사용자는 퍼시스턴트볼륨클레임을 통해 해당 스토리지에 접근하는 것이 바람직하다.
|
|
|
|
### 노드의 `proxy` 하위 리소스에 대한 접근
|
|
|
|
노드 오브젝트의 하위 리소스인 프록시에 대한 접근 권한을 가지는 사용자는 Kubelet API에 대한 권한도 가지며,
|
|
이는 권한을 가지고 있는 노드에 위치한 모든 파드에서 명령어 실행 권한이 주어짐을 의미한다.
|
|
이러한 접근 권한을 통해 감시 로깅 및 어드미션 컨트롤에 대한 우회가 가능해짐으로,
|
|
해당 리소스에 대한 권한을 부여할 시에는 주의가 필요하다.
|
|
|
|
### 에스컬레이트 동사
|
|
|
|
사용자가 자신이 보유한 권한보다 더 많은 권한을 가진 클러스터롤을 생성하고자 할때, RBAC 시스템이 이를 막는 것이 보편적이다.
|
|
이와 관련하여, `escalate` 동사가 예외에 해당한다. [RBAC 문서](/docs/reference/access-authn-authz/rbac/#restrictions-on-role-creation-or-update)에서도 언급이 되었듯이,
|
|
해당 권한을 가진 사용자는 권한 에스컬레이션을 할 수 있다.
|
|
|
|
### 바인드 동사
|
|
|
|
해당 권한을 사용자에게 부여함으로써 `escalate` 동사와 유사하게
|
|
권한 에스컬레이션에 대한 쿠버네티스에 내장된 보호 기능을 우회할 수 있게 되며,
|
|
이는 사용자가 부여받지 않은 권한을 가진 롤에 대한 바인딩을 생성할 수 있게끔 한다.
|
|
|
|
### 가장 (Impersonate) 동사
|
|
|
|
사용자는 해당 동사를 통해 클러스터 내에서 다른 사용자를 가장하여 권한을 부여받을 수 있게 된다.
|
|
가장된 계정을 통해 필요 이상의 권한이 부여되지 않도록
|
|
해당 동사 부여시 주의를 기울일 필요가 있다.
|
|
|
|
### CSR 및 증명서 발급
|
|
|
|
CSR API를 통해 CSR에 대한 `create` 권한 및 `certificatesigningrequests/approval`에 대한 `update` 권한을 가진 사용자가,
|
|
서명자가 `kubernetes.io/kube-apiserver-client`인 새로운 클라이언트 증명서를 생성할 수 있게 되며 이를 통해 사용자는 클러스터를 인증할 수 있게 된다.
|
|
해당 클라이언트 증명서는 임의의 이름을 가지게 되며, 이에 중복된 쿠버네티스 시스템 구성 요소도 포함 된다.
|
|
이는 권한 에스컬레이션 발생 가능성을 열어두게 된다.
|
|
|
|
### 토큰 요청
|
|
|
|
`serviceaccounts/token`에 대해 `create` 권한을 가지는 사용자는
|
|
기존의 서비스 어카운트에 토큰을 발급할 수 있는 토큰리퀘스트를 생성할 수 있다.
|
|
|
|
### 컨트롤 어드미션 웹훅
|
|
|
|
`validatingwebhookconfigurations` 혹은 `mutatingwebhookconfigurations`에 대한 제어권을 가지는 사용자는
|
|
클러스터가 승인한 모든 오브젝트를 열람할 수 있는 웹훅을 제어할 수 있으며,
|
|
변화하는 웹훅의 경우에는 승인된 오브젝트를 변화시킬 수도 있다.
|
|
|
|
|
|
## 쿠버네티스 RBAC - 서비스 거부 위험 {#denial-of-service-risks}
|
|
|
|
### 객체 생성 서비스 거부 {#object-creation-dos}
|
|
클러스터 내 오브젝트 생성 권한을 가지는 사용자는
|
|
[쿠버네티스가 사용하는 etcd는 OOM 공격에 취약](https://github.com/kubernetes/kubernetes/issues/107325)에서 언급 되었듯이,
|
|
서비스 거부 현상을 초래할 정도 규모의 오브젝트를 생성할 수 있다.
|
|
다중 테넌트 클러스터에서 신뢰되지 못하거나 신뢰성이 적은 사용자에게
|
|
시스템에 대해 제한된 권한이 부여된다면 해당 현상이 나타날 수 있다.
|
|
|
|
해당 문제의 완화 방안 중 하나로는,
|
|
[리소스 쿼터](/ko/docs/concepts/policy/resource-quotas/#object-count-quota)를 사용하여
|
|
생성할 수 있는 오브젝트의 수량을 제한하는 방법이 있다.
|
|
|
|
## {{% heading "whatsnext" %}}
|
|
|
|
* RBAC에 대한 추가적인 정보를 얻기 위해서는 [RBAC 문서](/docs/reference/access-authn-authz/rbac/)를 참고한다.
|