Kubernetes RBAC & ServiceAccount

1. RBAC (Role-Based Access Control)

RBAC는 사용자, 그룹, 그리고 서비스 계정이 Kubernetes API에 접근할 수 있는 권한을 제한하는 시스템이다. 클러스터 리소스에 대한 제어를 세분화하고 최소 권한 원칙을 적용할 수 있다.

1.1 구성 요소

- Role

NameSpace range 에서 적용되는 역할이다. 특정 NameSpace 안에서 어떤 Resource(API Object)에 대해 어떤 작업을 허용할지를 정의한다.  작업(verb: get, list, create, update, delete 등)

- ClusterRole

Cluster 전체에 적용되는 역할이다. NameSpace와 관계없이 공통적으로 필요한 Resource 나 Cluster Level의 resource 에 대한 권한을 정의할 때 사용한다.

# Role 정의 예시

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: my-namespace
  name: pod-reader
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "list", "watch"]

 

- RoleBinding

특정 NameSpace 내에서 Role을 사용자, 그룹 또는 ServiceAccount 에 Binding하여 해당 NameSpace 내 Resource 에 대한 접근 권한을 부여한다.

- ClusterRoleBinding

Cluster 전체에서 특정 ClusterRole을 사용자, 그룹, 또는 ServiceAccount 에 Binding 한다.

# RoleBinding 정의 예시

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: my-namespace
subjects:
  - kind: ServiceAccount
    name: my-service-account
    namespace: my-namespace
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

 

1.2 RBAC 동작원리

- 권한 검증 

Client ( 사용자, 그룹 또는 Service Account ) 가 Kubernetes API 서버에 요청을 보내면 API 서버는 해당 주체가 요청한 작업을 수행할 수 있는 지 RBAC 정책을 통해 확인한다

- 세분화된 제어

RBAC를 통해 관리자들은 각 주체별로 정확히 필요한 작업만 허용하고 불필요한 권한 상승을 방지할 수 있다. 

- 사용자 / 그룹 관리

RBAC는 외부 인증 시스템 (OIDC, LDAP 등)과 연동할 수 있으며 이를 통해 내부 사용자 및 그룹 정보를 기반으로 세밀한 권한 제어가 가능하다.

 

1.3 RBAC 사용하는 이유?

RBAC는 권한 최소화 원칙에 따라 필요한 작업만 허용하고 민감한 리소스에 대한 허용되지 않은 접근을 방지한다. 대규모 클러스 환경에서 여러 사용자와 서비스 계정의 권한을 중앙 집중식으로 관리할 수 있게 해준다. 그리고 어떤 주체가 어떤 작업을 수행하는 지 기록할 수 있어서 보안 감사 및 문제 해결에 도움이 된다.

 

1.4 AWS IAM Policy 와 RBAC 의 차이점

RBAC 를 보면 AWS IAM Policy 가 떠오를 정도로 비슷하다.

두 시스템은 모두 엑세스 제어를 위한 Policy 를 정의하지만 적용 대상, 구현 방식 그리고 세부 기능에서 차이가 난다.

- 적용 대상

Kubernetes RBAC는 Cluster 내부의 API 접근과 리소스 관리에 집중되었다.

AWS IAM Policy는 AWS 인프라 전반에 대한 세밀한 서비스별 권한을 제어한다.

- 구성 방식

RBAC는 Role, ClusterRole, RoleBinding, ClusterRoleBinding 을 이용해 접근 제어를 한다.

AWS Policy는 Json 형식의 문서로 상세 액션, 리소스 및 조건을 기술하고 이를 사용자, 그룹 그리고 역할에 부여한다.

- 세밀함과 유연성

AWS Policy는 조건 기반 제어를 포함한 매우 세밀한 접근 제어가 가능하지만

RBAC는 상대적으로 단순하게 Verb 기반 접근 제어에 초점이 맞춰져있다.

- 운영 및 관리

두 시스템 모두 최소 권한 원칙을 적용하여 보안을 강화하지만 운영 환경과 규모 그리고 복잡성에서 차이가 있으며 각각의 플랫폼 특성에 맞게 관리 도구와 전략이 필요하다.

 

2. ServiceAccount

ServiceAccount는 Cluster 내부에서 실행 중인 pod가 Kubernetes API에 접근할 때 사용하는 주체이다.

애플리케이션이 Cluster 내부의 Resource ( ConfigMap, Secret, Event etc) 에 접근하거나 제어 작업을 수행할 때 사용한다.

 

2.1 개념 및 구성

Kubernetes는 각 NameSpace에 default ServiceAccount를 자동으로 생성한다. 필요에 따라 별도의 ServiceAccount를 생성하고 해당 Pod 에 명시적으로 할당할 수 있다.

- ServicaAccount Account 생성

apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-service-account
  namespace: my-namespace

 

- 인증 방식

ServiceAccount는 Pod에 자동으로 주입되는 Secret (Token)을 통해 API 서버에 인증된다. 해당 Token은 Pod의 /var/run/secrets/kubernetes.io/serviceaccount/token 에 Mount 된다. 이를 통해 Pod 내 Application은 자신이 어떤 ServiceAccount로 동작하는 지를 인식하고 API 접근 시 인증 정보를 활용할 수 있게 된다.

 

2.2 ServiceAccount & RBAC

- 권한 부여

ServiceAccount는 RBAC (RoleBinding, ClusterRoleBinding)을 통해 필요한 권한을 부여받는다.

예를 들어, 특정 ServiceAccount에 Pod를 읽거나 생성하는 권한만 부여하고자 할 때, RBAC 정책을 사용해 그 작업에 필요한 Role 또는 ClusterRole을 바인딩할 수 있다.

- 보안 측면

ServiceAccount를 사용하면 애플리케이션마다 서로 다른 권한 세트를 적용할 수 있고 하나의 Pod에 공격을 당해도 해당 ServiceAccount 의 권한에 제한되어 피해를 줄일 수 있다.

 

+ 추가적으로 ServiceAccount의 Token은 Pod 내부에 Mount 될때 기본적으로 plain text(평문)에 가까운 형태로 저장된다. 따라서 민감한 정보는 별도의 Secret으로 관리하고 필요한 경우 RBAC에서 별도의 접근 제어를 추가해야할 수도 있다.