RBAC는 ServiceAccount와 함께 어떻게 동작하며, Kubernetes 클러스터를 어떻게 보안하는가?

Question

IT Interview Practice · Accepted Answer

**RBAC (Role-Based Access Control)**는 API에서 *누가 무엇을 할 수 있는지*를 통제한다. 권한은 리소스에 대해 허용된 verb를 나열하는 **Role**에 **subject**(사용자, 그룹, **ServiceAccount**)를 **바인딩**함으로써 부여된다. RBAC는 더 넓은 클러스터 강화 전략의 한 계층이다.

## RBAC 모델

```text
SUBJECT (user / group / ServiceAccount)
   │  ~에 의해 바인딩
   ▼
RoleBinding ───────► Role         (namespaced: 하나의 namespace 내 권한)
ClusterRoleBinding ► ClusterRole  (클러스터 전역, 또는 namespace 간 재사용 가능)

Role/ClusterRole = 규칙의 집합: "이 RESOURCE에 대한 이 VERB들"
바인딩은 가산적(ADDITIVE)이며 deny가 없다 — 필요한 것만 부여한다.
```

## Role + RoleBinding 예시

```yaml
# Role: "app" namespace의 Pod에 대한 읽기 전용 접근
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: app
  name: pod-reader
rules:
  - apiGroups: [""]
    resources: ["pods", "pods/log"]
    verbs: ["get", "list", "watch"]
---
# 그 Role을 ServiceAccount에 바인딩
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: app
  name: read-pods
subjects:
  - kind: ServiceAccount
    name: my-app
    namespace: app
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io
```

## ServiceAccount: Pod를 위한 신원

```text
ServiceAccount는 Pod가 API 서버와 통신하는 데 사용하는 신원이다.
  → 모든 Pod가 하나를 받는다 (지정하지 않으면 namespace "default" SA).
  → projected token이 Pod에 마운트된다; RBAC가 그 token이 무엇을 할 수 있는지 결정.
모범 사례: 각 워크로드에 최소 권한 RBAC를 가진 자신만의 SA를 주고,
Pod가 API 접근이 필요 없으면 automountServiceAccountToken: false를 설정하라.
```

```yaml
apiVersion: v1
kind: ServiceAccount
metadata: { name: my-app, namespace: app }
automountServiceAccountToken: false   # API 호출이 필요 없으면 옵트아웃
---
apiVersion: apps/v1
kind: Deployment
# ...
spec:
  template:
    spec:
      serviceAccountName: my-app       # 이 신원으로 Pod 실행
```

## 심층 방어(Defense in depth) — RBAC를 넘어서

```text
AUTH        → 최소 권한 RBAC; 워크로드별 ServiceAccount; 접근 감사
NETWORK     → default-deny NetworkPolicy (허용되지 않으면 Pod가 통신 못 함)
WORKLOAD    → securityContext: runAsNonRoot, readOnlyRootFilesystem, capability 제거
              seccomp 프로필; Pod Security Admission(restricted)으로 강제
SECRETS     → etcd 저장 시 암호화; 외부 secret 관리자; secret에 대한 엄격한 RBAC
IMAGES      → 이미지 스캔, 신뢰할 수 있는 registry 사용, admission으로 강제(예: policy engine)
API/etcd    → etcd 제한 & 암호화; 어디서나 TLS; 익명 & cluster-admin 접근 제한
SUPPLY CHAIN→ 서명된 이미지, admission control (OPA/Gatekeeper, Kyverno)
```

```bash
kubectl auth can-i list pods --as=system:serviceaccount:app:my-app -n app
kubectl auth can-i --list -n app          # 현재 사용자가 무엇을 할 수 있나?
```

## 왜 중요한가

클러스터 보안은 시니어의 책임이고 ServiceAccount와 함께하는 RBAC가 그 토대이므로, 둘을 이해하는 것은 필수적인 보안 지식이다. RBAC 모델은 우아하고 체화할 가치가 있다: 권한은 **순수하게 가산적이며 deny가 없고**, 허용된 **리소스에 대한 verb**를 열거하는 **Role**(namespaced)이나 **ClusterRole**(클러스터 전역)에 **subject**(사용자, 그룹, 특히 **ServiceAccount**)를 **바인딩**함으로써 부여된다 — 이는 좋은 보안이 거부에 의존하는 것이 아니라 각 워크로드가 필요로 하는 것만 부여하는 데서(**최소 권한**) 온다는 뜻이다. **ServiceAccount가 Pod가 API를 호출하는 데 사용하는 신원**이라는 것 — 모든 Pod가 token을 받고, `default` SA가 흔한 과도 권한의 함정이며, 각 워크로드에 자신만의 최소 권한 SA를 주어야 하고(API 접근이 필요 없으면 token 자동 마운트를 비활성화) — 을 이해하는 것은 직접적으로 실용적이며 실제 오설정의 잦은 원천이다. 결정적으로, 시니어 엔지니어는 RBAC가 **심층 방어**의 한 계층일 뿐임을 안다: default-deny **NetworkPolicy**, 강화된 **securityContext** 설정(non-root, read-only root filesystem, capability 제거, seccomp), **Pod Security Admission**, Secret에 대한 **저장 시 암호화**와 외부 관리자, 이미지 스캔과 서명, admission controller(OPA/Gatekeeper, Kyverno), 잠긴 etcd/API 접근이 모두 결합되어 클러스터를 보호한다. Kubernetes 클러스터는 과도한 권한을 가진 단 하나의 ServiceAccount나 열린 NetworkPolicy가 완전한 침해로 이어질 수 있는 고가치 표적이므로, RBAC와 더 넓은 강화 도구 세트를 숙달하는 것은 프로덕션에서 클러스터를 안전하게 운영하는 데 기초가 된다.

RBAC 모델

Role + RoleBinding 예시

ServiceAccount: Pod를 위한 신원

심층 방어(Defense in depth) — RBAC를 넘어서

왜 중요한가

관련 질문