kubectl - 명령어를 실행하거나 쿠버네티스 클러스터를 관리하기 위해 사용하는 주된 CLI 도구.
- JSONPath - kubectl에서 JSONPath 표현을 사용하기 위한 문법 가이드.
kubeadm - 안정적인 쿠버네티스 클러스터를 쉽게 프로비전하기 위한 CLI 도구.

컴포넌트

kubelet - 각 노드에서 구동되는 주요한 에이전트. kubelet은 PodSpecs 집합을 가지며 기술된 컨테이너가 구동되고 있는지, 정상 작동하는지를 보장한다.
kube-apiserver - 파드, 서비스, 레플리케이션 컨트롤러와 같은 API 오브젝트에 대한 검증과 구성을 수행하는 REST API.
kube-controller-manager - 쿠버네티스에 탑재된 핵심 제어 루프를 포함하는 데몬.
kube-proxy - 간단한 TCP/UDP 스트림 포워딩이나 백-엔드 집합에 걸쳐서 라운드-로빈 TCP/UDP 포워딩을 할 수 있다.
kube-scheduler - 가용성, 성능 및 용량을 관리하는 스케줄러.
- kube-scheduler 정책
- kube-scheduler 프로파일
컨트롤 플레인과 워커 노드에서 꼭 열어야 하는 포트와 프로토콜 리스트

API 설정

이 섹션은 쿠버네티스 구성요소 또는 도구를 환경설정하는 데에 사용되는 "미발표된" API를 다룬다. 이 API들은 사용자나 관리자가 클러스터를 사용/관리하는 데에 중요하지만, 이들 API의 대부분은 아직 API 서버가 제공하지 않는다.

kubeadm을 위한 API 설정

설계 문서

쿠버네티스 기능에 대한 설계 문서의 아카이브. 쿠버네티스 아키텍처와 쿠버네티스 디자인 개요부터 읽어보는 것이 좋다.

1 - 용어집

2 - API 개요

이 섹션은 쿠버네티스 API에 대한 참조 정보를 제공한다.

REST API는 쿠버네티스의 근본적인 구조이다. 모든 조작, 컴포넌트 간의 통신과 외부 사용자의 명령은 API 서버에서 처리할 수 있는 REST API 호출이다. 따라서, 쿠버네티스 플랫폼 안의 모든 것은 API 오브젝트로 취급되고, API에 상응하는 항목이 있다.

쿠버네티스 API 참조는 쿠버네티스 버전 v1.31에 대한 API가 나열되어 있다.

일반적인 배경 정보를 보려면, 쿠버네티스 API를 참고한다. 쿠버네티스 API에 대한 접근 제어는 클라이언트가 쿠버네티스 API 서버에 인증하는 방법과 요청이 승인되는 방법을 설명한다.

API 버전 규칙

JSON과 Protobuf 직렬화 스키마 모두 스키마 변경에 대해서 동일한 가이드라인을 따른다. 이후 설명에서는 이 형식 모두를 다룬다.

API 버전 규칙과 소프트웨어 버전 규칙은 간접적으로 연관된다. API와 릴리스 버전 부여에 관한 제안에는 API 버전 규칙과 소프트웨어 버전 규칙 간의 관계가 기술되어 있다.

API 버전의 차이는 수준의 안정성과 지원의 차이를 나타낸다. API 변경 문서에서 각 수준의 기준에 대한 더 많은 정보를 찾을 수 있다.

아래는 각 수준의 기준에 대한 요약이다.

알파(Alpha):
- 버전 이름에 alpha가 포함된다(예: v1alpha1).
- 빌트인 알파 API 버전은 기본적으로 활성화되지 않으며, 활성화하기 위해서는 kube-apiserver 설정에 반드시 명시해야 한다.
- 버그가 있을 수도 있다. 이 기능을 활성화하면 버그에 노출될 수 있다.
- 알파 API에 대한 기술 지원이 언제든 공지 없이 중단될 수 있다.
- 다음 소프트웨어를 릴리스할 때 공지 없이 API의 호환성이 깨지는 방식으로 변경될 수 있다.
- 버그에 대한 위험이 높고 장기간 지원되지 않으므로 단기간 테스트 용도의 클러스터에서만 사용하기를 권장한다.
베타(Beta):
- 버전 이름에 beta가 포함된다(예: v2beta3).
- 빌트인 베타 API 버전은 기본적으로 활성화되지 않으며, 활성화하기 위해서는 kube-apiserver 설정에 반드시 명시해야 한다. (예외사항 쿠버네티스 1.22 버전 이전의 베타 API들은 기본적으로 활성화되어 있다.)
- 빌트인 베타 API 버전이 더 이상 지원되지 않기까지는 9달 또는 3번의 마이너 릴리스(둘 중 더 긴 것을 기준으로 함)가 걸린다. 그리고 지원되지 않은 시점에서 제거되기까지는 다시 9달 또는 3번의 마이너 릴리스(둘 중 더 긴 것을 기준으로 함)가 걸린다.
- 코드가 잘 테스트 되었다. 이 기능을 활성화해도 안전하다.
- 구체적인 내용이 바뀔 수는 있지만, 전반적인 기능에 대한 기술 지원이 중단되지 않는다.
- 오브젝트에 대한 스키마나 문법이 다음 베타 또는 안정화 API 버전에서 호환되지 않는 방식으로 바뀔 수도 있다. 이런 경우, 다음 버전으로 이관할 수 있는 가이드가 제공된다. 다음 베타 또는 안정화 API 버전을 적용하는 것은 API 오브젝트의 편집 또는 재생성이 필요할 수도 있으며, 그렇게 쉬운 일만은 아닐 것이다. 이 기능에 의존하고 있는 애플리케이션은 다운타임이 필요할 수도 있다.
- 이 소프트웨어는 프로덕션 용도로 권장하지 않는다. 이후 여러 버전에서 호환되지 않는 변경 사항이 적용될 수 있다. 베타 API 버전이 더 이상 지원되지 않는 경우, 후속 베타 또는 안정화 API 버전으로 전환하기 위해서는 베타 API 버전을 사용해야 한다.
참고:
베타 기능을 사용해보고 피드백을 제공하자. 기능이 베타 수준을 벗어난 이후에는 실질적으로 더 많은 변경이 어렵다.
안정화(Stable):
- 버전 이름이 vX이고 X 는 정수다.
- 안정화된 API 버전은 이후의 모든 쿠버네티스 메이저 버전에서 사용 가능하며, 현재로써 쿠버네티스 메이저 버전에서 안정화된 API를 제거하려는 계획은 없다.

API 그룹

API 그룹은 쿠버네티스 API를 더 쉽게 확장할 수 있도록 해 준다. API 그룹은 REST 경로와 직렬화된 오브젝트의 apiVersion 필드에 명시된다.

쿠버네티스에는 다음과 같은 다양한 API 그룹이 있다.

핵심 (또는 레거시 라고 불리는) 그룹은 REST 경로 /api/v1에 있다. 핵심 그룹은 apiVersion 필드의 일부로 명시되지 않는다. 예를 들어, apiVersion: v1 과 같다.
이름이 있는 그룹은 REST 경로 /apis/$GROUP_NAME/$VERSION에 있으며 apiVersion: $GROUP_NAME/$VERSION을 사용한다(예를 들어, apiVersion: batch/v1). 지원되는 API 그룹 전체의 목록은 쿠버네티스 API 참조 문서에서 확인할 수 있다.

API 그룹 활성화 또는 비활성화

특정 리소스 및 API 그룹은 기본적으로 활성화된다. API 서버에서 --runtime-config 를 설정하여 활성화 또는 비활성화할 수 있다. --runtime-config 플래그는 API 서버의 런타임 구성을 설명하는 쉼표로 구분된 <key>=<value> 쌍을 허용한다. 만약 =<value> 부분을 생략하면, =true 가 명시된 것처럼 취급한다. 예를 들면, 다음과 같다.

