K8S API Server

K8s API Server 개요

일단 API Server라고 한다면 우리가 클러스터와 상호작용하기 위한 모든 요청을 처리하는 핵심 컴포넌트라고 할 수 있다. 사용자가 kubectl 명령을 입력하거나, 클러스터 내의 Pod가 네트워크 요청을 보낼 때 모든 요청은 다 API Server로 들어가게 된다. 여기서 3단계 프로세스를 통해서 요청이 처리된다. 이 3단계 프로세스는 다 플러그인이라서 설치해서 쓰는 거다. (minikube나 k3s 에는 없다)

자 그림을 한 번 살펴보자.

Authentication

너 누구야? 를 확인하는 단계이다. 사용자나 Pod가 요청을 보낼 때, 자신이 누구인지를 증명해야 한다.

사용자: 아이디, 패스워드로 인증

Pod: ServiceAccount와 연결된 JWT 토큰을 통해 인증

Pod는 아이디,패스워드 이런 걸 입력할 수가 없잖아? 그래서 Service Account라는 리소스가 필요한 거다! 얘가 Pod랑 연결되어있다.

Authorization

너, 이 작업을 해도 되냐? 를 판단하는 단계이다. RBAC를 사용하여 요청자가 해당 리소스에 대해 요청한 작업을 할 권한이 있는지 확인한다.

• Role: 특정 네임스페이스 내에서 어떤 리소스를 어떻게 조작할 수 있는지를 정의한다.
• ClusterRole: 클러스터 전역에서 적용되는 권한이다.
• RoleBinding/ClusterRoleBinding: Role이나 ClusterRole을 사용자(ServiceAccount)와 연결한다.

Admission Control

요청이 올바르고, 필요한 정보를 다 가지고 있나? 를 확인하는 단계이다. 이 단계에서 리소스의 기본값을 설정하거나, 정책에 따라 요청을 거부할 수도 있다.

그래서,

이 3가지 3A를 통과하면 etcd까지 접근할 수 있게 된다. 이제 http 메서드와 비슷하게 동작하고, etcd에 Pod를 만들기만 하면 나머지는 쿠버네티스의 동작원리에 따라서 동작하게 된다.

ServiceAccount

Pod는 기본적으로 아이디, 패스워드 같은 신원 정보가 없다. 따라서 API Server와 상호작용하기 위해서 ServiceAccount라는 리소스를 사용한다.

ServiceAccount는 Pod가 API Server에 접근할 수 있는 인증 정보를 제공한다. Pod는 자신과 연결된 ServiceAccount를 사용해 API 요청을 보낼 수 있다. 이 ServiceAccount는 토큰을 통해서 API Server에 자신을 인증한다.

자 그러면 Pod랑은 어떻게 연결하냐? Pod의 spec.serviceAccountName 필드에 ServiceAccount이름을 명시하면 된다.

Role

role은 특정 네임스페이스 내에서 특정 리소스에 대해 수행할 수 있는 작업(verbs)을 정의하는 리소스이다.

위의 그림이 Role의 예시이다. 해당 yaml파일에서 봐야할 부분은 verbs, resources이다.

• verbs : 동작, 리소스에 대해 어떤 작업을 할 수 있는지 정의한다. (get, list, create, delete)
• resources: 어떤 리소스에 권한을 줄 건지 정의한다. (pod, service, configmap)

Role과 ServiceAccount 연결

Role은 Pod 또는 사용자가 특정 작업을 수행할 수 있도록 권한을 부여하기 위해 ServiceAccount와 연결된다.

왜 ServiceAccount와 연결하나?

Pod는 기본적으로 인증 정보가 없기 때문에 ServiceAccount를 통해 자신을 인증해야 한다고 햇다. 여기서 ServiceAccount는 Role을 할당받아, 특정 리소스에 대해 어떤 작업을 수행할 수 있는지 결정한다.

RoleBinding을 통해 연결

Role을 ServiceAccount에 연결하려면 RoleBinding이라는 리소스를 사용한다. 구성요소는 다음과 같다.

• subjects: 권한을 부여받는 대상 (ServiceAccount, 사용자, 그룹 )
• roleRef: 연결할 Role의 정보

