RBAC 권한 부여

소개

Kubernetes 에서는 일반적으로 RBAC(Role-Based Access Control, 역할 기반 액세스 제어) 을 사용하여 권한을 관리합니다.

사용자 (User): 직원 (예: "Jane").
Role: 특정 액세스 권한이 있는 출입 카드(예: "서버실에 들어갈 수 있음", "문서를 읽을 수 있음").
RoleBinding: 직원에게 출입 카드를 주는 작업입니다.

클러스터 액세스는 인증만으로 끝나지 않기 때문에 RBAC 가 중요합니다. 사용자의 신원이 확인된 후에도 시스템은 해당 사용자가 어떤 작업을 수행할 수 있는지 결정해야 합니다.

이 실습에서는 보안 책임자 역할을 수행합니다.

사물을 보기만 하고 변경할 수는 없는 "방문자 출입증"(Role) 을 생성합니다.
이 출입증을 jane이라는 사용자에게 할당합니다.
Jane 이 클러스터를 둘러볼 수는 있지만 무언가를 변경하려 하면 거부되는지 확인합니다.

Role 정의

먼저 권한 집합을 생성합니다. 여기서는 "읽기 전용" Role 을 사용합니다. 이 Role 은 Pod 를 list 및 get(읽기) 할 수 있게 하지만, Pod 를 create하거나 delete할 수는 없게 합니다.

RBAC 는 Kubernetes 의 인증 (authentication) 이 아니라 권한 부여 (authorization) 입니다. 인증은 "당신은 누구입니까?"라는 질문에 답하고, 권한 부여는 "무엇을 할 수 있습니까?"라는 질문에 답합니다. 이 실습에서는 특정 리소스 유형에 대해 허용되는 작업을 verb로 명시하여 두 번째 질문을 다룹니다.

role.yaml이라는 파일을 생성합니다.

nano role.yaml

다음 YAML 을 붙여 넣습니다. 이 정의는 "pods"에 대해 "get", "watch", "list" 작업을 수행할 수 있는 Role 을 생성합니다.

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-reader
rules:
  - apiGroups: [""] ## "" indicates the core API group
    resources: ["pods"]
    verbs: ["get", "watch", "list"]

저장하고 종료합니다 (Ctrl+X, Y, Enter).

이제 다음 명령으로 이 출입 카드를 클러스터에 적용합니다.

kubectl apply -f role.yaml

Role 이 생성되었는지 확인합니다.

kubectl get roles

출력에 pod-reader가 표시되어야 합니다.

Role 바인딩

이제 출입 카드 (pod-reader) 와 직원 (jane) 이 준비되었습니다. 하지만 아직 Jane 에게 출입 카드를 주지는 않았습니다. 둘을 연결하려면 RoleBinding이 필요합니다.

Role은 그 자체로는 어떤 권한도 부여하지 않습니다. 반드시 바인딩에서 참조해야 합니다. 이러한 분리는 의도적으로 설계되었습니다. 관리자는 재사용 가능한 권한 묶음을 한 번만 정의한 다음, 필요에 따라 여러 사용자, 그룹 또는 서비스 계정에 연결할 수 있습니다.

rolebinding.yaml이라는 파일을 생성합니다.

nano rolebinding.yaml

다음 내용을 붙여 넣습니다. 이 내용은 "pod-reader Role 을 jane 사용자에게 바인딩한다"는 의미입니다.

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: default
subjects:
  - kind: User
    name: jane ## The employee
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader ## The key card
  apiGroup: rbac.authorization.k8s.io

저장하고 종료합니다 (Ctrl+X, Y, Enter).

다음 명령으로 바인딩을 적용합니다.

kubectl apply -f rolebinding.yaml

이제 Jane 에게 default 네임스페이스에 대한 읽기 전용 액세스 권한을 공식적으로 부여했습니다.

액세스 권한 확인

권한을 어떻게 테스트할까요? Jane 으로 로그아웃한 다음 다시 로그인할 필요는 없습니다. Kubernetes 에서는 --as 플래그를 사용하여 사용자를 "가장(impersonate)"하고 권한을 테스트할 수 있습니다.

이는 실용적인 관리 기법입니다. 실제 사용자나 자동화 계정에 액세스 권한을 부여하기 전에 사용자의 신원을 시뮬레이션하면 권한을 훨씬 안전하게 확인할 수 있습니다. 클러스터에 불필요한 부작용을 만들지 않고 의도한 권한이 적용되었는지 검증할 수 있습니다.

먼저 Jane 이 Pod 를 나열할 수 있는지 확인합니다.

kubectl auth can-i list pods --as jane

출력은 yes여야 합니다.

특정 Pod 의 세부 정보를 가져올 수 있는지도 확인할 수 있습니다.

kubectl auth can-i get pods --as jane

이 명령의 출력도 yes여야 합니다.

이 결과는 RoleBinding 이 정상적으로 작동한다는 뜻입니다. 출입 카드가 출입 통제기에 인식된 것입니다.

제한 사항 확인

보안은 할 수 없는 작업도 관리하는 것입니다. Jane 에게는 pod-reader Role 만 있으므로 클러스터를 변경하는 작업은 엄격하게 금지되어야 합니다.

이는 최소 권한 (least privilege) 원칙을 실제로 적용한 예입니다. 광범위한 액세스 권한을 먼저 부여하고 사용자가 주의해서 행동하기를 기대하는 대신, 작업에 필요한 최소 권한으로 시작한 뒤 실제 운영상 필요할 때만 권한을 확대합니다.

Jane 이 Pod 를 생성할 수 있는지 확인합니다.

kubectl auth can-i create pods --as jane

출력은 no여야 합니다.

Jane 이 Pod 를 삭제할 수 있는지도 확인합니다.

kubectl auth can-i delete pods --as jane

출력은 no여야 합니다.

Jane 이 실제로 이러한 명령을 실행하려 하면 API 서버는 "Forbidden" 오류와 함께 요청을 거부합니다. 이를 통해 클러스터가 안전하게 보호되고 있으며 최소 권한 (Least Privilege) 원칙을 따르고 있음을 확인할 수 있습니다.

요약

이 실습에서는 RBAC 를 사용하여 클러스터를 보호했습니다.

다음 작업을 완료했습니다.

제한된 읽기 전용 권한을 가진 Role("출입 카드") 을 생성했습니다.
해당 출입 카드를 jane 사용자에게 제공하는 RoleBinding을 생성했습니다.
jane이 사물을 볼 수는 있지만 변경할 수는 없음을 확인했습니다.

이는 Kubernetes 에서 여러 사용자의 보안을 관리하는 기본 토대입니다. 모든 사용자에게 전체 관리자 권한을 부여하지 마세요!