batch/v1 을 비활성화하려면, --runtime-config=batch/v1=false 로 설정
batch/v2alpha1 을 활성화하려면, --runtime-config=batch/v2alpha1 으로 설정
예를 들어 storage.k8s.io/v1beta1/csistoragecapacities와 같이 특정 버전의 API를 활성화하려면, --runtime-config=storage.k8s.io/v1beta1/csistoragecapacities와 같이 설정

참고:

그룹이나 리소스를 활성화 또는 비활성화하려면, apiserver와 controller-manager를 재시작하여 --runtime-config 변경을 반영해야 한다.

지속성

쿠버네티스는 etcd에 기록하여 API 리소스 측면에서 직렬화된 상태를 저장한다.

다음 내용

API 규칙에 대해 자세히 알아보기
애그리게이터(aggregator)에 대한 디자인 문서 읽기

2.1 - 클라이언트 라이브러리

이 페이지는 다양한 프로그래밍 언어에서 쿠버네티스 API를 사용하기 위한 클라이언트 라이브러리에 대한 개요를 포함하고 있다.

쿠버네티스 REST API를 사용해 애플리케이션을 작성하기 위해 API 호출 또는 요청/응답 타입을 직접 구현할 필요는 없다. 사용하고 있는 프로그래밍 언어를 위한 클라이언트 라이브러리를 사용하면 된다.

클라이언트 라이브러리는 대체로 인증과 같은 공통의 태스크를 처리한다. 대부분의 클라이언트 라이브러리들은 API 클라이언트가 쿠버네티스 클러스터 내부에서 동작하는 경우 인증 또는 kubeconfig 파일 포맷을 통해 자격증명과 API 서버 주소를 읽을 수 있게 쿠버네티스 서비스 어카운트를 발견하고 사용할 수 있다.

공식적으로 지원되는 쿠버네티스 클라이언트 라이브러리

다음의 클라이언트 라이브러리들은 쿠버네티스 SIG API Machinery에서 공식적으로 관리된다.

언어	클라이언트 라이브러리	예제 프로그램
C	github.com/kubernetes-client/c	둘러보기
dotnet	github.com/kubernetes-client/csharp	둘러보기
Go	github.com/kubernetes/client-go/	둘러보기
Haskell	github.com/kubernetes-client/haskell	둘러보기
Java	github.com/kubernetes-client/java	둘러보기
JavaScript	github.com/kubernetes-client/javascript	둘러보기
Perl	github.com/kubernetes-client/perl/	둘러보기
Python	github.com/kubernetes-client/python/	둘러보기
Ruby	github.com/kubernetes-client/ruby/	둘러보기

커뮤니티에 의해 관리되는 클라이언트 라이브러리

참고: 이 섹션은 쿠버네티스에 필요한 기능을 제공하는 써드파티 프로젝트와 관련이 있다. 쿠버네티스 프로젝트 작성자는 써드파티 프로젝트에 책임이 없다. 이 페이지는 CNCF 웹사이트 가이드라인에 따라 프로젝트를 알파벳 순으로 나열한다. 이 목록에 프로젝트를 추가하려면 변경사항을 제출하기 전에 콘텐츠 가이드를 읽어본다.

다음의 쿠버네티스 API 클라이언트 라이브러리들은 쿠버네티스 팀이 아닌 각각의 저자들이 제공하고 관리한다.

언어	클라이언트 라이브러리
Clojure	github.com/yanatan16/clj-kubernetes-api
DotNet	github.com/tonnyeremin/kubernetes_gen
DotNet (RestSharp)	github.com/masroorhasan/Kubernetes.DotNet
Elixir	github.com/obmarg/kazan
Elixir	github.com/coryodaniel/k8s
Go	github.com/ericchiang/k8s
Java (OSGi)	bitbucket.org/amdatulabs/amdatu-kubernetes
Java (Fabric8, OSGi)	github.com/fabric8io/kubernetes-client
Java	github.com/manusa/yakc
Lisp	github.com/brendandburns/cl-k8s
Lisp	github.com/xh4/cube
Node.js (TypeScript)	github.com/Goyoo/node-k8s-client
Node.js	github.com/ajpauwels/easy-k8s
Node.js	github.com/godaddy/kubernetes-client
Node.js	github.com/tenxcloud/node-kubernetes-client
Perl	metacpan.org/pod/Net::Kubernetes
PHP	github.com/allansun/kubernetes-php-client
PHP	github.com/maclof/kubernetes-client
PHP	github.com/travisghansen/kubernetes-client-php
PHP	github.com/renoki-co/php-k8s
Python	github.com/fiaas/k8s
Python	github.com/gtsystem/lightkube
Python	github.com/mnubo/kubernetes-py
Python	github.com/tomplus/kubernetes_asyncio
Python	github.com/Frankkkkk/pykorm
Ruby	github.com/abonas/kubeclient
Ruby	github.com/k8s-ruby/k8s-ruby
Ruby	github.com/kontena/k8s-client
Rust	github.com/clux/kube-rs
Rust	github.com/ynqa/kubernetes-rust
Scala	github.com/hagay3/skuber
Scala	github.com/hnaderi/scala-k8s
Scala	github.com/joan38/kubernetes-client
Swift	github.com/swiftkube/client

2.2 - 쿠버네티스 API 헬스(health) 엔드포인트

쿠버네티스 API 서버는 현재 상태를 나타내는 API 엔드포인트를 제공한다. 이 페이지에서는 API 엔드포인트들에 대해 설명하고 이를 사용하는 방법을 다룬다.

헬스를 위한 API 엔드포인트

쿠버네티스 API 서버는 현재 상태를 나타내는 세 가지 API 엔드포인트(healthz, livez 와 readyz)를 제공한다. healthz 엔드포인트는 사용 중단(deprecated)됐으며 (쿠버네티스 v1.16 버전 이후), 대신 보다 구체적인 livez 와 readyz 엔드포인트를 사용해야 한다. livez 엔드포인트는 --livez-grace-period 플래그 옵션을 사용하여 시작 대기 시간을 지정할 수 있다. /readyz 엔드포인트는 --shutdown-delay-duration 플래그 옵션을 사용하여 정상적(graceful)으로 셧다운할 수 있다. API 서버의 healthz/livez/readyz 를 사용하는 머신은 HTTP 상태 코드에 의존해야 한다. 상태 코드 200은 호출된 엔드포인트에 따라 API 서버의 healthy/live/ready 상태를 나타낸다. 아래 표시된 더 자세한 옵션은 운영자가 클러스터를 디버깅하거나 특정 API 서버의 상태를 이해하는 데 사용할 수 있다.

다음의 예시는 헬스 API 엔드포인트와 상호 작용할 수 있는 방법을 보여준다.

모든 엔드포인트에 대해, verbose 파라미터를 사용하여 검사 항목과 상태를 출력할 수 있다. 이는 운영자가 머신 사용을 위한 것이 아닌, API 서버의 현재 상태를 디버깅하는데 유용하다.

curl -k https://localhost:6443/livez?verbose

인증을 사용하는 원격 호스트에서 사용할 경우에는 다음과 같이 수행한다.

kubectl get --raw='/readyz?verbose'

출력은 다음과 같다.

[+]ping ok
[+]log ok
[+]etcd ok
[+]poststarthook/start-kube-apiserver-admission-initializer ok
[+]poststarthook/generic-apiserver-start-informers ok
[+]poststarthook/start-apiextensions-informers ok
[+]poststarthook/start-apiextensions-controllers ok
[+]poststarthook/crd-informer-synced ok
[+]poststarthook/bootstrap-controller ok
[+]poststarthook/rbac/bootstrap-roles ok
[+]poststarthook/scheduling/bootstrap-system-priority-classes ok
[+]poststarthook/start-cluster-authentication-info-controller ok
[+]poststarthook/start-kube-aggregator-informers ok
[+]poststarthook/apiservice-registration-controller ok
[+]poststarthook/apiservice-status-available-controller ok
[+]poststarthook/kube-apiserver-autoregistration ok
[+]autoregister-completion ok
[+]poststarthook/apiservice-openapi-controller ok
healthz check passed