RBAC(Role-Based-Access Control)

RBAC는 기본적으로 쿠버네티스에서 리소스 접근을 관리하기 위한 인증 및 권한 부여 메커니즘이다. 이를 통해 클러스터 내 리소스에 대해 어떤 사용자나 ServiceAccount가 어떤 작업을 수행할 수 있는지를 제어한다.

Role과 ClusterRole

특정 리소스에 대해 수행할 수 있는 작업을 정의한다.

• Role: 네임스페이스 내에서 리소스 접근 권한을 정의한다.
• ClusterRole: 클러스터 전역에서 리소스 접근 권한을 정의한다.

RoleBinding과 ClusterRoleBinding

특정 Role이나 ClusterRole을 사용자, 그룹 또는 Service Account에 연결한다.

• RoleBinding: 네임스페이스 내에서 Role과 사용자/그룹/서비스 계정을 연결한다.
• ClusterRoleBinding: 클러스터 전역에서 ClusterRole과 사용자/그룹/서비스 계정을 연결한다.

RBAC의 구성요소

1. Role: 어떤 리소스에 대해서 어떤 작업을 수행할 수 있을지 정의한다.
2. RoleBinding: Role을 특정 사용자나 서비스 계정에 연결한다.
3. ClusterRole: 클러스터 전체에서 리소스 접근 권한을 정의한다.
4. ClusterRoleBinding: CluterRole을 클러스터 전역 사용자나 그룹에 연결한다.

Service Account와 RBAC의 관계

먼저, Service Account는 Pod와 연결되어 API 서버와 통신할 때 인증 정보로 사용된다.

RBAC 작동 흐름

1. 사용자 요청: 사용자가 kubectl이나 다른 API 클라이언트를 통해 HTTP 요청을 보낸다.
2. Authentication: API 서버의 인증 플러그인을 통해 요청자가 누구인지 확인한다. 사용자 정보는 Http 헤더나 클라이언트 인증서로 전달된다.
3. Authorization: API 서버의 RBAC 플러그인을 통해 요청자가 해당 작업을 수행할 권한이 있는지 확인한다. Role/RoleBinding 또는 ClusterRole/ClusterRoleBinding을 확인한다.
4. Admission Control: 요청이 리소스를 생성, 수정, 삭제하는 경우, Admission Controller를 통해 요청을 검증하고 기본값을 추가하거나 수정할 수 있다.

RBAC 연결고리의 전체 흐름

자 그러면 Role, ServiceAccount, RoleBinding, 그리고 Pod 간의 관계를 정리해보자.

1. 관리자가 Role을 정의한다

특정 리소스에 대한 수행 가능한 작업을 관리자가 정의하게 된다. 뭐 예를 들면 Pod 생성 및 삭제? 이런게 있겟다.

1. Role을 ServiceAccount에 연결한다.

RoleBinding을 사용하여 Role을 ServiceAccount에 연결한다. RoleBinding은 Role과 ServiceAccount를 링크하여, 권한을 ServiceAccount에 부여한다.

1. Pod에 ServiceAccount를 연결한다.

Pod 스펙에다가 serviceAccountName 을 추가하여 특정 serviceAccount를 사용하도록 설정한다.

1. Pod가 API server와 상호작용한다.

Pod는 이제 자신의 serviceAccount를 사용해 API Server에 인증한다. ServiceAccount는 Role에 의해 허가된 작업만 수행 가능하다.

---

Summary about API Server

1. Authenticating the Client with Authentication Plugins (Auth N)

[역할]

API서버는 사용자의 요청을 처리하기 전에 요청자가 누구인지 확인한다.

[방법]

1. HTTP 헤더 검사: 요청의 http 헤더를 통해 사용자 정보를 확인한다.
2. 인증 플러그인을 사용하여 요청자가 적절히 인증되었는지 확인한다.
3. 인증 결과를 기반으로 사용자 정보를 다음 단계인(Authorization)으로 전달한다.

[결과]

요청자의 신원이 확인되었고, 다음 단계로 간다.

2. Authorizing the Client with Authorization Plugins (Auth Z)

