[K8s] RBAC: Role, ClusterRole, ServiceAccount, RoleBinding
Kubernetes RBAC, RBAC, K8s RBAC, ServiceAccount, Role, ClusterRole, RoleBinding, ClusterRoleBinding
정의
RBAC (Role-Based Access Control) = K8s 의 권한 부여 모델. 주체 + 권한 + 바인딩.
사용 시나리오
| 상황 | RBAC 역할 |
|---|---|
| CI/CD 파이프라인 | SA 에 최소 권한만 부여, 배포 자동화 |
| 멀티팀 클러스터 | 팀별 namespace 관리 권한 격리 |
| Operator / Controller | CRD read/write 권한만 허용 |
| 감사 준비 | 누가 어떤 자원에 접근하는지 추적 |
API 요청 처리 흐름
flowchart LR
Req["API 요청<br/>(kubectl / pod)"]
Auth["Authentication<br/>(인증: 누구?)"]
Authz["Authorization<br/>(인가: 허용?)"]
Adm["Admission Control"]
ETCD["etcd 저장"]
Req --> Auth --> Authz --> Adm --> ETCD
RBAC 는 Authorization 단계 에서만 작동. Authentication 은 별도 플러그인 (X.509, OIDC 등).
4 객체
flowchart LR
User[User / Group<br/>또는 ServiceAccount] -->|RoleBinding| Role
User -->|ClusterRoleBinding| CRole[ClusterRole]
Role -->|"namespace 안"| API[API resources]
CRole -->|"cluster 전체"| API
| 객체 | 범위 |
|---|---|
Role | 단일 namespace |
ClusterRole | 전체 cluster |
RoleBinding | 같은 namespace 안 user → Role |
ClusterRoleBinding | cluster 전체 user → ClusterRole |
ServiceAccount
apiVersion: v1
kind: ServiceAccount
metadata:
name: app-sa
namespace: default
- Pod 가 K8s API 호출 할 때의 identity.
- 기본은
defaultSA. 명시 권장. - 모든 SA 는 토큰 자동 마운트 (
/var/run/secrets/kubernetes.io/serviceaccount/token).
# Pod 에 SA 연결
spec:
serviceAccountName: app-sa
automountServiceAccountToken: false # API 호출 안 하면 false 권장
Role 예시
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: pod-reader
namespace: default
rules:
- apiGroups: [""]
resources: [pods, pods/log]
verbs: [get, list, watch]
- apiGroups: [apps]
resources: [deployments]
verbs: [get, list]
| verb | 의미 |
|---|---|
get | 단일 |
list | 목록 |
watch | 변경 stream |
create | 생성 |
update | 갱신 |
patch | 부분 갱신 |
delete | 삭제 |
deletecollection | 일괄 삭제 |
RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: app-pod-reader
namespace: default
subjects:
- kind: ServiceAccount
name: app-sa
namespace: default
roleRef:
kind: Role
name: pod-reader
apiGroup: rbac.authorization.k8s.io
ClusterRole + ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata: { name: namespace-admin }
rules:
- apiGroups: ["*"]
resources: ["*"]
verbs: ["*"]
---
kind: ClusterRoleBinding
metadata: { name: alice-cluster-admin }
subjects:
- kind: User
name: alice
roleRef:
kind: ClusterRole
name: namespace-admin
최소 권한 패턴
flowchart TD
Goal["최소 권한 원칙"]
Goal --> P1["필요한 verb 만<br/>(get, list 등)"]
Goal --> P2["필요한 resource 만<br/>(pods 지정)"]
Goal --> P3["필요한 namespace 만<br/>(Role 우선)"]
Goal --> P4["별도 SA 사용<br/>(default SA 금지)"]
CI/CD SA 예시: 배포만 하는 SA 에 최소 권한 부여:
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: deployer
namespace: production
rules:
- apiGroups: [apps]
resources: [deployments]
verbs: [get, list, patch, update]
- apiGroups: [""]
resources: [pods]
verbs: [get, list]
검사 / 디버깅
# 내가 무엇을 할 수 있나?
kubectl auth can-i get pods
kubectl auth can-i list secrets --as alice
# 특정 SA 권한
kubectl auth can-i get pods --as=system:serviceaccount:default:app-sa
# 누가 어떤 권한?
kubectl get rolebinding,clusterrolebinding -A | grep alice
# SA 의 모든 RoleBinding 조회
kubectl get rolebindings -A -o json | \
jq '.items[] | select(.subjects[]?.name=="app-sa")'
Aggregated ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: monitoring
labels:
rbac.authorization.k8s.io/aggregate-to-monitoring: "true"
rules: [...]
다른 ClusterRole 이 자동 결합. 운영 도구의 plugin 권한 추가 패턴.
Workload Identity (IRSA / GKE WI)
클라우드 SA 를 K8s SA 와 연동해 AWS/GCP 권한 획득. 토큰 직접 관리 불필요.
flowchart LR
Pod["pod (SA: app-sa)"]
STS["AWS STS<br/>(token 교환)"]
OIDC["K8s OIDC Provider"]
IAM["AWS IAM Role"]
S3["AWS S3"]
Pod -->|"SA token"| STS
STS -->|"OIDC 검증"| OIDC
STS -->|"Role 확인"| IAM
STS -->|"임시 credential"| Pod
Pod -->|"임시 credential"| S3
AWS IRSA (EKS):
# ServiceAccount 에 IAM Role ARN 어노테이션
apiVersion: v1
kind: ServiceAccount
metadata:
name: app-sa
namespace: default
annotations:
eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/app-role
TIP
GKE Workload Identity, Azure Workload Identity 도 동일 패턴. 인스턴스 프로파일 없이 pod 단위 IAM 제어 가능.
흔한 함정
WARNING
verbs: ["*"]남발 = 권한 최소화 원칙 위배. 필요한 verb 만.- default SA 사용 = 모든 pod 가 같은 권한. 명시 SA + 최소 Role.
apiGroups: ["*"]와resources: ["*"]= 모든 자원 접근. cluster-admin과 다를 바 없음.- RoleBinding namespace 잘못 = Role 은 같은 namespace 만. 다른 namespace 면 무효.
- token 직접 사용 = 만료 짧음 (1시간 기본, 1.24+). projected SA token 으로 자동 갱신.
관련 위키
이 글의 용어 (4개)
- [Auth] mTLS (Mutual TLS): 양방향 인증서 인증auth-security
- 정의 mTLS (Mutual TLS) 는 서버뿐 아니라 클라이언트도 TLS 인증서로 자기 신분 증명. 일반 TLS = 서버 인증만, mTLS = 양방향. 활용: 서비스 메시 (I…
- [Auth] OAuth 2.0 / 2.1: Authorization Code + PKCEauth-security
- 정의 OAuth 2.0 (RFC 6749, 2012) 은 제3자 앱이 사용자 동의로 자원에 접근 하게 하는 권한 위임 프레임워크. 인증 (authentication) 이 아니라 …
- [AWS] IAM: User, Role, Policy, STScloud
- 정의 IAM (Identity and Access Management) = AWS 의 권한 관리 전부. User, Group, Role, Policy 로 구성. "누가 어떤 리소…
- [K8s] Pod: 컨테이너의 최소 단위, sidecar, lifecyclekubernetes
- 정의 Pod = K8s 의 가장 작은 배포 단위. 1개 이상의 컨테이너 + 공유 네트워크 + 공유 스토리지. [!IMPORTANT] Pod 는 컨테이너의 wrapping 이 아니…
이 개념을 다룬 위키 페이지 (12)
- wiki[Auth] mTLS (Mutual TLS): 양방향 인증서 인증
- wiki[AWS] EKS: managed Kubernetes
- wiki[AWS] IAM: User, Role, Policy, STS
- wiki[GitOps] ArgoCD: Kubernetes GitOps
- wiki[Kubernetes] Admission Controllers
- wiki[Kubernetes] Architecture (Control Plane + Node)
- wiki[K8s] ConfigMap & Secret: 설정과 비밀의 분리
- wiki[Kubernetes] CRDs & Operators
- wiki[Kubernetes] Namespace
- wiki[Kubernetes] Service Mesh (Istio, Linkerd, Cilium)
- wikikubectl
- wikiKubernetes
💬 댓글