또한 쿠버네티스 API 서버는 특정 체크를 제외할 수 있다. 쿼리 파라미터는 다음 예와 같이 조합될 수 있다.

curl -k 'https://localhost:6443/readyz?verbose&exclude=etcd'

출력에서 etcd 체크가 제외된 것을 보여준다.

[+]ping ok
[+]log ok
[+]etcd excluded: ok
[+]poststarthook/start-kube-apiserver-admission-initializer ok
[+]poststarthook/generic-apiserver-start-informers ok
[+]poststarthook/start-apiextensions-informers ok
[+]poststarthook/start-apiextensions-controllers ok
[+]poststarthook/crd-informer-synced ok
[+]poststarthook/bootstrap-controller ok
[+]poststarthook/rbac/bootstrap-roles ok
[+]poststarthook/scheduling/bootstrap-system-priority-classes ok
[+]poststarthook/start-cluster-authentication-info-controller ok
[+]poststarthook/start-kube-aggregator-informers ok
[+]poststarthook/apiservice-registration-controller ok
[+]poststarthook/apiservice-status-available-controller ok
[+]poststarthook/kube-apiserver-autoregistration ok
[+]autoregister-completion ok
[+]poststarthook/apiservice-openapi-controller ok
[+]shutdown ok
healthz check passed

개별 헬스 체크

기능 상태: Kubernetes v1.31 [alpha]

각 개별 헬스 체크는 HTTP 엔드포인트를 노출하며 개별적으로 체크할 수 있다. 개별 체크를 위한 스키마는 /livez/<healthcheck-name> 이고, 여기서 livez 와 readyz 는 API 서버의 활성 상태 또는 준비 상태인지를 확인할 때 사용한다. <healthcheck-name> 경로 위에서 설명한 verbose 플래그를 사용해서 찾을 수 있고, [+] 와 ok 사이의 경로를 사용한다. 이러한 개별 헬스 체크는 머신에서 사용되서는 안되며, 운영자가 시스템의 현재 상태를 디버깅하는데 유용하다.

curl -k https://localhost:6443/livez/etcd

3 - API 접근 제어

쿠버네티스가 API 접근을 구현 및 제어하는 방법에 대한 자세한 내용은 쿠버네티스 API에 대한 접근 제어를 참고한다.

참조 문헌

인증
- 부트스트랩 토큰 인증
승인 컨트롤러
- 동적 승인 제어
인가
인증서 서명 요청
- CSR 승인과 인증서 서명을 포함함
서비스 어카운트
- 개발자 가이드
- 관리
kubelet 인증과 인가
- kubelet TLS 부트스트래핑을 포함함

3.1 - 부트스트랩 토큰을 사용한 인증

기능 상태: Kubernetes v1.18 [stable]

부트스트랩 토큰은 새 클러스터를 만들거나 새 노드를 기존 클러스터에 결합할 때 사용되는 간단한 전달자 토큰이다. kubeadm을 지원하도록 구축되었지만 kubeadm 없이 클러스터를 시작하려는 사용자를 위해 다른 컨텍스트에서 사용할 수 있다. 또한 RBAC 정책을 통해 Kubelet TLS 부트스트래핑 시스템과 함께 동작하도록 구축되었다.

부트스트랩 토큰 개요

부트스트랩 토큰은 kube-system 네임스페이스에 있는 특정 유형(bootstrap.kubernetes.io/token)의 시크릿(Secret)으로 정의된다. API 서버의 부트스트랩 인증자가 이러한 시크릿을 읽는다. 만료된 토큰은 컨트롤러 관리자가 TokenCleaner 컨트롤러로 제거한다. 토큰은 BootstrapSigner 컨트롤러를 통해 "discovery" 프로세스에 사용되는 특정 컨피그맵(ConfigMap)에 대한 서명을 만드는 데도 사용된다.

토큰 형식

부트스트랩 토큰은 abcdef.0123456789abcdef 형식을 취한다. 더 공식적으로는 정규식 [a-z0-9]{6}\.[a-z0-9]{16} 와 일치해야 한다.

토큰의 첫 번째 부분은 "Token ID" 이며 공개 정보로 간주된다. 인증에 사용하는 시크릿의 일부를 노출하지 않고 토큰을 참조할 때 사용한다. 두 번째 부분은 "Token Secret"이며 신뢰할 수 있는 당사자와만 공유해야 한다.

부트스트랩 토큰 인증 활성화

API 서버에서 다음 플래그를 사용하여 부트스트랩 토큰 인증자를 활성화할 수 있다.

--enable-bootstrap-token-auth

활성화되면 부트스트랩 토큰을 API 서버에 대한 요청을 인증하기 위한 전달자 토큰 자격 증명으로 사용할 수 있다.

Authorization: Bearer 07401b.f395accd246ae52d

토큰은 사용자 이름 system:bootstrap:<token id> 로 인증되며 system:bootstrappers 그룹의 구성원이다. 토큰의 시크릿에 추가 그룹을 지정할 수 있다.

만료된 토큰은 컨트롤러 관리자에서 tokencleaner 컨트롤러를 활성화하여 자동으로 삭제할 수 있다.

--controllers=*,tokencleaner

부트스트랩 토큰 시크릿 형식

각각의 유효한 토큰은 kube-system 네임스페이스의 시크릿에 의해 지원된다. 전체 디자인 문서는 여기에서 찾을 수 있다.

시크릿은 다음과 같다.

apiVersion: v1
kind: Secret
metadata:
  # Name MUST be of form "bootstrap-token-<token id>"
  name: bootstrap-token-07401b
  namespace: kube-system

# Type MUST be 'bootstrap.kubernetes.io/token'
type: bootstrap.kubernetes.io/token
stringData:
  # Human readable description. Optional.
  description: "The default bootstrap token generated by 'kubeadm init'."

  # Token ID and secret. Required.
  token-id: 07401b
  token-secret: f395accd246ae52d

  # Expiration. Optional.
  expiration: 2017-03-10T03:22:11Z

  # Allowed usages.
  usage-bootstrap-authentication: "true"
  usage-bootstrap-signing: "true"

  # Extra groups to authenticate the token as. Must start with "system:bootstrappers:"
  auth-extra-groups: system:bootstrappers:worker,system:bootstrappers:ingress

시크릿 유형은 bootstrap.kubernetes.io/token 이어야 하고 이름은 bootstrap-token-<token id>여야 한다. 반드시 kube-system 네임스페이스에도 존재해야 한다.

usage-bootstrap-* 멤버는 이 시크릿의 용도를 나타낸다. 활성화하려면 값을 true 로 설정해야 한다.

usage-bootstrap-authentication 은 토큰을 API 서버에 베어러 토큰으로 인증하는데 사용할 수 있음을 나타낸다.
usage-bootstrap-signing 은 토큰을 사용하여 아래에 설명된 cluster-info 컨피그맵에 서명할 수 있음을 나타낸다.

expiration 필드는 토큰의 만료를 제어한다. 만료된 토큰은 인증에 사용될 때 거부되고 컨피그맵서명 중에 무시된다. 만료된 값은 RFC3339를 사용하여 절대 UTC 시간으로 인코딩된다. 만료된 토큰을 자동으로 삭제하려면 tokencleaner 컨트롤러를 활성화한다.

kubeadm을 사용한 토큰 관리

kubeadm 툴을 사용하여 실행중인 클러스터에서 토큰을 관리할 수 있다. 자세한 내용은 kubeadm token docs 에서 찾을 수 있다.

컨피그맵 서명