[역할]

인증된 사용자가 요청한 작업을 수행할 권한이 있는지 확인한다.

[방법]

1. Authorization 플러그인이 요청 리소스와 작업 (CRUD?)를 확인한다.
2. 플러그인이 요청 작업이 허가되었는지를 결정한다.
3. 첫 번째 플러그인이 작업을 허용하면 다음 단계로 진행한다.

[예시]

사용자가 Pod를 생성하려고 할 때, 플러그인이 해당 사용자가 특정 네임스페이스에서 pod 생성 권한이 있는지 확인한다.

3. Validating and/or Modifying the Request with Admission Control Plugins

[역할]

요청이 유효한지 확인하고, 필요한 경우 요청을 수정하거나 거부한다.

[작동 방식]

1. 요청이 Create, Modify, Delete 작업인 경우에만 적용된다.
2. Admission Control 플러그인이 요청을 검증하거나 수정한다.
3. (요청에 누락된 기본값을 추가 / 잘못된 값을 수정 / 요청이 리소스 정책을 위반하면 거부)

[특징]

단순한 데이터 읽기 요청은 이 단계를 거치지 않는다.

4. Examples of Admission Control Plugins

[플러그인의 역할]

1. AlwaysPullImages: Pod의 이미지가 이미 캐시에 있더라도 항상 새로 가져오도록 강제한다.
2. ServiceAccount: Pod가 기본 서비스 계정을 사용하도록 설정한다.
3. NamespaceLifecycle: 삭제 중이거나 존재하지 않는 네임스페이스에 Pod가 생성되지 않도록 방지한다.
4. ResourceQuota: 네임스페이스 내에서 리소스(CPU, 메모리 등)의 사용량을 제한한다.

➡️ 클러스터의 리소스와 작업을 안정적이고 일관되게 관리한다!!!

5. Validating the Resource and Storing It Persistently

모든 검증 단계를 통과한 요청은 etcd에 영구 저장된다.

[결과]

리소스가 성공적으로 생성, 수정, 삭제되었다는 응답이 클라이언트에 반환된다.

K8s API Server 개요

일단 API Server라고 한다면 우리가 클러스터와 상호작용하기 위한 모든 요청을 처리하는 핵심 컴포넌트라고 할 수 있다. 사용자가 kubectl 명령을 입력하거나, 클러스터 내의 Pod가 네트워크 요청을 보낼 때 모든 요청은 다 API Server로 들어가게 된다. 여기서 3단계 프로세스를 통해서 요청이 처리된다. 이 3단계 프로세스는 다 플러그인이라서 설치해서 쓰는 거다. (minikube나 k3s 에는 없다)

자 그림을 한 번 살펴보자.

Authentication

너 누구야? 를 확인하는 단계이다. 사용자나 Pod가 요청을 보낼 때, 자신이 누구인지를 증명해야 한다.

사용자: 아이디, 패스워드로 인증

Pod: ServiceAccount와 연결된 JWT 토큰을 통해 인증

Pod는 아이디,패스워드 이런 걸 입력할 수가 없잖아? 그래서 Service Account라는 리소스가 필요한 거다! 얘가 Pod랑 연결되어있다.

Authorization

너, 이 작업을 해도 되냐? 를 판단하는 단계이다. RBAC를 사용하여 요청자가 해당 리소스에 대해 요청한 작업을 할 권한이 있는지 확인한다.

• Role: 특정 네임스페이스 내에서 어떤 리소스를 어떻게 조작할 수 있는지를 정의한다.
• ClusterRole: 클러스터 전역에서 적용되는 권한이다.
• RoleBinding/ClusterRoleBinding: Role이나 ClusterRole을 사용자(ServiceAccount)와 연결한다.

Admission Control

요청이 올바르고, 필요한 정보를 다 가지고 있나? 를 확인하는 단계이다. 이 단계에서 리소스의 기본값을 설정하거나, 정책에 따라 요청을 거부할 수도 있다.

그래서,

이 3가지 3A를 통과하면 etcd까지 접근할 수 있게 된다. 이제 http 메서드와 비슷하게 동작하고, etcd에 Pod를 만들기만 하면 나머지는 쿠버네티스의 동작원리에 따라서 동작하게 된다.

