[Kubernetes] RBAC(Role-based Access Control) 기반 다중 사용자 보안

# Role 예시: 특정 네임스페이스의 pods 읽기만 허용
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-reader
  namespace: rbac-demo    # 이 네임스페이스에서만 유효
rules:
- apiGroups: [""]          # "" = core API group (pods, services, configmaps 등)
  resources: ["pods", "pods/log"]
  verbs: ["get", "list", "watch"]

# ClusterRole 예시: 모든 네임스페이스의 노드 정보 읽기
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: node-reader
rules:
- apiGroups: [""]
  resources: ["nodes"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["metrics.k8s.io"]
  resources: ["nodes", "pods"]
  verbs: ["get", "list"]

# 빌트인 ClusterRole 확인 (재사용 권장)
kubectl describe clusterrole view       # 읽기 전용
kubectl describe clusterrole edit       # 읽기/쓰기 (secrets 제외)
kubectl describe clusterrole admin      # 네임스페이스 전체 관리
kubectl describe clusterrole cluster-admin  # 클러스터 전체 관리

[클라이언트]  kubectl create deployment web -n production
   │
   ① 요청이 API 서버에 도착          (verb=create, resource=deployments.apps, namespace=production)
   │
   ② 인증(Authentication)            (인증서·토큰 → 주체 확정: user / group / serviceaccount)
   │    → 신원을 못 밝히면 401 Unauthorized
   │
   ③ 인가 시작(Authorization=RBAC)   (요청을 (subject, verb, resource, namespace) 튜플로 정규화)
   │
   ④ 바인딩 수집                     (그 주체를 subjects로 가리키는 RoleBinding·ClusterRoleBinding 조회)
   │
   ⑤ 규칙 대조                       (바인딩이 roleRef로 연결한 Role·ClusterRole의 rules와 튜플 매칭)
   │
   ⑥ allow/deny 판정                 (매칭되는 허용 규칙이 하나라도 있으면 allow, 없으면 기본 거부)
   │    → 거부면 403 Forbidden: "... cannot create deployments ..."
   │
   ⑦ 어드미션(Admission)             (인가 통과 후 오브젝트 내용을 검사·변형 — PodSecurity·웹훅)
   ▼
[etcd 저장]  오브젝트 생성 완료

# 1. ServiceAccount 생성
apiVersion: v1
kind: ServiceAccount
metadata:
  name: ci-sa
  namespace: ci
---
# 2. CI가 production 네임스페이스의 Deployment를 관리할 Role
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: deploy-manager
  namespace: production
rules:
- apiGroups: ["apps"]
  resources: ["deployments", "replicasets"]
  verbs: ["get", "list", "watch", "create", "update", "patch"]
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]
---
# 3. ci 네임스페이스의 ci-sa에 production의 deploy-manager Role 부여
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: ci-deploy-binding
  namespace: production    # 이 네임스페이스에서 권한 적용
subjects:
- kind: ServiceAccount
  name: ci-sa
  namespace: ci            # ServiceAccount가 있는 네임스페이스
roleRef:
  kind: Role
  name: deploy-manager
  apiGroup: rbac.authorization.k8s.io

kubectl apply -f ci-rbac.yaml

# 파드에 ServiceAccount 지정
# (지정 안 하면 네임스페이스의 default ServiceAccount 사용)
kubectl patch deployment my-app -n production \
  --type='json' \
  -p='[{"op":"add","path":"/spec/template/spec/serviceAccountName","value":"ci-sa"}]'

# 현재 사용자 권한 확인
kubectl auth can-i list pods -n production
# yes

# 다른 주체로 가장해서 확인 (--as)
kubectl auth can-i list pods \
  --as=system:serviceaccount:ci:ci-sa \
  -n production
# no  ← 권한 없음

# 어떤 권한이 있는지 전체 확인
kubectl auth can-i --list \
  --as=system:serviceaccount:ci:ci-sa \
  -n production
# Resources             Non-Resource URLs   Resource Names   Verbs
# deployments.apps      []                  []               [get list watch update patch]
# pods                  []                  []               [get list watch]

# 특정 동작 확인
kubectl auth can-i create deployments \
  --as=system:serviceaccount:ci:ci-sa \
  -n production
# yes

kubectl auth can-i delete nodes \
  --as=system:serviceaccount:ci:ci-sa
# no  ← 클러스터 레벨 권한 없음