토큰은 인증 외에도 컨피그맵에 서명하는데 사용할 수 있다. 이것은 클라이언트가 API 서버를 신뢰하기 전에 클러스터 부트스트랩 프로세스의 초기에 사용된다. 서명된 컨피그맵은 공유 토큰으로 인증할 수 있다.

컨트롤러 관리자에서 bootstrapsigner 컨트롤러를 활성화하여 컨피그맵서명을 활성화 한다.

--controllers=*,bootstrapsigner

서명된 컨피그맵은 kube-public 네임스페이스에 있는 cluster-info 이다. 일반적인 흐름은 클라이언트가 인증되지 않고 TLS 오류를 무시하는 동안 컨피그맵을 읽는 것이다. 그런 다음 컨피그맵에 포함된 서명을 확인하여 컨피그맵의 페이로드를 확인한다.

컨피그맵은 다음과 같을 수 있다.

apiVersion: v1
kind: ConfigMap
metadata:
  name: cluster-info
  namespace: kube-public
data:
  jws-kubeconfig-07401b: eyJhbGciOiJIUzI1NiIsImtpZCI6IjA3NDAxYiJ9..tYEfbo6zDNo40MQE07aZcQX2m3EB2rO3NuXtxVMYm9U
  kubeconfig: |
    apiVersion: v1
    clusters:
    - cluster:
        certificate-authority-data: <really long certificate data>
        server: https://10.138.0.2:6443
      name: ""
    contexts: []
    current-context: ""
    kind: Config
    preferences: {}
    users: []

컨피그맵의 kubeconfig 멤버는 클러스터 정보만 입력된 구성 파일이다. 여기서 전달되는 핵심은 certificate-authority-data 이다.
이는 향후 확대될 수 있다.

서명은 "detached" 모드를 사용하는 JWS 서명이다. 서명을 검증하려면 사용자는 JWS 규칙(뒤로 오는 = 를 삭제하는 동안 인코딩된 base64)에 따라 kubeconfig 페이로드를 인코딩해야 한다. 그런 다음 인코딩된 페이로드는 두 개의 점 사이에 삽입하여 전체 JWS를 형성하는 데 사용된다. 전체 토큰(예:07401b.f395accd246ae52d)을 공유 시크릿으로 사용하여 HS256 방식(HMAC-SHA256)을 사용함으로 JWS를 확인할 수 있다. 사용자는 반드시 HS256이 사용되고 있는지 확인해야 한다.

경고:

부트스트래핑 토큰을 가진 모든 당사자는 해당 토큰에 대한 유효한 서명을 만들 수 있다. 컨피그맵 서명을 사용할 때 많은 클라이언트와 동일한 토큰을 공유하는 것은 권장되지 않는다. 손상된 클라이언트는 잠재적으로 서명에 의존하여 TLS 트러스트를 부트스트랩하는 다른 클라이언트를 대신할 수 있기 때문이다.

자세한 내용은 kubeadm implementation details 섹션을 참조하면 된다.

3.2 - 서비스 어카운트 관리하기

서비스어카운트(ServiceAccount) 는 파드에서 실행되는 프로세스에 대한 식별자를 제공한다.

파드 내부의 프로세스는, 자신에게 부여된 서비스 어카운트의 식별자를 사용하여 클러스터의 API 서버에 인증할 수 있다.

서비스 어카운트에 대한 소개는, 서비스 어카운트 구성하기를 참고한다.

이 가이드는 서비스어카운트와 관련된 개념 중 일부를 설명하며, 서비스어카운트를 나타내는 토큰을 얻거나 취소하는 방법에 대해서도 설명한다.

시작하기 전에

쿠버네티스 클러스터가 필요하고, kubectl 커맨드-라인 툴이 클러스터와 통신할 수 있도록 설정되어 있어야 한다. 이 튜토리얼은 컨트롤 플레인 호스트가 아닌 노드가 적어도 2개 포함된 클러스터에서 실행하는 것을 추천한다. 만약, 아직 클러스터를 가지고 있지 않다면, minikube를 사용해서 생성하거나 다음 쿠버네티스 플레이그라운드 중 하나를 사용할 수 있다.

아래 내용들을 따라하기 위해서는 examplens라는 네임스페이스가 필요하다. 없을 경우 다음과 같이 네임스페이스를 생성한다.

kubectl create namespace examplens

사용자 어카운트와 서비스 어카운트 비교

쿠버네티스는 여러 가지 이유로 사용자 어카운트와 서비스 어카운트의 개념을 구분한다.

사용자 어카운트는 사람을 위한 것이지만, 서비스 어카운트는 쿠버네티스의 경우 파드의 일부 컨테이너에서 실행되는 애플리케이션 프로세스를 위한 것이다.
사용자 어카운트는 전역적으로 고려되기 때문에, 클러스터의 모든 네임스페이스에 걸쳐 이름이 고유해야 한다. 어떤 네임스페이스를 확인하든지 간에, 특정 사용자명은 해당 유저만을 나타낸다. 쿠버네티스에서 서비스 어카운트는 네임스페이스별로 구분된다. 두 개의 서로 다른 네임스페이스는 동일한 이름의 서비스어카운트를 각자 가질 수 있다.
일반적으로 클러스터의 사용자 어카운트는 기업 데이터베이스로부터 동기화될 수 있으며, 여기서 새로운 사용자 어카운트를 생성하려면 특별한 권한이 필요하며 복잡한 비즈니스 프로세스에 연결된다. 반면에 서비스 어카운트를 생성하는 경우는, 클러스터 사용자가 최소 권한 원칙에 따라 특정 작업을 위한 서비스 어카운트를 만들 수 있도록 보다 가볍게 만들어졌다. 실 사용자를 온보딩하는 단계와 서비스어카운트를 생성하는 단계를 분리하는 것은, 워크로드가 최소 권한 원칙을 따르기 쉬워지게 한다.
사람과 서비스 어카운트에 대한 감사 고려 사항은 다를 수 있다. 이 둘을 따로 관리함으로써 더욱 쉽게 감사를 수행할 수 있다.
복잡한 시스템의 설정들은 그 시스템의 구성요소에 대한 다양한 서비스 어카운트 정의를 포함할 수 있다. 서비스 어카운트는 많은 제약없이 만들 수 있고 네임스페이스에 할당된 이름을 가질 수 있기 때문에 이러한 설정은 이식성이 좋다.

바인딩된 서비스 어카운트 토큰 볼륨 메커니즘

기능 상태: Kubernetes v1.22 [stable]

기본적으로, 쿠버네티스 컨트롤 플레인(구체적으로 말하자면 서비스어카운트 어드미션 컨트롤러)은 프로젝티드 볼륨을 파드에 추가하며, 이 볼륨은 쿠버네티스 API에 접근할 수 있는 토큰을 포함한다.

다음은 실행된 파드에서 해당 토큰이 어떻게 보이는지에 대한 예시이다.

...
  - name: kube-api-access-<random-suffix>
    projected:
      sources:
        - serviceAccountToken:
            path: token # 애플리케이션이 알고 있는 경로와 일치해야 한다.
        - configMap:
            items:
              - key: ca.crt
                path: ca.crt
            name: kube-root-ca.crt
        - downwardAPI:
            items:
              - fieldRef:
                  apiVersion: v1
                  fieldPath: metadata.namespace
                path: namespace

위의 매니페스트는 세 가지 정보로 구성된 프로젝티드 볼륨을 정의한다. 이 경우, 각 정보는 해당 볼륨 내의 단일 경로를 나타내기도 한다. 세 가지 정보는 다음과 같다.