ServiceAccount

Pod는 기본적으로 아이디, 패스워드 같은 신원 정보가 없다. 따라서 API Server와 상호작용하기 위해서 ServiceAccount라는 리소스를 사용한다.

ServiceAccount는 Pod가 API Server에 접근할 수 있는 인증 정보를 제공한다. Pod는 자신과 연결된 ServiceAccount를 사용해 API 요청을 보낼 수 있다. 이 ServiceAccount는 토큰을 통해서 API Server에 자신을 인증한다.

자 그러면 Pod랑은 어떻게 연결하냐? Pod의 spec.serviceAccountName 필드에 ServiceAccount이름을 명시하면 된다.

Role

role은 특정 네임스페이스 내에서 특정 리소스에 대해 수행할 수 있는 작업(verbs)을 정의하는 리소스이다.

위의 그림이 Role의 예시이다. 해당 yaml파일에서 봐야할 부분은 verbs, resources이다.

• verbs : 동작, 리소스에 대해 어떤 작업을 할 수 있는지 정의한다. (get, list, create, delete)
• resources: 어떤 리소스에 권한을 줄 건지 정의한다. (pod, service, configmap)

Role과 ServiceAccount 연결

Role은 Pod 또는 사용자가 특정 작업을 수행할 수 있도록 권한을 부여하기 위해 ServiceAccount와 연결된다.

왜 ServiceAccount와 연결하나?

Pod는 기본적으로 인증 정보가 없기 때문에 ServiceAccount를 통해 자신을 인증해야 한다고 햇다. 여기서 ServiceAccount는 Role을 할당받아, 특정 리소스에 대해 어떤 작업을 수행할 수 있는지 결정한다.

RoleBinding을 통해 연결

Role을 ServiceAccount에 연결하려면 RoleBinding이라는 리소스를 사용한다. 구성요소는 다음과 같다.

• subjects: 권한을 부여받는 대상 (ServiceAccount, 사용자, 그룹 )
• roleRef: 연결할 Role의 정보

RBAC(Role-Based-Access Control)

RBAC는 기본적으로 쿠버네티스에서 리소스 접근을 관리하기 위한 인증 및 권한 부여 메커니즘이다. 이를 통해 클러스터 내 리소스에 대해 어떤 사용자나 ServiceAccount가 어떤 작업을 수행할 수 있는지를 제어한다.

Role과 ClusterRole

특정 리소스에 대해 수행할 수 있는 작업을 정의한다.

• Role: 네임스페이스 내에서 리소스 접근 권한을 정의한다.
• ClusterRole: 클러스터 전역에서 리소스 접근 권한을 정의한다.

RoleBinding과 ClusterRoleBinding

특정 Role이나 ClusterRole을 사용자, 그룹 또는 Service Account에 연결한다.

• RoleBinding: 네임스페이스 내에서 Role과 사용자/그룹/서비스 계정을 연결한다.
• ClusterRoleBinding: 클러스터 전역에서 ClusterRole과 사용자/그룹/서비스 계정을 연결한다.

RBAC의 구성요소

1. Role: 어떤 리소스에 대해서 어떤 작업을 수행할 수 있을지 정의한다.
2. RoleBinding: Role을 특정 사용자나 서비스 계정에 연결한다.
3. ClusterRole: 클러스터 전체에서 리소스 접근 권한을 정의한다.
4. ClusterRoleBinding: CluterRole을 클러스터 전역 사용자나 그룹에 연결한다.

Service Account와 RBAC의 관계

먼저, Service Account는 Pod와 연결되어 API 서버와 통신할 때 인증 정보로 사용된다.

RBAC 작동 흐름

1. 사용자 요청: 사용자가 kubectl이나 다른 API 클라이언트를 통해 HTTP 요청을 보낸다.
2. Authentication: API 서버의 인증 플러그인을 통해 요청자가 누구인지 확인한다. 사용자 정보는 Http 헤더나 클라이언트 인증서로 전달된다.
3. Authorization: API 서버의 RBAC 플러그인을 통해 요청자가 해당 작업을 수행할 권한이 있는지 확인한다. Role/RoleBinding 또는 ClusterRole/ClusterRoleBinding을 확인한다.
4. Admission Control: 요청이 리소스를 생성, 수정, 삭제하는 경우, Admission Controller를 통해 요청을 검증하고 기본값을 추가하거나 수정할 수 있다.

