본문 바로가기

클라우드/GCP

RBAC 정리

반응형

해당 내용은 GKE 기반으로 작성되었으며 대부분의 내용은 Google 가이드 문서를 참조하였음

 

역할 기반 엑세스 제어(RBAC)

역할은 특정 쿠버네티스 객체 또는 특정 유형의 쿠버네티스 객체를 대상으로 함
지정된 객체와 관련하여 역할에서 부여하는 작업을 정의

RoleBinding 도 쿠버네티스 객체이며 사용자에게 역할을 부여함

GKE에서의 사용자
- Google Cloud 사용자
- Google Cloud 서비스 계정
- Kubernetes 서비스 계정
- Google Workspace 사용자
- Google Workspace Google 그룹
- X509 클라이언트 인증서를 사용하여 인증된 사용자


RBAC 작동 방식

ClusterRole : 모든 네임스페이스 또는 전체 클러스터에 적용할 수 있는 권한 집합
Role: 단일 네임스페이스로 제한되는 권한 집합

Role 또는 ClusterRole에서 권한을 rules로 정의 
역할의 각 rules 필드는 API 그룹, 이 API 그룹내에 있는 리소스, 이러한 리소스에 허용되는 작업으로 구성
(선택적) resourceNames 필드 사용하여  API 리소스의 명명된 인스턴스로 작업의 범위 지정 가능
ex) https://cloud.google.com/kubernetes-engine/docs/best-practices/rbac?hl=ko#named-resources 

----------------------------------------------------------------------------------------------------------------

ClusterRoleBinding: 클러스터에서 모든 네임스페이스의 사용자 또는 그룹에 ClusterRole을 바인딩 함
RoleBinding: 특정 네임스페이스 내에서 사용자 또는 그룹에 Role 또는 ClusterRole을 바인딩 함

역할을 정의 후 RoleBinding 또는 ClusterRoleBinding을 사용하여 역할을 주체에 바인딩함 
단일 네임스페이스 또는 다중 네임스페이스에서 권한을 부여할지에 따라 바인딩 유형을 선택


---
RBAC 역할 설계

최소 권한의 원칙 사용

 

이름 유형 설명
cluster-admin ClusterRole 클러스터의 모든 리소스에서 모든 작업을 수행할 수 있는 권한을 주체에게 부여합니다.
system:anonymous 사용자 Kubernetes는 인증 정보가 제공되지 않은 API 서버 요청에 이 사용자를 할당합니다.
이 사용자에게 역할을 바인딩하면 인증되지 않은 사용자에게 해당 역할에서 부여한 권한이 부여됩니다.
system:unauthenticated 그룹 Kubernetes는 인증 정보가 제공되지 않은 API 서버 요청에 이 그룹을 할당합니다.
이 그룹에 역할을 바인딩하면 인증되지 않은 사용자에게 해당 역할에서 부여한 권한이 부여됩니다.
system:authenticated 그룹 GKE는 Google 계정으로 로그인한 모든 사용자의 API 서버 요청에 이 그룹을 할당합니다. 실제로는 누구나 Google 계정을 만들 수 있으므로 system:unauthenticated와 유의미한 차이가 없습니다.
이 그룹에 역할을 바인딩하면 Google 계정이 있는 모든 사용자에게 해당 역할에서 부여한 권한이 부여됩니다.
system:masters 그룹 Kubernetes는 시스템 기능을 사용 설정하기 위해 기본적으로 이 그룹에 cluster-admin ClusterRole을 할당합니다.
이 그룹에 자신의 주체를 추가하면 이 주체가 클러스터의 모든 리소스에서 모든 작업을 수행할 수 있습니다.

 

cluster-admin은 모든 권한이기 때문에 조심히 사용해야함 

 

Google 가이드라인

  • system:masters 그룹에 자신의 주체를 추가하지 않습니다.
  • system:unauthenticated 그룹을 RBAC 역할에 바인딩하지 않습니다.
  • system:authenticated 그룹을 RBAC 역할에 바인딩하지 않습니다.
  • system:anonymous 사용자를 RBAC 역할에 바인딩하지 않습니다.
  • 사용자의 주체 또는 기본 사용자 및 그룹에 cluster-admin ClusterRole을 바인딩하지 않습니다. 애플리케이션에 많은 권한이 필요한 경우 필요한 정확한 권한을 결정하고 해당 목적에 대한 특정 역할을 만듭니다.
  • 주체를 바인딩하기 전 다른 기본 역할로 부여되는 권한을 평가합니다.
  • 이러한 그룹의 구성원을 수정하기 전 기본 그룹에 바인딩된 역할을 평가합니다

 

※ 버전 1.28 이상의 GKE 클러스터는 cluster-admin 롤을 사용자 및 그룹에 등록하는걸 허용하지 않음 (master 그룹 제외)

 

 

네임스페이스 수준으로 권한 범위 지정 방법

  • 하나의 네임스페이스에서 리소스에 액세스를 부여하려면 RoleBinding과 함께 Role을 사용합니다.
  • 하나를 초과하는 네임스페이스에서 리소스에 액세스를 부여하려면 각 네임스페이스에 대해 RoleBinding과 함께 ClusterRole을 사용합니다.
  • 모든 네임스페이스에서 리소스에 액세스를 부여하려면 ClusterRoleBinding과 함께 ClusterRole을 사용합니다.

와일드카드(*)로 권한 부여하지 않고 리소스 별로 별도의 규칙을 사용하여 최소 권한 엑세스를 부여하여야 함

같은 롤을 부여할 경우 리소스를 묶어서 정의함

resourceNames 필드를 사용하여 리소스 엑세스 제한을 할 수 있음

 

 

구글 가이드 방식

 

1. 각  워크로드에 쿠버네티스 서비스 계정 생성하여 사용하여 최소 권한 부여후 바인딩 하여 사용

2. 기본 서비스 계정(default) 사용 하지 않음 (기본적으로 생성되는 계정)

3. 서비스 계정 토큰을 자동 마운트 하지 않음 (automountServiceAccountToken 필드 Kubernetes가 Kubernetes 서비스 계정에 대한 사용자 인증 정보 토큰을 포드에 삽입하도록 지정 기본 값 true)

4. 보안 비밀 기반 토큰보다 임시 토큰 선호

 

 

 

 

 

반응형