서비스어카운트토큰(serviceAccountToken) 정보는 kubelet이 kube-apiserver로부터 취득한 토큰을 포함한다. kubelet은 TokenRequest API를 통해 일정 시간 동안 사용할 수 있는 토큰을 발급 받는다. 이렇게 취득한 토큰은 파드가 삭제되거나 지정된 수명 주기 이후에 만료된다(기본값은 1시간이다). 이 토큰은 특정한 파드에 바인딩되며 kube-apiserver를 그 대상으로 한다. 이 메커니즘은 시크릿을 기반으로 볼륨을 추가하던 이전 메커니즘을 대체한 것이다. 해당 시크릿은 파드의 서비스어카운트를 나타냈었는데, 이는 토큰과는 달리 만료가 되지 않는 것이었다.
컨피그맵(ConfigMap) 정보는 인증 및 인가에 관한 번들을 포함한다. 파드들은 이러한 인증서를 사용하여 해당 클러스터의 kube-apiserver(미들박스나 실수로 잘못 구성된 피어가 아닌) 에 대한 연결을 확인할 수 있다.
DownwardAPI 정보는 파드가 포함된 네임스페이스를 검색하고, 해당 정보를 파드 내부에서 실행 중인 애플리케이션에서 사용할 수 있도록 한다.

이러한 볼륨을 마운트한 컨테이너는 위의 정보들에 접근할 수 있다.

참고:

TokenRequest를 통해 발급된 토큰을 무효화하는 메커니즘은 없다. 만약 파드에 바인딩된 서비스 어카운트 토큰을 더 이상 신뢰하지 못하게 된다면, 파드를 삭제한다. 파드를 삭제하면 바인딩 되어있던 서비스 어카운트 토큰 역시 만료된다.

서비스어카운트에 대해 수동으로 시크릿 관리하기

쿠버네티스 v1.22 이전의 버전들은 쿠버네티스 API에 접근하기 위한 자격 증명들을 자동으로 생성했다. 이러한 옛 메커니즘들은, 실행 중인 파드에 마운트 될 수 있는 토큰 시크릿을 만드는 것에 기반을 두었다.

쿠버네티스 v1.31을 포함한 최신 버전에서는, API 자격 증명들은 TokenRequest API를 사용하여 직접 얻을 수 있으며, 프로젝티드 볼륨을 사용하여 파드에 마운트할 수 있다. 이 방법으로 취득한 토큰은 시간 제한이 있으며, 마운트 되었던 파드가 삭제되는 경우 자동으로 만료된다.

예를 들어 평생 만료되지 않는 토큰이 필요한 경우, 서비스 어카운트 토큰을 유지하기 위한 시크릿을 수동으로 생성할 수 있다.

한 번 시크릿을 수동으로 생성하여 서비스어카운트에 연결했다면, 쿠버네티스 컨트롤 플레인은 자동으로 해당 시크릿에 토큰을 채운다.

참고:

장기간 사용할 서비스어카운트 토큰을 수동으로 생성하는 메커니즘이 존재하지만, 단기간 동안에만 사용할 토큰을 취득하는 경우 TokenRequest를 사용하는 것이 권장된다.

컨트롤 플레인의 세부 사항들

토큰 컨트롤러

토큰 컨트롤러는 kube-controller-manager 의 일부로써 실행되며, 비동기적으로 동작한다.

서비스어카운트에 대한 삭제를 감시하고, 해당하는 모든 서비스어카운트 토큰 시크릿을 같이 삭제한다.
서비스어카운트 토큰 시크릿에 대한 추가를 감시하고, 참조된 서비스어카운트가 존재하는지 확인하며, 필요한 경우 시크릿에 토큰을 추가한다.
시크릿에 대한 삭제를 감시하고, 필요한 경우 해당 서비스어카운트에서 참조 중인 항목들을 제거한다.

서비스 어카운트 개인키 파일은 --service-account-private-key-file 플래그를 사용하여 kube-controller-manager 의 토큰 컨트롤러에 전달해야 한다. 개인키는 생성된 서비스 어카운트 토큰에 서명하는 데 사용될 것이다. 마찬가지로 --service-account-key-file 플래그를 사용하여 해당 공개키를 kube-apiserver 에 전달해야 한다. 공개키는 인증 과정에서 토큰을 검증하는 데 사용될 것이다.

서비스어카운트 어드미션 컨트롤러

파드 수정은 어드미션 컨트롤러라는 플러그인을 통해 구현된다. 이것은 API 서버의 일부이며, 파드가 생성될 때 파드를 수정하기 위해 동기적으로 동작한다. 이 플러그인이 활성 상태(대부분의 배포에서 기본값)인 경우, 어드미션 컨트롤러는 파드의 생성 시점에 다음 작업들을 수행한다.

파드에 .spce.serviceAccountName 항목이 지정되지 않았다면, 어드미션 컨트롤러는 실행하려는 파드의 서비스어카운트 이름을 default로 설정한다.
어드미션 컨트롤러는 실행되는 파드가 참조하는 서비스어카운트가 존재하는지 확인한다. 만약 해당하는 이름의 서비스어카운트가 존재하지 않는 경우, 어드미션 컨트롤러는 파드를 실행시키지 않는다. 이는 default 서비스어카운트에 대해서도 동일하게 적용된다.
서비스어카운트의 automountServiceAccountToken 또는 파드의 automountServiceAccountToken 중 어느 것도 false 로 설정되어 있지 않다면,
- 어드미션 컨트롤러는 실행하려는 파드에 API에 접근할 수 있는 토큰을 포함하는 볼륨 을 추가한다.
- 어드미션 컨트롤러는 파드의 각 컨테이너에 volumeMount를 추가한다. 이미 /var/run/secrets/kubernetes.io/serviceaccount 경로에 볼륨이 마운트 되어있는 컨테이너에 대해서는 추가하지 않는다. 리눅스 컨테이너의 경우, 해당 볼륨은 /var/run/secrets/kubernetes.io/serviceaccount 위치에 마운트되며, 윈도우 노드 역시 동일한 경로에 마운트된다.
파드의 spec에 imagePullSecrets 이 없는 경우, 어드미션 컨트롤러는 ServiceAccount의 imagePullSecrets을 복사하여 추가된다.

TokenRequest API

기능 상태: Kubernetes v1.22 [stable]

서비스어카운트의 하위 리소스인 TokenRequest를 사용하여 일정 시간 동안 해당 서비스어카운트에서 사용할 수 있는 토큰을 가져올 수 있다. 컨테이너 내에서 사용하기 위한 API 토큰을 얻기 위해 이 요청을 직접 호출할 필요는 없는데, kubelet이 프로젝티드 볼륨 을 사용하여 이를 설정하기 때문이다.

kubectl에서 TokenRequest API를 사용하고 싶다면, 서비스어카운트를 위한 API 토큰을 수동으로 생성하기를 확인한다.

쿠버네티스 컨트롤 플레인(구체적으로는 서비스어카운트 어드미션 컨트롤러)은 파드에 프로젝티드 볼륨을 추가하고, kubelet은 컨테이너가 올바른 서비스어카운트로 인증할 수 있도록 해당 볼륨이 토큰을 포함하는고 있는지 확인한다.

(이 메커니즘은 시크릿을 기반으로 볼륨을 추가하던 이전 메커니즘을 대체한 것이다. 해당 시크릿은 파드의 서비스어카운트를 나타냈었는데, 이는 만료가 되지 않는 것이었다.)

아래는 실행 중인 파드에서 어떻게 보이는지에 대한 예시이다.

...
  - name: kube-api-access-<random-suffix>
    projected:
      defaultMode: 420 # 8진수 0644에 대한 10진수 값
      sources:
        - serviceAccountToken:
            expirationSeconds: 3607
            path: token
        - configMap:
            items:
              - key: ca.crt
                path: ca.crt
            name: kube-root-ca.crt
        - downwardAPI:
            items:
              - fieldRef:
                  apiVersion: v1
                  fieldPath: metadata.namespace
                path: namespace

위의 매니페스트는 세 가지 정보로 구성된 프로젝티드 볼륨을 정의한다.

