Kubernetes ServiceAccount: Pod에 맞춤형 신분증과 권한을 부여하는 방법

안녕하세요! 👋 오늘은 쿠버네티스 보안의 핵심, ServiceAccount(서비스 어카운트)에 대해 알아보겠습니다.

 

여러분이 만든 애플리케이션이 파드(Pod) 안에서 실행되다가, 갑자기 다른 파드의 목록을 보거나 특정 설정 파일(ConfigMap)을 읽어야 하는 상황이 생겼다고 상상해 보세요. 이때 아무런 인증 절차 없이 쿠버네티스의 모든 정보에 접근할 수 있다면 정말 위험하겠죠? 💣

 

ServiceAccount는 바로 이럴 때 사용합니다. 사람에게 주민등록증이 있듯, 파드 안에서 실행되는 애플리케이션에게 부여하는 '신분증'이자, 그 신분증으로 무엇을 할 수 있는지 정해주는 '권한 설정'의 출발점입니다.

 

---

🤔 ServiceAccount란? Pod를 위한 신분증

쿠버네티스에는 두 종류의 계정이 있습니다.

1. 사용자 계정 (User Account): 저와 여러분처럼 kubectl 명령어를 사용하는 사람을 위한 계정입니다.
2. 서비스 어카운트 (ServiceAccount): 파드 안의 컨테이너에서 실행되는 프로세스(애플리케이션)를 위한 계정입니다. 즉, 기계(Machine)를 위한 계정이죠.

파드가 생성될 때 특별히 지정하지 않으면, 쿠버네티스는 해당 네임스페이스의 default라는 이름의 ServiceAccount를 자동으로 할당해 줍니다. 하지만 이 '기본 신분증'은 보안상의 이유로 거의 아무런 권한이 없습니다.

 

따라서 우리는 "최소 권한의 원칙(Principle of Least Privilege)"에 따라, 각 애플리케이션에 딱 필요한 만큼의 권한만 가진 맞춤형 ServiceAccount를 만들어 부여해야 합니다.

---

📜 권한 부여의 핵심 3총사: RBAC

ServiceAccount 자체는 신분증일 뿐, 그 자체로는 아무런 힘이 없습니다. 여기에 '권한'이라는 힘을 불어넣어 주는 것이 바로 RBAC(Role-Based Access Control, 역할 기반 접근 제어) 시스템입니다. RBAC의 핵심 3총사만 기억하면 모든 것이 쉬워집니다.

1. Role / ClusterRole (역할 - 무엇을 할 수 있는가?)
   • Role: 특정 네임스페이스 안에서만 유효한 권한입니다. (예: dev 네임스페이스의 파드(pods)를 조회(get, list)할 수 있는 권한)
   • ClusterRole: 네임스페이스에 국한되지 않고 클러스터 전체에 적용되는 권한입니다. (예: 모든 노드(nodes)를 조회할 수 있는 권한)
   • Role은 '역할'이라는 뜻 그대로, 허용되는 행동 규칙들을 모아놓은 권한 목록입니다.
2. ServiceAccount (주체 - 누가 하는가?)
   • 위에서 설명한 파드의 신분증입니다. 바로 이 ServiceAccount에게 Role에 정의된 권한을 부여하게 됩니다.
3. RoleBinding / ClusterRoleBinding (연결 - 누구에게 어떤 역할을 부여하는가?)
   • RoleBinding: ServiceAccount와 Role을 연결하여, 특정 네임스페이스 내의 권한을 부여합니다.
   • ClusterRoleBinding: ServiceAccount와 ClusterRole을 연결하여, 클러스터 전역의 권한을 부여합니다.
   • 가장 중요한 연결고리입니다! Binding은 특정 주체(Subject, 즉 ServiceAccount)와 특정 역할(Role)을 연결(Bind)해 주는 역할을 합니다.

정리: RoleBinding은 ServiceAccount에게 Role에 정의된 권한을 부여하는 마법의 주문입니다! ✨

---

🚀 단계별 실습 예제: 파드 목록 조회 권한 부여하기

자, 이제 my-app이라는 애플리케이션이 같은 네임스페이스에 있는 다른 파드들의 목록을 조회할 수 있도록 권한을 부여하는 전 과정을 실습해 보겠습니다.

1단계: ServiceAccount 생성하기

먼저, my-app만을 위한 전용 신분증을 만들어 줍니다.

# `default` 네임스페이스에 my-app-sa 라는 ServiceAccount 생성
kubectl create serviceaccount my-app-sa

 

YAML 파일로는 이렇게 생겼습니다.

apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-app-sa

 

2단계: Role 생성하기

파드를 조회(get, list, watch)할 수 있는 권한을 담은 Role을 정의합니다.

 

pod-reader-role.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-reader # 이 Role의 이름
rules:
- apiGroups: [""] # ""는 핵심(core) API 그룹을 의미합니다. Pod는 여기에 속해요.
  resources: ["pods"] # 어떤 리소스에 대한 권한인가? -> 파드
  verbs: ["get", "list", "watch"] # 어떤 행동을 허용할 것인가? -> 조회, 목록 보기, 변화 감지

 

kubectl apply -f pod-reader-role.yaml

 

3단계: RoleBinding으로 연결하기

이제 1단계에서 만든 신분증(my-app-sa)과 2단계에서 만든 권한 목록(pod-reader)을 연결해 줍니다.

read-pods-binding.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods-binding
subjects: # 권한을 부여받을 주체(대상)
- kind: ServiceAccount
  name: my-app-sa # 바로 이 서비스 어카운트에게!
roleRef: # 어떤 역할을 부여할 것인가?
  kind: Role
  name: pod-reader # 바로 이 Role을!
  apiGroup: rbac.authorization.k8s.io

 

kubectl apply -f read-pods-binding.yaml

 

4단계: Pod에 ServiceAccount 할당하기

마지막으로, 애플리케이션 파드를 생성할 때 spec.serviceAccountName 필드를 추가하여 우리가 만든 맞춤형 신분증을 지정해 줍니다.

my-app-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: my-app
spec:
  # 이 파드는 'default'가 아닌 'my-app-sa' 신분증을 사용합니다!
  serviceAccountName: my-app-sa
  containers:
  - name: my-app-container
    # kubectl이 포함된 이미지로 파드 목록 조회를 테스트합니다.
    image: bitnami/kubectl
    command: ["kubectl", "get", "pods"]

 

kubectl apply -f my-app-pod.yaml

 

이제 이 파드는 생성되면서 pod-reader Role에 정의된 권한을 갖게 되고, 파드 내부의 애플리케이션은 쿠버네티스 API 서버에 자신을 my-app-sa로 인증한 뒤 당당하게 파드 목록을 조회할 수 있게 됩니다!

---

✅ 정리하며

ServiceAccount와 RBAC는 쿠버네티스 보안의 기본이자 핵심입니다.

• ServiceAccount는 파드(애플리케이션)를 위한 신분증입니다.
• Role은 '무엇을 할 수 있는지'를 정의한 권한 목록입니다.
• RoleBinding은 '누가 어떤 권한을 갖는지'를 연결해 주는 접착제입니다.

항상 최소 권한의 원칙을 기억하세요. default ServiceAccount를 사용하기보다, 각 애플리케이션의 역할에 맞는 최소한의 권한을 가진 ServiceAccount를 만들어 사용하는 습관을 통해 여러분의 클러스터를 더욱 안전하게 지킬 수 있습니다.

---

태그: Kubernetes, K8s, ServiceAccount, RBAC, 보안, 쿠버네티스, DevOps, 인증, 권한, MSA