[Kubernetes] RBAC

RBAC (Role-Based Access Control)란?

RBAC는 Kubernetes 내 리소스에 대한 접근을 제어하기 위한 권한 기반 접근 제어

 

 

 

RBAC의 구성 요소

1. Role / ClusterRole

• Role: 특정 namespace 내 권한 정의
• ClusterRole: 클러스터 전체 혹은 여러 namespace에 걸친 권한 정의

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

2. RoleBinding / ClusterRoleBinding

• RoleBinding: Role을 특정 사용자, 그룹 또는 ServiceAccount에 namespace 단위로 연결
• ClusterRoleBinding: ClusterRole을 클러스터 전체에 연결

# RoleBinding 예시
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: dev
subjects:
- kind: User
  name: alice
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

3. ServiceAccount

• Kubernetes 내부에서 Pod가 API 서버와 통신할 때 사용하는 계정
• 기본적으로 네임스페이스별로 자동 생성됨 (default ServiceAccount)

kubectl create serviceaccount my-sa -n dev

---

RBAC 구성 및 확인

클러스터 내 역할 및 바인딩 목록 조회

# 모든 Role 확인
kubectl get roles --all-namespaces

# 모든 RoleBinding 확인
kubectl get rolebindings --all-namespaces

# 모든 ClusterRole 확인
kubectl get clusterroles

# 모든 ClusterRoleBinding 확인
kubectl get clusterrolebindings

 

특정 Role/Binding 상세 확인

kubectl describe role pod-reader -n dev
kubectl describe rolebinding read-pods -n dev

 

ServiceAccount에 역할 부여

# 네임스페이스 생성
kubectl create namespace dev

# ServiceAccount 생성
kubectl create serviceaccount sa-reader -n dev

# Role 생성
kubectl apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: dev
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list"]
EOF

# RoleBinding 생성
kubectl create rolebinding rb-pod-reader \
  --role=pod-reader \
  --serviceaccount=dev:sa-reader \
  -n dev

권한 테스트 및 오류 확인

# sa-reader가 Pod 목록 조회 가능 여부 확인
kubectl auth can-i list pods --as=system:serviceaccount:dev:sa-reader -n dev
# 예상 출력: yes

# sa-reader가 Pod 삭제 가능 여부 확인
kubectl auth can-i delete pods --as=system:serviceaccount:dev:sa-reader -n dev
# 예상 출력: no

# 권한 부족 시나리오 테스트 (직접 Pod 접근 시도)
kubectl get pods -n dev --as=system:serviceaccount:dev:sa-reader
# 성공 시 Pod 목록 출력

 

 

---

실제 환경에서는

• 최소 권한 원칙 (Least Privilege Principle)
• 정기적인 권한 감사 및 불필요한 권한 제거
• 네임스페이스 별 권한 분리
• kubectl auth can-i 명령으로 권한 확인 및 디버깅

실제 환경

+------------------+       +------------------+       +------------------+
|      Role        |<----->|   RoleBinding    |<----->|  ServiceAccount  |
| (Namespace 내    |       | (역할과 주체 연결)|       | (Pod의 신원)     |
| 권한 정의)       |       +------------------+       +------------------+
+------------------+                |                        |
       |                            |                        |
       | Defines Permissions        | Binds to                |
       |                            |                        |
       v                            v                        v
+------------------+       +------------------+       +------------------+
| Kubernetes       |       | Users / Groups   |       | Pods             |
| Resources        |       | (인간 사용자)     |       | (워크로드 실행)   |
| (Pods, ConfigMap)|       +------------------+       +------------------+
| etc.)            |                                          |
+------------------+                                          |
       |                                                     |
       | In EKS: AWS IAM Role                                |
       | Assumed via IRSA                                    |
       v                                                     v
+------------------+                                 +------------------+
| AWS Resources    |<--------------------------------| AWS IAM Role     |
| (S3, DynamoDB,   |                                 | (EKS에서 Pod에   |
| etc.)            |                                 | 연결)            |
+------------------+                                 +------------------+