서비스어카운트토큰(serviceAccountToken) 정보는 kubelet이 kube-apiserver로부터 취득한 토큰을 포함한다. kubelet은 TokenRequest API를 통해 일정 시간 동안 사용할 수 있는 토큰을 발급 받는다. 이렇게 취득한 토큰은 파드가 삭제되거나 지정된 수명 주기 이후에 만료된다(기본값은 1시간이다). 이 토큰은 특정한 파드에 바인딩되며 kube-apiserver를 그 대상으로 한다.
컨피그맵(ConfigMap) 정보는 인증 및 인가에 관한 번들을 포함한다. 파드들은 이러한 인증서를 사용하여 해당 클러스터의 kube-apiserver(미들박스나 실수로 잘못 구성된 피어가 아닌) 에 대한 연결을 확인할 수 있다.
DownwardAPI 정보는 파드가 포함된 네임스페이스를 검색하고, 해당 정보를 파드 내부에서 실행 중인 애플리케이션에서 사용할 수 있도록 한다.

이러한 볼륨을 마운트한 컨테이너는 위의 정보들에 접근할 수 있다.

추가적인 API 토큰 생성하기

주의:

토큰 요청 메커니즘이 적합하지 않은 경우에만 수명이 긴 API 토큰을 생성한다. 토큰 요청 메커니즘은 시간 제한이 있는 토큰만을 제공하며, 토큰이 만료되기 때문에 보안에 대한 위험이 적다.

서비스어카운트를 위한 만료되지 않는 API 토큰을 생성하려면, 해당 서비스어카운트를 참조하는 어노테이션을 갖는 kubernetes.io/service-account-token 타입의 시크릿을 생성한다. 그러면 컨트롤 플레인은 장기적으로 사용 가능한 토큰을 발급하여 시크릿을 갱신할 것이다.

아래는 시크릿을 위한 예제 매니페스트이다.

secret/serviceaccount/mysecretname.yaml

apiVersion: v1
kind: Secret
type: kubernetes.io/service-account-token
metadata:
  name: mysecretname
  annotations:
    kubernetes.io/service-account.name: myserviceaccount

이 예제에 기반한 시크릿을 생성하려면, 아래의 명령어를 실행한다.

kubectl -n examplens create -f https://k8s.io/examples/secret/serviceaccount/mysecretname.yaml

시크릿에 대한 자세한 사항을 확인하려면, 아래의 명령어를 실행한다.

kubectl -n examplens describe secret mysecretname

결과는 다음과 같다.

Name:           mysecretname
Namespace:      examplens
Labels:         <none>
Annotations:    kubernetes.io/service-account.name=myserviceaccount
                kubernetes.io/service-account.uid=8a85c4c4-8483-11e9-bc42-526af7764f64

Type:   kubernetes.io/service-account-token

Data
====
ca.crt:         1362 bytes
namespace:      9 bytes
token:          ...

만약 examplens 네임스페이스에 새로운 파드를 실행한다면, 해당 파드는 방금 생성한 myserviceaccount 서비스 어카운트 토큰 시크릿을 사용할 수 있다.

서비스어카운트 토큰 시크릿 삭제/무효화

만약 제거하려는 토큰을 포함하는 시크릿의 이름을 알고 있다면, 아래 명령어를 실행한다.

kubectl delete secret name-of-secret

그게 아니라면, 먼저 시크릿을 확인한다.

# 아래 명령어는 'examplens' 네임스페이스가 존재한다고 가정한다.
kubectl -n examplens get serviceaccount/example-automated-thing -o yaml

결과는 다음과 같다.

apiVersion: v1
kind: ServiceAccount
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"v1","kind":"ServiceAccount","metadata":{"annotations":{},"name":"example-automated-thing","namespace":"examplens"}}      
  creationTimestamp: "2019-07-21T07:07:07Z"
  name: example-automated-thing
  namespace: examplens
  resourceVersion: "777"
  selfLink: /api/v1/namespaces/examplens/serviceaccounts/example-automated-thing
  uid: f23fd170-66f2-4697-b049-e1e266b7f835
secrets:
  - name: example-automated-thing-token-zyxwv

이제 시크릿의 이름을 알았으니, 삭제한다.

kubectl -n examplens delete secret/example-automated-thing-token-zyxwv

컨트롤 플레인은 서비스어카운트에 시크릿이 누락되었음을 감지하고, 새로운 것으로 대체한다.

kubectl -n examplens get serviceaccount/example-automated-thing -o yaml

apiVersion: v1
kind: ServiceAccount
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"v1","kind":"ServiceAccount","metadata":{"annotations":{},"name":"example-automated-thing","namespace":"examplens"}}      
  creationTimestamp: "2019-07-21T07:07:07Z"
  name: example-automated-thing
  namespace: examplens
  resourceVersion: "1026"
  selfLink: /api/v1/namespaces/examplens/serviceaccounts/example-automated-thing
  uid: f23fd170-66f2-4697-b049-e1e266b7f835
secrets:
  - name: example-automated-thing-token-4rdrh

정리하기

예제를 위해 examplens 네임스페이스를 생성했었다면, 아래의 명령어로 제거할 수 있다.

kubectl delete namespace examplens

컨트롤 플레인의 세부 사항들

서비스어카운트 컨트롤러

서비스어카운트 컨트롤러는 네임스페이스 내의 서비스어카운트들을 관리하며, 활성화된 모든 네임스페이스에 "default"라는 이름의 서비스어카운트가 존재하도록 한다.

토큰 컨트롤러

토큰 컨트롤러는 kube-controller-manager의 일부로써 실행되며, 비동기적으로 동작한다.

서비스어카운트에 대한 생성을 감시하고, 해당 서비스어카운트 토큰 시크릿을 생성하여 API에 대한 접근을 허용한다.
서비스어카운트에 대한 삭제를 감시하고, 해당하는 모든 서비스어카운트 토큰 시크릿을 같이 삭제한다.
서비스어카운트 토큰 시크릿에 대한 추가를 감시하고, 참조된 서비스어카운트가 존재하는지 확인하며, 필요한 경우 시크릿에 토큰을 추가한다.
시크릿에 대한 삭제를 감시하고, 필요한 경우 해당 서비스어카운트에서 참조 중인 항목들을 제거한다.

다음 내용

자세한 내용은 프로젝티드 볼륨을 확인한다.

3.3 - 인가 개요

지원되는 인가 모듈을 사용하여 정책을 만드는 방법을 포함한 쿠버네티스 인가에 대해 자세히 알아보자.

쿠버네티스에서는 사용자의 요청이 인가(접근 권한을 부여) 받기 전에 사용자가 인증(로그인)되어야 한다. 인증에 대한 자세한 내용은 쿠버네티스 API 접근 제어하기를 참고한다.

쿠버네티스는 REST API 요청에 공통적인 속성을 요구한다. 이는 쿠버네티스 인가가 쿠버네티스 API 이외에 다른 API를 처리할 수 있는 기존 조직 전체 또는 클라우드 제공자 전체의 접근 제어 시스템과 연동된다는 것을 의미한다.

요청 허용 또는 거부 결정

쿠버네티스는 API 서버를 이용하여 API 요청을 인가한다. 모든 정책과 비교하여 모든 요청 속성을 평가하고 요청을 허용하거나 거부한다. 계속 진행하려면 API 요청의 모든 부분이 일부 정책에 의해 반드시 허용되어야 한다. 이는 기본적으로 승인이 거부된다는 것을 의미한다.

(쿠버네티스는 API 서버를 사용하지만, 특정 오브젝트의 특정 필드에 의존하는 접근 제어 및 정책은 어드미션 컨트롤러에 의해 처리된다.)

여러 개의 인가 모듈이 구성되면 각 모듈이 순서대로 확인된다. 어느 인가 모듈이 요청을 승인하거나 거부할 경우, 그 결정은 즉시 반환되며 다른 인가 모듈이 참고되지 않는다. 모든 모듈에서 요청에 대한 평가가 없으면 요청이 거부된다. 요청 거부는 HTTP 상태 코드 403을 반환한다.

요청 속성 검토