RBAC 연결고리의 전체 흐름

자 그러면 Role, ServiceAccount, RoleBinding, 그리고 Pod 간의 관계를 정리해보자.

1. 관리자가 Role을 정의한다

특정 리소스에 대한 수행 가능한 작업을 관리자가 정의하게 된다. 뭐 예를 들면 Pod 생성 및 삭제? 이런게 있겟다.

1. Role을 ServiceAccount에 연결한다.

RoleBinding을 사용하여 Role을 ServiceAccount에 연결한다. RoleBinding은 Role과 ServiceAccount를 링크하여, 권한을 ServiceAccount에 부여한다.

1. Pod에 ServiceAccount를 연결한다.

Pod 스펙에다가 serviceAccountName 을 추가하여 특정 serviceAccount를 사용하도록 설정한다.

1. Pod가 API server와 상호작용한다.

Pod는 이제 자신의 serviceAccount를 사용해 API Server에 인증한다. ServiceAccount는 Role에 의해 허가된 작업만 수행 가능하다.

---

Summary about API Server

1. Authenticating the Client with Authentication Plugins (Auth N)

[역할]

API서버는 사용자의 요청을 처리하기 전에 요청자가 누구인지 확인한다.

[방법]

1. HTTP 헤더 검사: 요청의 http 헤더를 통해 사용자 정보를 확인한다.
2. 인증 플러그인을 사용하여 요청자가 적절히 인증되었는지 확인한다.
3. 인증 결과를 기반으로 사용자 정보를 다음 단계인(Authorization)으로 전달한다.

[결과]

요청자의 신원이 확인되었고, 다음 단계로 간다.

2. Authorizing the Client with Authorization Plugins (Auth Z)

[역할]

인증된 사용자가 요청한 작업을 수행할 권한이 있는지 확인한다.

[방법]

1. Authorization 플러그인이 요청 리소스와 작업 (CRUD?)를 확인한다.
2. 플러그인이 요청 작업이 허가되었는지를 결정한다.
3. 첫 번째 플러그인이 작업을 허용하면 다음 단계로 진행한다.

[예시]

사용자가 Pod를 생성하려고 할 때, 플러그인이 해당 사용자가 특정 네임스페이스에서 pod 생성 권한이 있는지 확인한다.

3. Validating and/or Modifying the Request with Admission Control Plugins

[역할]

요청이 유효한지 확인하고, 필요한 경우 요청을 수정하거나 거부한다.

[작동 방식]

1. 요청이 Create, Modify, Delete 작업인 경우에만 적용된다.
2. Admission Control 플러그인이 요청을 검증하거나 수정한다.
3. (요청에 누락된 기본값을 추가 / 잘못된 값을 수정 / 요청이 리소스 정책을 위반하면 거부)

[특징]

단순한 데이터 읽기 요청은 이 단계를 거치지 않는다.

4. Examples of Admission Control Plugins

[플러그인의 역할]

1. AlwaysPullImages: Pod의 이미지가 이미 캐시에 있더라도 항상 새로 가져오도록 강제한다.
2. ServiceAccount: Pod가 기본 서비스 계정을 사용하도록 설정한다.
3. NamespaceLifecycle: 삭제 중이거나 존재하지 않는 네임스페이스에 Pod가 생성되지 않도록 방지한다.
4. ResourceQuota: 네임스페이스 내에서 리소스(CPU, 메모리 등)의 사용량을 제한한다.

➡️ 클러스터의 리소스와 작업을 안정적이고 일관되게 관리한다!!!

5. Validating the Resource and Storing It Persistently

모든 검증 단계를 통과한 요청은 etcd에 영구 저장된다.

[결과]

리소스가 성공적으로 생성, 수정, 삭제되었다는 응답이 클라이언트에 반환된다.