Overview
Kubernetes의 보안 및 접근 제어는 클러스터를 안전하게 운영하기 위해 반드시 이해해야 할 중요한 개념이다.
이번 글에서는 Kubernetes API Server의 동작 원리, API Group 구조, 그리고 클러스터 리소스에 대한 접근 권한을 제어하는 RBAC(Role-Based Access Control)까지 핵심 요소를 정리한다.
API Server는 Kubernetes의 컨트롤 플레인 중 핵심이며, 모든 요청의 입구이자 인증/인가 흐름의 중심이다.
API Group은 리소스를 체계적으로 분리하고 버전 관리를 돕는 역할을 하며, RBAC은 이들 리소스에 대한 권한을 세부적으로 설정할 수 있도록 한다.
실제 명령어 출력 예시와 YAML 구성까지 함께 다루기 때문에, 이론부터 실무 적용까지 한 번에 정리할 수 있는 실용적인 가이드가 될 것이다.
Kubernetes에 개념과 간단한 실습을 하고싶다면 아래의 링크를 참고하길 바란다.
2022.03.22 - [Container Orchestration/Kubernetes] - Kubernetes 개념과 Minikube 실습
Kubernetes 개념과 Minikube 실습
1. Kubernetes의 개념과 특징, 그리고 아키텍처 1) 개념 Kubernetes는 컨테이너를 쉽고 빠르게 배포/확장하고 관리를 자동화해주는 오픈소스 플랫폼이다. 2) 특징 Kubernetes는 Deployment, StatefulSets, DaemonSet, J
somaz.tistory.com
API Server란?
쿠버네티스(Kubernetes) API 서버는 쿠버네티스 클러스터의 중심 컴포넌트로, 사용자와 클러스터 간의 상호 작용을 가능하게 하는 역할을 한다. API 서버는 클러스터의 상태를 관리하고 제어하기 위한 주요 인터페이스를 제공한다. 이 서버를 통해 쿠버네티스 리소스를 생성, 수정, 삭제할 수 있으며, 클러스터의 전반적인 상태와 정보를 조회할 수 있다.
API 서버의 주요 기능
- RESTful API
- 쿠버네티스 API 서버는 RESTful API를 통해 클라이언트와 통신한다.
- 이를 통해 클러스터의 리소스를 생성, 조회, 수정, 삭제할 수 있다.
- 인증(Authentication)
- API 서버는 클러스터에 액세스하는 사용자와 요청을 인증한다.
- 이를 위해 다양한 인증 방법을 지원하며, 인증된 사용자는 자신의 권한에 맞게 리소스에 접근할 수 있다.
- 권한 부여(Authorization)
- 인증된 사용자의 요청에 대해 권한을 부여하고 검사하는 역할을 한다.
- 쿠버네티스는 Role-Based Access Control(RBAC) 및 Attribute-Based Access Control(ABAC) 등 다양한 권한 부여 방식을 지원한다.
- 승인(Admission)
- API 서버는 사용자 요청을 처리하기 전에 승인 단계를 거친다.
- 승인 컨트롤러는 요청이 클러스터에 영향을 미치기 전에 요청이 적절한지 검사하고, 필요한 경우 요청을 수정하거나 거부할 수 있다.
- API 오브젝트 저장 및 관리
- API 서버는 클러스터의 리소스를 etcd라는 분산 키-값 저장소에 저장하고 관리한다.
- etcd는 클러스터의 상태를 일관성있게 유지하고, 각 컴포넌트 사이에서 공유하기 위한 데이터 저장소이다.
쿠버네티스 API 서버는 클러스터의 컨트롤 플레인에 위치하며, 클러스터의 다양한 컴포넌트와 함께 작동하여 쿠버네티스의 강력한 기능을 제공한다. 사용자는 kubectl과 같은 도구를 통해 API 서버와 상호 작용할 수 있다.
API Group이란?
쿠버네티스 API 그룹(API Group)은 쿠버네티스 API 리소스들을 관리하기 위해 그룹화한 것이다.
API 그룹을 통해 관련된 리소스를 분류하고, 버전 관리를 효율적으로 수행할 수 있다.
쿠버네티스 API는 크게 Core Group과 Named Group으로 나뉜다.
Core Group
Core Group은 기본적인 쿠버네티스 리소스를 포함하는 그룹으로, API 그룹 이름이 공백 문자열("")로 지정된다.
이 그룹에는 파드(Pods), 서비스(Services), 레플리케이션컨트롤러(ReplicationControllers), 노드(Nodes), 네임스페이스(Namespaces) 등 쿠버네티스의 핵심 기능을 제공하는 리소스가 포함된다.
예를들어 Core Group의 'pods' 리소스에 대한 권한을 설정할 때 다음과 같이 작성한다.
apiGroups: [""]
resources: ["pods"]
Named Group
Named Group은 Core Group 외의 특정한 이름을 가진 API 그룹이다.
이 그룹에는 애플리케이션 관련 리소스, 보안 관련 리소스, 구성 관련 리소스, 그 외 다양한 확장 리소스 등이 포함될 수 있다. 대표적인 Named Group으로는 extensions, apps, networking.k8s.io, rbac.authorization.k8s.io 등이 있다.
예를 들어, apps API 그룹의 deployments 리소스에 대한 권한을 설정할 때 다음과 같이 작성한다.
apiGroups: ["apps"]
resources: ["deployments"]
API 그룹, 버전 및 리소스(GVR)는 HTTP 경로를 고유하게 정의한다.
쿠버네티스의 다양한 접근제어 방식
쿠버네티스에서는 RBAC(Role-Based Access Control) 외에도 다양한 접근 제어 방식이 제공된다.
Node Authorization
Node Authorization은 쿠버네티스 노드에 대한 접근을 제어한다. 이를 통해 특정 노드에 대한 권한을 획득한 사용자만 해당 노드에서 파드를 생성하거나 실행할 수 있다. Node Authorization은 kubelet 인증서를 기반으로 한다.
Attribute-Based Access Control (ABAC)
Attribute-Based Access Control은 객체의 특성(attribute)을 기반으로 접근을 제어한다. 예를 들어, 사용자가 특정 라벨(label)을 가지고 있거나, 특정 네임스페이스(namespace)에 속해 있는 경우에만 해당 객체에 접근할 수 있도록 제어할 수 있다.
Webhook Mode
Webhook Mode는 쿠버네티스 API 서버가 인증 및 권한 부여 요청을 외부 인증 시스템에 전달하고, 해당 시스템에서 인증 및 권한 부여를 수행한 뒤, 결과를 API 서버에 반환하여 접근을 제어하는 방식이다. 이를 통해 외부 인증 시스템을 이용하여 보다 복잡한 권한 제어를 수행할 수 있다.
Node Restriction
Node Restriction은 노드에서 실행되는 파드에 대한 권한을 제어한다. 예를 들어, 특정 노드에서만 파드를 실행하도록 설정하거나, 노드의 리소스 사용량을 제한하는 등의 제어를 수행할 수 있다.
이 외에도 쿠버네티스는 Network Policy를 통해 네트워크 트래픽에 대한 제어도 제공하고 있다. 이를 통해 파드 간의 트래픽을 제한하거나, 보안 그룹과 유사한 방식으로 파드에 대한 포트 제한 등을 설정할 수 있다.
RBAC(Role Based Access Control)란?
쿠버네티스의 RBAC (Role-Based Access Control)은 쿠버네티스 클러스터 내에서 리소스에 대한 접근 권한을 사용자나 그룹에게 부여하는 보안 메커니즘이다. RBAC을 통해 특정 사용자에게 필요한 최소한의 권한만 부여함으로써 클러스터의 리소스와 정보를 안전하게 보호할 수 있다.
쿠버네티스에서는 Role과 ClusterRole, RoleBinding과 ClusterRoleBinding 이렇게 네 가지 요소를 사용하여 RBAC을 구현한다.
Role
Role은 쿠버네티스의 특정 네임스페이스(namespace) 내에서 리소스에 대한 접근 권한을 정의하는 객체이다.
Role은 어떤 종류의 리소스에 대한 권한을 설정할지, 그리고 그 권한이 어떤 동작(예: get, list, create, update 등)을 포함하는지 명시한다.
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: gitlab-runner-role
# kubectl apply 할 때 적용할 namespace 지정
#namespace:
rules:
- apiGroups: ["extensions", "apps"]
resources: ["deployments"]
verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
- apiGroups: [""]
resources: ["pods","services","secrets","pods/exec", "serviceaccounts"]
verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
extensions 및 apps API 그룹에 속하는 deployments 리소스에 대한 권한
- get: 리소스 조회
- list: 리소스 목록 조회
- watch: 리소스 변경 사항 감시
- create: 리소스 생성
- update: 리소스 수정
- patch: 리소스 일부 수정
- delete: 리소스 삭제
core API 그룹 (apiGroups 필드에 빈 문자열 ""이 사용)에 속하는 리소스에 대한 권한
- pods, services, secrets, serviceaccounts: 위와 동일한 동작 권한
- pods/exec: 파드 내에서 실행 중인 컨테이너의 명령을 실행할 수 있는 권한
RoleBinding
RoleBinding은 Role에 정의된 권한을 사용자, 그룹, 또는 다른 서비스 계정에 연결하는 객체이다.
즉, RoleBinding을 통해 특정 사용자가 Role에 명시된 권한을 가지게 된다. RoleBinding은 특정 네임스페이스에만 국한되어 작동한다.
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
# kubectl apply 할 때 적용할 namespace 지정
#namespace:
name: gitlab-runner-role-binding
subjects:
- kind: ServiceAccount
name: default
# kubectl apply 할 때 적용할 namespace 지정
#namespace:
roleRef:
kind: Role
name: gitlab-runner-role
apiGroup: rbac.authorization.k8s.io- metadata
- RoleBinding의 이름(name)과 네임스페이스(namespace)를 정의한다.
- subjects
- RoleBinding에 연결할 대상을 지정한다. ServiceAccount'종류의 default 서비스 계정이 사용되었다.
- roleRef
- 연결할 Role을 참조한다. Role 종류의 gitlab-runner-role이 참조되었고, 이 Role은 rbac.authorization.k8s.io API 그룹에 속해 있다.
ClusterRole & ClusterRoleBinding
Role과 RoleBinding말고, 네임스페이스 범위를 넘어 전체 클러스터에 적용되는 권한을 부여할 땐 반드시 ClusterRole, ClusterRoleBinding을 사용해야 한다.
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: cluster-admin-readonly
rules:
- apiGroups: [""]
resources: ["pods", "services"]
verbs: ["get", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: readonly-binding
subjects:
- kind: User
name: alice
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: cluster-admin-readonly
apiGroup: rbac.authorization.k8s.io- 이 예시는 클러스터 전체 리소스에 대해 read-only 권한을 특정 사용자에게 부여하는 구조다.
접근제어 목록 확인
쿠버네티스를 설치할때 기아래와 같이 Node,RBAC 접근제어는 default로 들어가 있다.
RBAC CLI 확인
- Role
- Role binding
Roles 확인
$ k get roles -A
NAMESPACE NAME CREATED AT
build-image gitlab-runner-role 2022-05-02T15:13:30Z
ingress-nginx ingress-nginx 2022-05-02T12:24:06Z
ingress-nginx ingress-nginx-admission 2022-05-02T12:24:06Z
kube-public kubeadm:bootstrap-signer-clusterinfo 2022-05-02T11:46:26Z
kube-public system:controller:bootstrap-signer 2022-05-02T11:46:25Z
kube-system extension-apiserver-authentication-reader 2022-05-02T11:46:25Z
kube-system kube-proxy 2022-05-02T11:46:27Z
kube-system kubeadm:kubeadm-certs 2022-05-02T11:46:26Z
kube-system kubeadm:kubelet-config-1.23 2022-05-02T11:46:25Z
kube-system kubeadm:nodes-kubeadm-config 2022-05-02T11:46:25Z
kube-system system::leader-locking-kube-controller-manager 2022-05-02T11:46:25Z
kube-system system::leader-locking-kube-scheduler 2022-05-02T11:46:25Z
kube-system system:controller:bootstrap-signer 2022-05-02T11:46:25Z
kube-system system:controller:cloud-provider 2022-05-02T11:46:25Z
kube-system system:controller:token-cleaner 2022-05-02T11:46:25Z
kubernetes-dashboard kubernetes-dashboard 2022-05-02T12:02:39Z
Rolebindings 확인
$ k get rolebindings -A
NAMESPACE NAME ROLE AGE
build-image gitlab-runner-role-binding Role/gitlab-runner-role 349d
ingress-nginx ingress-nginx Role/ingress-nginx 349d
ingress-nginx ingress-nginx-admission Role/ingress-nginx-admission 349d
kube-public kubeadm:bootstrap-signer-clusterinfo Role/kubeadm:bootstrap-signer-clusterinfo 349d
kube-public system:controller:bootstrap-signer Role/system:controller:bootstrap-signer 349d
kube-system kube-proxy Role/kube-proxy 349d
kube-system kubeadm:kubeadm-certs Role/kubeadm:kubeadm-certs 349d
kube-system kubeadm:kubelet-config-1.23 Role/kubeadm:kubelet-config-1.23 349d
kube-system kubeadm:nodes-kubeadm-config Role/kubeadm:nodes-kubeadm-config 349d
kube-system system::extension-apiserver-authentication-reader Role/extension-apiserver-authentication-reader 349d
kube-system system::leader-locking-kube-controller-manager Role/system::leader-locking-kube-controller-manager 349d
kube-system system::leader-locking-kube-scheduler Role/system::leader-locking-kube-scheduler 349d
kube-system system:controller:bootstrap-signer Role/system:controller:bootstrap-signer 349d
kube-system system:controller:cloud-provider Role/system:controller:cloud-provider 349d
kube-system system:controller:token-cleaner Role/system:controller:token-cleaner 349d
kubernetes-dashboard kubernetes-dashboard Role/kubernetes-dashboard 349d
kubectl auth can-i 명령어 소개
`kubectl auth can-i` 명령은 현재 사용자 또는 서비스 계정이 특정 작업을 수행할 수 있는지 여부를 빠르게 확인하는 데 유용하다.
kubectl auth can-i create pods --namespace=default
kubectl auth can-i delete deployments --as=system:serviceaccount:dev:gitlab-runner- 이러한 명령을 사용하면 설정된 RBAC 권한을 빠르게 테스트하고 디버깅할 수 있다.
마무리
Kubernetes의 API Server, API Group, 그리고 RBAC은 클러스터 운영의 보안과 관리 측면에서 가장 기본적이면서도 중요한 구성 요소이다.
API Server는 모든 요청의 관문으로, 인증(Authentication), 인가(Authorization), 승인(Admission)을 통해 클러스터 접근을 제어한다.
API Group은 리소스를 논리적으로 그룹화하여 체계적인 접근 제어와 버전 관리를 돕는다.
RBAC은 사용자/서비스 계정에게 최소 권한 원칙에 따라 필요한 리소스만 접근할 수 있게 해주며, 클러스터 보안의 중심이다.
kubectl CLI를 통해 실시간으로 권한 상태를 조회하고, Role/RoleBinding 구성을 관리하는 습관을 들이면 클러스터 보안 및 운영 효율성이 대폭 향상된다.
생산 환경에서는 실수로 과도한 권한이 부여되지 않도록 주의하고, 서비스 계정과 네임스페이스를 전략적으로 활용하는 것이 중요하다.
Reference
Kubernetes RBAC 개념 정리 - opennaru 슬라이드
Kubernetes 공식 문서 - Using RBAC Authorization
'Container Orchestration > Kubernetes' 카테고리의 다른 글
| Kubernetes Resources(쿠버네티스 리소스) (0) | 2023.05.02 |
|---|---|
| Kubernetes 플러그인 매니저 Krew란? (0) | 2023.04.30 |
| K8S 인증서 10년 만기 생성 방법 (2) | 2022.09.23 |
| kubectl 명령어 정리 (0) | 2022.08.10 |
| Kubernetes Ingress란? (클러스터 외부 트래픽 관리) (0) | 2022.08.08 |