Security - Authorization(RBAC)

인증(Authentication)은 “누가 클러스터에 들어왔는가”를 결정합니다.
인가(Authorization)는 “들어온 주체가 무엇을 할 수 있는가”를 결정합니다.

Kubernetes에서 kubectl로 수행하는 거의 모든 작업은 결국 kube-apiserver에 대한 요청이며, 인가 단계는 이 요청이 허용(Allow) 될지 거부(Deny) 될지를 판정합니다.

---

1) 관리자가 인가를 신경 써야 하는 이유

클러스터 관리자는 모든 작업을 수행할 수 있습니다.

• Pod/Node/Deployment 같은 오브젝트 조회
• 오브젝트 생성/수정/삭제
• 노드 추가/삭제, 스토리지/네트워킹 설정 변경 등

하지만 운영 환경에서는 곧 다양한 주체가 클러스터에 접근합니다.

• 다른 관리자(Admin)
• 개발자(Developer)
• 테스터(QA)
• 모니터링 애플리케이션
• CI/CD 도구(Jenkins, Argo CD 등)
• 외부 시스템이 호출하는 ServiceAccount 기반 자동화

이때 “인증”만 제공하면 사고가 납니다. 예를 들어 개발자가 노드를 삭제하거나, 스토리지/네트워크 구성을 수정하는 권한까지 가지면 운영 안정성이 무너집니다.

인가의 핵심 목적은 다음입니다.

• 최소 권한 원칙(Least Privilege): 필요한 권한만 부여
• 역할 분리(Separation of Duties): 운영/개발/배포 자동화 권한 구분
• 네임스페이스 기반 격리: 팀/조직별 범위 제한

---

2) Kubernetes Authorization 메커니즘 개요

Kubernetes는 여러 인가 방식을 지원합니다.

• Node Authorizer
• ABAC (Attribute-Based Access Control)
• RBAC (Role-Based Access Control)
• Webhook (외부 인가 시스템 연동, 예: OPA)

실무에서 가장 일반적인 구성은 다음 조합입니다.

• Node Authorizer + RBAC (+ 필요 시 Webhook)

---

3) Node Authorizer: “노드(kubelet) 전용” 인가

클러스터 내부에서 kubelet은 API 서버와 지속적으로 통신합니다.

• kubelet이 읽는 것: Service, Endpoint, Node, Pod 정보 등
• kubelet이 보고하는 것: Node 상태(NodeStatus) 등

이 “노드 운영에 필수적인 요청”을 처리하는 특수 인가자가 Node Authorizer입니다.

kubelet 요청의 조건(중요)

강의에서 언급된 핵심 포인트:

• kubelet 사용자 이름은 보통 system:node:<node-name> 형태
• 그룹은 system:nodes

즉, system:nodes 그룹(그리고 system:node: 접두사 사용자)에서 오는 요청은 Node Authorizer가 kubelet에 필요한 권한으로 승인 처리합니다.

---

4) ABAC: 사용자/그룹을 정책 파일(JSON)로 직접 매핑

ABAC는 “사용자(또는 그룹) 속성 기반”으로 정책을 정의하고, 이를 JSON 정책 파일로 관리합니다.

예: dev-user가 Pod를 get/list/create/delete 할 수 있도록 정책 작성

ABAC의 단점(운영 난이도)

• 정책 변경 시 정책 파일을 수동 편집
• 변경 반영을 위해 kube-apiserver 재시작이 필요한 경우가 많음
• 사용자/그룹이 늘수록 파일이 비대해지고 관리가 어려움

그래서 현대 운영에서는 ABAC보다는 RBAC가 표준입니다.

---

5) RBAC: 역할(Role) 중심의 표준 접근

RBAC는 Kubernetes의 대표적인 인가 방식입니다.

ABAC처럼 “사용자 ↔ 권한”을 직접 연결하는 대신:

1. 역할(Role/ClusterRole)에 권한 규칙을 정의하고
2. 사용자(또는 그룹/서비스어카운트)를 바인딩(RoleBinding/ClusterRoleBinding)으로 연결합니다.

장점

• 역할을 수정하면 그 역할에 연결된 대상에게 즉시 반영
• 네임스페이스 범위(Role) / 클러스터 범위(ClusterRole)로 체계화 가능
• 운영 표준으로 자리 잡음

---

6) Webhook: 외부 인가 시스템에 위임 (예: OPA)

Kubernetes의 인가 결정을 외부 정책 엔진에 위임할 수 있습니다.

• Kubernetes가 요청 정보를 Webhook으로 전달
• OPA 같은 외부 시스템이 allow/deny 판단
• 결과에 따라 Kubernetes가 최종 승인/거부

조직 통합 정책, 정책을 코드로 운영(Policy as Code)하려는 환경에서 유용합니다.

---

7) Authorization 모드 설정: --authorization-mode

kube-apiserver는 --authorization-mode 옵션으로 인가 모듈을 설정합니다.

• 미지정 시(강의 기준) 기본은 AlwaysAllow
• 여러 모드를 쉼표로 나열 가능

예:

--authorization-mode=Node,RBAC,Webhook

평가 순서(체인 동작)

• 요청은 지정된 순서대로 모듈이 처리
• 어떤 모듈이 “거부”하거나 “대상이 아님”이면 다음 모듈로 넘어감
• 어떤 모듈이 승인하면 즉시 종료(더 이상 평가하지 않음)
• 끝까지 승인되지 않으면 거부

---

RBAC 실전: Role / RoleBinding 만들기

이제 “RBAC를 실제로 어떻게 구성하는가”를 강의 흐름 그대로 정리합니다.