쿠버네티스는 다음 API 요청 속성만 검토한다.

user - 인증 중에 제공된 user 문자열.
group - 인증된 사용자가 속한 그룹 이름 목록.
extra - 인증 계층에서 제공하는 문자열 값에 대한 임의의 문자열 키 맵.
API - 요청이 API 리소스에 대한 것인지 여부.
Request path - /api 또는 /healthz와 같이 다양한 리소스가 아닌 엔드포인트의 경로.
API request verb - get, list, create, update, patch, watch, delete, deletecollection과 같은 리소스 요청에 사용하는 API 동사. 리소스 API 엔드포인트의 요청 동사를 결정하려면 요청 동사 결정을 참고한다.
HTTP request verb - get, post, put, delete처럼 소문자 HTTP 메서드는 리소스가 아닌 요청에 사용한다.
Resource - 접근 중인 리소스의 ID 또는 이름(리소스 요청만 해당) -- get, update, patch, delete 동사를 사용하는 리소스 요청의 경우 리소스 이름을 지정해야 한다.
Subresource - 접근 중인 하위 리소스(리소스 요청만 해당).
Namespace - 접근 중인 오브젝트의 네임스페이스(네임스페이스에 할당된 리소스 요청만 해당)
API group - 접근 중인 API 그룹(리소스 요청에만 해당). 빈 문자열은 핵심(core) API 그룹을 지정한다.

요청 동사 결정

리소스가 아닌 요청 /api/v1/... 또는 /apis/<group>/<version>/... 이외에 다른 엔드포인트에 대한 요청은 "리소스가 아닌 요청"으로 간주되며, 요청의 소문자 HTTP 메서드를 동사로 사용한다. 예를 들어, /api 또는 /healthz와 같은 엔드포인트에 대한 GET 요청은 get을 동사로 사용할 것이다.

리소스 요청 리소스 API 엔드포인트에 대한 요청 동사를 결정하려면 사용된 HTTP 동사와 해당 요청이 개별 리소스 또는 리소스 모음에 적용되는지 여부를 검토한다.

HTTP 동사	요청 동사
POST	create
GET, HEAD	get(개별 리소스), list(전체 오브젝트 내용을 포함한 리소스 모음), watch(개별 리소스 또는 리소스 모음을 주시)
PUT	update
PATCH	patch
DELETE	delete(개별 리소스), deletecollection(리소스 모음)

주의:

get, list, watch 요청은 모두 리소스의 전체 세부 내용을 반환할 수 있다. 반환된 데이터의 관점으론 모두 동일하다. 예를 들어 secrets에 대해 list 요청은 반환된 리소스의 data 속성을 여전히 드러낼 것이다.

쿠버네티스는 종종 전문 동사를 사용하여 부가적인 권한 인가를 확인한다. 예를 들면,

RBAC
- rbac.authorization.k8s.io API 그룹의 roles 및 clusterroles 리소스에 대한 bind 동사.
인증
- 핵심 API 그룹의 users, groups, serviceaccounts와 authentication.k8s.io API 그룹의 userextras 동사.

인가 모드

쿠버네티스 API 서버는 몇 가지 인가 모드 중 하나를 사용하여 요청을 승인할 수 있다.

Node - 실행되도록 스케줄된 파드에 따라 kubelet에게 권한을 부여하는 특수 목적 인가 모드. Node 인가 모드 사용에 대한 자세한 내용은 Node 인가를 참조한다.
ABAC - 속성 기반 접근 제어 (ABAC, Attribute-based access control)는 속성과 결합한 정책의 사용을 통해 사용자에게 접근 권한을 부여하는 접근 제어 패러다임을 말한다. 이 정책은 모든 유형의 속성(사용자 속성, 리소스 속성, 오브젝트, 환경 속성 등)을 사용할 수 있다. ABAC 모드 사용에 대한 자세한 내용은 ABAC 모드를 참조한다.
RBAC - 역할 기반 접근 제어(RBAC, Role-based access control)는 기업 내 개별 사용자의 역할을 기반으로 컴퓨터나 네트워크 리소스에 대한 접근을 규제하는 방식이다. 이 맥락에서 접근은 개별 사용자가 파일을 보거나 만들거나 수정하는 것과 같은 특정 작업을 수행할 수 있는 능력이다. RBAC 모드 사용에 대한 자세한 내용은 RBAC 모드를 참조한다.
- 지정된 RBAC(역할 기반 접근 제어)이 인가 결정을 위해 rbac.authorization.k8s.io API 그룹을 사용하면, 관리자가 쿠버네티스 API를 통해 권한 정책을 동적으로 구성할 수 있다.
- RBAC을 활성화하려면 --authorization-mode=RBAC로 API 서버를 시작한다.
Webhook - WebHook은 HTTP 콜백이다(어떤 일이 일어날 때 발생하는 HTTP POST와 HTTP POST를 통한 간단한 이벤트 알림). WebHook을 구현하는 웹 애플리케이션은 특정한 일이 발생할 때 URL에 메시지를 POST 할 것이다. Webhook 모드 사용에 대한 자세한 내용은 Webhook 모드를 참조한다.

API 접근 확인

kubectl은 API 인증 계층을 신속하게 쿼리하기 위한 auth can-i 하위 명령어를 제공한다. 이 명령은 현재 사용자가 지정된 작업을 수행할 수 있는지 여부를 알아내기 위해 SelfSubjectAccessReview API를 사용하며, 사용되는 인가 모드에 관계없이 작동한다.

kubectl auth can-i create deployments --namespace dev

다음과 유사하게 출력된다.

yes

kubectl auth can-i create deployments --namespace prod

다음과 유사하게 출력된다.

no

관리자는 이를 사용자 가장(impersonation)과 병행하여 다른 사용자가 수행할 수 있는 작업을 결정할 수 있다.

kubectl auth can-i list secrets --namespace dev --as dave

다음과 유사하게 출력된다.

no

유사하게, dev 네임스페이스의 dev-sa 서비스어카운트가 target 네임스페이스의 파드 목록을 볼 수 있는지 확인하려면 다음을 실행한다.

kubectl auth can-i list pods \
	--namespace target \
	--as system:serviceaccount:dev:dev-sa

다음과 유사하게 출력된다.

yes

SelfSubjectAccessReview는 authorization.k8s.io API 그룹의 일부로서 API 서버 인가를 외부 서비스에 노출시킨다. 이 그룹의 기타 리소스에는 다음이 포함된다.

SubjectAccessReview - 현재 사용자뿐만 아니라 모든 사용자에 대한 접근 검토. API 서버에 인가 결정을 위임하는 데 유용하다. 예를 들어, kubelet 및 확장(extension) API 서버는 자신의 API에 대한 사용자 접근을 결정하기 위해 해당 리소스를 사용한다.
LocalSubjectAccessReview - SubjectAccessReview와 비슷하지만 특정 네임스페이스로 제한된다.
SelfSubjectRulesReview - 사용자가 네임스페이스 안에서 수행할 수 있는 작업 집합을 반환하는 검토. 사용자가 자신의 접근을 빠르게 요약해서 보거나 UI가 작업을 숨기거나 표시하는 데 유용하다.

이러한 API는 반환된 오브젝트의 응답 "status" 필드가 쿼리의 결과인 일반 쿠버네티스 리소스를 생성하여 쿼리할 수 있다.

kubectl create -f - -o yaml << EOF
apiVersion: authorization.k8s.io/v1
kind: SelfSubjectAccessReview
spec:
  resourceAttributes:
    group: apps
    resource: deployments
    verb: create
    namespace: dev
EOF

생성된 SelfSubjectAccessReview 는 다음과 같다.

apiVersion: authorization.k8s.io/v1
kind: SelfSubjectAccessReview
metadata:
  creationTimestamp: null
spec:
  resourceAttributes:
    group: apps
    resource: deployments
    namespace: dev
    verb: create
status:
  allowed: true
  denied: false

