Overview
오늘은 Kubernets API Server, Group 그리고 RBAC 에 대해서 공부해보려고 한다.
Kubernetes에 개념과 간단한 실습을 하고싶다면 아래의 링크를 참고하길 바란다.
2022.03.22 - [Container Orchestration/Kubernetes] - Kubernetes 개념과 Minikube 실습
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 그룹에 속해 있다.
접근제어 목록 확인
쿠버네티스를 설치할때 기아래와 같이 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
Reference
'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 |
Ingress(인그레스) (0) | 2022.08.08 |