---

8) Role 만들기: 권한 규칙 정의

역할을 만들려면 Role 오브젝트를 생성합니다.

• apiVersion: rbac.authorization.k8s.io/v1
• kind: Role
• metadata.name: 역할 이름 (예: developer)
• rules: 권한 규칙 목록

각 rule에는 3가지 핵심 섹션이 있습니다.

• apiGroups
• resources
• verbs

(1) Core API 그룹은 apiGroups: [""]

강의에서 “core 그룹은 비워둘 수 있다”고 했는데, YAML 관점에서 가장 안전한 표현은 보통 다음입니다.

• Core 그룹(예: pods, configmaps): apiGroups: [""]
• Named 그룹(예: deployments=apps): apiGroups: ["apps"]

개발자 Role 예시 (Pod + ConfigMap)

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: developer
  namespace: default
rules:
  - apiGroups: [""]          # core group
    resources: ["pods"]
    verbs: ["get", "list", "create", "delete"]
  - apiGroups: [""]          # core group
    resources: ["configmaps"]
    verbs: ["get", "list", "create", "delete"]

포인트: 한 Role 안에 여러 rule을 추가할 수 있습니다.

생성

kubectl apply -f role-developer.yaml

---

9) RoleBinding 만들기: 사용자/그룹/SA를 Role에 연결

다음 단계는 사용자를 역할에 연결하는 것입니다. 이를 위해 RoleBinding 오브젝트를 생성합니다.

• kind: RoleBinding
• subjects: “누구에게” (User/Group/ServiceAccount)
• roleRef: “어떤 Role에” 연결할지

RoleBinding 예시 (dev-user → developer Role)

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: dev-user-to-developer
  namespace: default
subjects:
  - kind: User
    name: dev-user
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: developer
  apiGroup: rbac.authorization.k8s.io

생성:

kubectl apply -f rolebinding-dev-user.yaml

---

10) Role/RoleBinding은 “네임스페이스 스코프”다

강의에서 강조한 포인트:

• Role과 RoleBinding은 네임스페이스 범위입니다.
• 위 예시라면 dev-user는 default 네임스페이스에서만 pods/configmaps 권한이 있습니다.

다른 네임스페이스로 제한하거나 적용하려면:

• Role/RoleBinding YAML의 metadata.namespace를 해당 네임스페이스로 지정
• 또는 -n <namespace>로 생성/조회

예: test 네임스페이스에 만들려면

metadata:
  namespace: test

---

11) 생성된 Role/RoleBinding 조회/상세 확인

목록 조회

kubectl get roles -n default
kubectl get rolebindings -n default

상세 확인(describe)

kubectl describe role developer -n default
kubectl describe rolebinding dev-user-to-developer -n default

describe role에서는 리소스/동사 권한이 보기 좋게 정리되어 나타납니다.

---

12) “이 사용자가 이걸 할 수 있나?” 권한 검증: kubectl auth can-i

권한이 맞게 구성됐는지 확인하는 표준 방법입니다.

현재 사용자 기준

kubectl auth can-i create pods -n default
kubectl auth can-i delete nodes

관리자 권한으로 “다른 사용자”를 가장해 테스트: --as

실무에서 매우 자주 씁니다. 사용자가 실제로 로그인/인증하지 않아도 권한 검증이 가능합니다.

예: dev-user가 Deployment 생성 가능한지 확인
(권한을 주지 않았다면 no가 나와야 정상)

kubectl auth can-i create deployments --as=dev-user -n default

예: dev-user가 Pod 생성 가능한지 확인

kubectl auth can-i create pods --as=dev-user -n default

예: dev-user가 test 네임스페이스에서 Pod 생성 가능한지 확인
(default에만 Role/RoleBinding을 만들었다면 no가 정상)

kubectl auth can-i create pods --as=dev-user -n test

---

13) resourceNames로 “특정 리소스만” 접근 허용하기

네임스페이스 내 리소스(Pod 등)에 대해 “전체가 아니라 일부만” 허용할 수도 있습니다.

예: default 네임스페이스에 Pod가 5개 있는데,

• blue, orange Pod만 접근 허용
• 나머지는 접근 불허

Role rule에 resourceNames를 추가합니다.

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-limited-reader
  namespace: default
rules:
  - apiGroups: [""]
    resources: ["pods"]
    resourceNames: ["blue", "orange"]
    verbs: ["get"]

주의: resourceNames는 보통 get/delete 같은 “개별 리소스 대상 동사”와 함께 쓰는 게 자연스럽습니다.
list는 “전체 컬렉션” 개념이라 resourceNames로 제한하는 형태가 기대대로 동작하지 않는 경우가 많습니다(정책 설계 시 보통 get 중심으로 제한).

바인딩:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: dev-user-to-limited-pods
  namespace: default
subjects:
  - kind: User
    name: dev-user
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-limited-reader
  apiGroup: rbac.authorization.k8s.io

---

결론 요약

• 인가는 “인증된 주체가 무엇을 할 수 있나”를 결정한다.
• Kubernetes는 Node/ABAC/RBAC/Webhook 등의 인가 메커니즘을 제공한다.
• 실무 표준은 대개 Node Authorizer + RBAC (+ 필요 시 Webhook).
• RBAC는 Role(권한 규칙) + RoleBinding(대상 연결)로 구성된다.
• Role/RoleBinding은 네임스페이스 범위이며, 권한 검증은 kubectl auth can-i + --as로 빠르게 테스트한다.
• 필요하면 resourceNames로 특정 리소스만 허용할 수 있다.