인가 모듈에 플래그 사용

정책에 포함된 인가 모듈을 나타내기 위해 정책에 플래그를 포함시켜야 한다.

다음 플래그를 사용할 수 있다.

--authorization-mode=ABAC 속성 기반 접근 제어(ABAC) 모드를 사용하면 로컬 파일을 사용하여 정책을 구성할 수 있다.
--authorization-mode=RBAC 역할 기반 접근 제어(RBAC) 모드를 사용하면 쿠버네티스 API를 사용하여 정책을 만들고 저장할 수 있다.
--authorization-mode=Webhook WebHook은 원격 REST 엔드포인트를 사용하여 인가를 관리할 수 있는 HTTP 콜백 모드다.
--authorization-mode=Node 노드 인가는 kubelet이 생성한 API 요청을 특별히 인가시키는 특수 목적 인가 모드다.
--authorization-mode=AlwaysDeny 이 플래그는 모든 요청을 차단한다. 이 플래그는 테스트에만 사용한다.
--authorization-mode=AlwaysAllow 이 플래그는 모든 요청을 허용한다. API 요청에 대한 인가가 필요하지 않은 경우에만 이 플래그를 사용한다.

하나 이상의 인가 모듈을 선택할 수 있다. 모듈이 순서대로 확인되기 때문에 우선 순위가 더 높은 모듈이 요청을 허용하거나 거부할 수 있다.

워크로드 생성 및 수정을 통한 권한 확대

네임스페이스에서 파드를 직접, 또는 오퍼레이터와 같은 컨트롤러를 통해 생성/수정할 수 있는 사용자는 해당 네임스페이스 안에서 자신의 권한을 확대할 수 있다.

주의:

시스템 관리자는 파드 생성/수정에 대한 접근 권한을 부여할 때 주의한다. 권한 확대 경로에서 접근 권한이 잘못 사용되었을 때의 상세사항을 확인할 수 있다.

권한 확대 경로

네임스페이스 내의 임의의 시크릿을 마운트
- 다른 워크로드를 위한 시크릿으로의 접근에 사용될 수 있음
- 더 권한이 많은 서비스 어카운트의 서비스 어카운트 토큰 획득에 사용될 수 있음
네임스페이스 내의 임의의 서비스 어카운트를 사용
- 다른 워크로드인것처럼 사칭하여 쿠버네티스 API 액션을 수행할 수 있음
- 서비스 어카운트가 갖고 있는 '권한이 필요한 액션'을 수행할 수 있음
네임스페이스 내의 다른 워크로드를 위한 컨피그맵을 마운트
- 다른 워크로드를 위한 정보(예: DB 호스트 이름) 획득에 사용될 수 있음
네임스페이스 내의 다른 워크로드를 위한 볼륨을 마운트
- 다른 워크로드를 위한 정보의 획득 및 수정에 사용될 수 있음

주의:

시스템 관리자는 위와 같은 영역을 수정하는 CRD를 배포할 때 주의를 기울여야 한다. 이들은 의도하지 않은 권한 확대 경로를 노출할 수 있다. RBAC 제어에 대해 결정할 때 이와 같은 사항을 고려해야 한다.

다음 내용

인증에 대한 자세한 내용은 쿠버네티스 API 접근 제어하기에서 인증 을 참조한다.
어드미션 제어에 대한 자세한 내용은 어드미션 컨트롤러 사용하기를 참조한다.

3.4 - Kubelet 인증/인가

개요

kubelet의 HTTPS 엔드포인트는 다양한 민감도의 데이터에 대한 접근을 제공하는 API를 노출하며, 노드와 컨테이너 내에서 다양한 수준의 권한으로 작업을 수행할 수 있도록 허용한다.

이 문서는 kubelet의 HTTPS 엔드포인트에 대한 접근을 인증하고 인가하는 방법을 설명한다.

Kubelet 인증

기본적으로, 다른 구성의 인증 방법에 의해 거부되지 않은 kubelet의 HTTPS 엔드포인트에 대한 요청은 익명의 요청으로 처리되며, system:anonymous의 사용자 이름과 system:unauthenticated 의 그룹이 부여된다.

익명의 접근을 비활성화하고 인증되지 않은 요청에 401 Unauthorized 응답을 보내려면 아래를 참고한다.

--anonymous-auth=false 플래그로 kubelet을 시작

kubelet의 HTTPS 엔드포인트에 대한 X509 클라이언트 인증서 인증을 활성화하려면 아래를 참고한다.

--client-ca-file 플래그로 kubelet을 시작하면 클라이언트 인증서를 확인할 수 있는 CA 번들을 제공
--kubelet-client-certificate 및 --kubelet-client-key 플래그로 apiserver를 시작
자세한 내용은 apiserver 인증 문서를 참고

API bearer 토큰(서비스 계정 토큰 포함)을 kubelet의 HTTPS 엔드포인트 인증에 사용하려면 아래를 참고한다.

API 서버에서 authentication.k8s.io/v1beta1 API 그룹이 사용 가능한지 확인
--authentication-token-webhook 및 --kubeconfig 플래그로 kubelet을 시작
kubelet은 구성된 API 서버의 TokenReview API를 호출하여 bearer 토큰에서 사용자 정보를 결정

Kubelet 승인

성공적으로 인증된 모든 요청(익명 요청 포함)이 승인된다. 기본 인가 모드는 모든 요청을 허용하는 AlwaysAllow 이다.

kubelet API에 대한 접근을 세분화하는 데는 다양한 이유가 있다.

익명 인증을 사용할 수 있지만, 익명 사용자의 kubelet API 호출 기능은 제한되어야 함
bearer 토큰 인증을 사용할 수 있지만, 임의의 API 사용자(API 계정)의 kubelet API 호출 기능은 제한되어야 함
클라이언트 인증을 사용할 수 있지만, 구성된 CA에서 서명한 일부 클라이언트 인증서만 kubelet API를 사용하도록 허용해야 함

kubelet API에 대한 접근을 세분화하려면 API 서버에 권한을 위임한다.

authorization.k8s.io/v1beta1 API 그룹이 API 서버에서 사용 가능한지 확인
--authorization-mode=Webhook 및 --kubeconfig 플래그로 kubelet을 시작
kubelet은 구성된 API 서버의 SubjectAccessReview API를 호출하여 각각의 요청이 승인되었는지 여부를 확인

kubelet은 API 요청을 apiserver와 동일한 요청 속성 접근 방식을 사용하여 승인한다.

동사는 들어오는 요청의 HTTP 동사로부터 결정된다.

HTTP 동사	요청 동사
POST	create
GET, HEAD	get
PUT	update
PATCH	patch
DELETE	delete

리소스 및 하위 리소스는 들어오는 요청의 경로로부터 결정된다.

Kubelet API	리소스	하위 리소스
/stats/*	nodes	stats
/metrics/*	nodes	metrics
/logs/*	nodes	log
/spec/*	nodes	spec
all others	nodes	proxy

네임스페이스와 API 그룹 속성은 항상 빈 문자열이며, 리소스 이름은 항상 kubelet의 Node API 오브젝트 이름이다.

이 모드로 실행할 때, --kubelet-client-certificate 및 --kubelet-client-key 플래그로 식별된 사용자에게 다음 속성에 대한 권한이 있는지 확인한다.

verb=*, resource=nodes, subresource=proxy
verb=*, resource=nodes, subresource=stats
verb=*, resource=nodes, subresource=log
verb=*, resource=nodes, subresource=spec
verb=*, resource=nodes, subresource=metrics

4 - 잘 알려진 레이블, 어노테이션, 테인트(Taint)

쿠버네티스는 모든 레이블과 어노테이션을 kubernetes.io와 k8s.io 네임스페이스 아래에 정의해 놓았다.

이 문서는 각 값에 대한 레퍼런스를 제공하며, 값을 할당하기 위한 협력 포인트도 제공한다.