• Role: 네임스페이스 내에서 특정 리소스(예: Pods)에 대한 권한(get, list 등)을 정의
• RoleBinding: Role을 특정 주체(사용자, 그룹, ServiceAccount)에 연결
• ServiceAccount: Pod가 Kubernetes API와 통신할 때 사용하는 어카운트
• EKS에서 AWS 리소스 접근: ServiceAccount에 AWS IAM Role을 연결(IRSA: IAM Roles for Service Accounts)하여 AWS 리소스(S3, DynamoDB 등)에 접근
  • IRSA는 ServiceAccount와 AWS IAM Role을 연결하는 메커니즘으로, Pod가 AWS SDK/API를 호출할 때 필요한 권한을 부여

 

---

 

예시

• dev 네임스페이스에서 Pod 목록을 조회할 수 있는 권한 부여
• Pod가 AWS S3 버킷(my-bucket)에 접근할 수 있도록 설정

 

 

1. Role 생성

dev 네임스페이스에서 Pod를 조회할 수 있는 권한을 정의

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

2. ServiceAccount 생성

Pod가 사용할 ServiceAccount를 생성

EKS에서 AWS IAM Role과 연결하려면 Annotation을 추가

# s3-access-sa.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  namespace: dev
  name: s3-access-sa
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/eks-s3-access-role

• eks.amazonaws.com/role-arn은 AWS IAM Role의 ARN을 지정하며, IRSA를 통해 이 ServiceAccount가 해당 IAM Role을 assume

 

3. RoleBinding 생성

pod-reader Role을 s3-access-sa ServiceAccount에 연결

# pod-reader-binding.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: dev
  name: pod-reader-binding
subjects:
- kind: ServiceAccount
  name: s3-access-sa
  namespace: dev
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

4. AWS IAM Role 및 정책 (EKS에서 S3 접근)

AWS IAM Role을 생성하고, S3 버킷에 접근할 수 있는 정책

# IAM 정책 (s3-access-policy.json)
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::my-bucket",
        "arn:aws:s3:::my-bucket/*"
      ]
    }
  ]
}

IAM Role 생성 후, EKS 클러스터의 OIDC 제공자와 신뢰 관계를 설정

# IAM Role 신뢰 관계 (trust-policy.json)
{
"Version": "2012-10-17",
"Statement": [
  {
    "Effect": "Allow",
    "Principal": {
      "Federated": "arn:aws:iam::123456789012:oidc-provider/oidc.eks.us-west-2.amazonaws.com/id/EXAMPLED539D4633E53DE1B716B304"
    },
    "Action": "sts:AssumeRoleWithWebIdentity",
    "Condition": {
      "StringEquals": {
        "oidc.eks.us-west-2.amazonaws.com/id/EXAMPLED539D4633E53DE1B716B304:sub": "system:serviceaccount:dev:s3-access-sa"
      }
    }
  }
]
}

5. Pod에서 테스트

ServiceAccount를 사용하는 Pod를 배포해 S3 접근을 테스트

# test-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  namespace: dev
  name: s3-test-pod
spec:
  serviceAccountName: s3-access-sa
  containers:
  - name: aws-cli
    image: amazon/aws-cli
    command: ["sh", "-c", "aws s3 ls s3://my-bucket && sleep 3600"]

• 실행:

  kubectl apply -f test-pod.yaml
  kubectl logs s3-test-pod -n dev

  • 성공 시 my-bucket의 객체 목록이 출력

 

6. 권한 확인

Kubernetes와 AWS 권한이 제대로 작동하는지 확인

# Kubernetes 권한 확인
kubectl auth can-i list pods --as=system:serviceaccount:dev:s3-access-sa -n dev
# 출력: yes

# AWS S3 접근 확인 (Pod 내부에서)
kubectl exec -it s3-test-pod -n dev -- aws s3 ls s3://my-bucket

---

 

참고 문서 및 리소스

• Kubernetes 공식 문서 - RBAC 개요
• Kubernetes 공식 문서 - ServiceAccount
• RBAC 권한 시뮬레이션 도구: kubectl auth can-i
• 도구 :
  • rbac-tool: RBAC 정책 분석 및 시각화
  • kubectl-who-can: 특정 리소스에 대한 권한 소유자 확인