쿠버네티스가 API 접근을 구현 및 제어하는 방법에 대한 자세한 내용은 쿠버네티스 API에 대한 접근 제어를 참고한다.
참조 문헌
이 섹션의 다중 페이지 출력 화면임. 여기를 클릭하여 프린트.
쿠버네티스가 API 접근을 구현 및 제어하는 방법에 대한 자세한 내용은 쿠버네티스 API에 대한 접근 제어를 참고한다.
참조 문헌
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 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이 사용되고 있는지 확인해야 한다.
자세한 내용은 kubeadm implementation details 섹션을 참조하면 된다.
이것은 서비스 어카운트에 대한 클러스터 관리자 안내서다. 독자는 쿠버네티스 서비스 어카운트 설정에 익숙하다고 가정한다.
인증 및 사용자 어카운트에 대한 지원은 아직 준비 중이다. 서비스 어카운트를 더 잘 설명하기 위해, 때때로 미완성 기능이 언급될 수 있다.
쿠버네티스는 여러 가지 이유로 사용자 어카운트와 서비스 어카운트의 개념을 구분한다.
서비스 계정 자동화를 구현하기 위해 세 가지 개별 요소가 협력한다.
ServiceAccount
어드미션 컨트롤러ServiceAccount
컨트롤러파드 수정은 어드미션 컨트롤러라는 플러그인을 통해 구현된다. 이것은 API 서버의 일부이다. 파드가 생성되거나 수정될 때 파드를 수정하기 위해 동기적으로 동작한다. 이 플러그인이 활성 상태(대부분의 배포에서 기본값)인 경우 파드 생성 또는 수정 시 다음 작업을 수행한다.
ServiceAccount
가 없다면, ServiceAccount
를 default
로 설정한다.ServiceAccount
가 있도록 하고, 그렇지 않으면 이를 거부한다.automountServiceAccountToken
와 파드의 automountServiceAccountToken
중
어느 것도 false
로 설정되어 있지 않다면,
API 접근을 위한 토큰이 포함된 volume
을 파드에 추가한다./var/run/secrets/kubernetes.io/serviceaccount
에 마운트된 파드의 각 컨테이너에
volumeSource
를 추가한다.imagePullSecrets
이 없는 경우,
ServiceAccount
의 imagePullSecrets
이 파드에 추가된다.Kubernetes v1.22 [stable]
서비스 어카운트 어드미션 컨트롤러는 토큰 컨트롤러에서 생성한 만료되지 않은 서비스 계정 토큰에 시크릿 기반 볼륨 대신 다음과 같은 프로젝티드 볼륨을 추가한다.
- name: kube-api-access-<random-suffix>
projected:
defaultMode: 420 # 0644
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
프로젝티드 볼륨은 세 가지로 구성된다.
kube-apiserver
로부터 TokenRequest API를 통해 얻은 서비스어카운트토큰(ServiceAccountToken)
.
서비스어카운트토큰은 기본적으로 1시간 뒤에, 또는 파드가 삭제될 때 만료된다.
서비스어카운트토큰은 파드에 연결되며 kube-apiserver를 위해 존재한다.컨피그맵(ConfigMap)
.DownwardAPI
.상세 사항은 프로젝티드 볼륨을 참고한다.
토큰컨트롤러는 kube-controller-manager
의 일부로 실행된다. 이것은 비동기적으로 동작한다. 토큰 컨트롤러는,
서비스 어카운트 개인키 파일은 --service-account-private-key-file
플래그를 사용하여 kube-controller-manager
의 토큰 컨트롤러에 전달해야
한다. 개인키는 생성된 서비스 어카운트 토큰에 서명하는 데 사용될 것이다.
마찬가지로 --service-account-key-file
플래그를 사용하여 해당 공개키를
kube-apiserver
에 전달해야 한다. 공개키는 인증 과정에서 토큰을
검증하는 데 사용될 것이다.
컨트롤러 루프는 API 토큰이 포함된 시크릿이 각 서비스어카운트에 존재하도록 보장한다.
서비스어카운트에 대한 추가적인 API 토큰을 생성하기 위해
서비스어카운트를 참조하는 어노테이션과 함께
kubernetes.io/service-account-token
유형의 시크릿을 생성하면
컨트롤러가 새로 생성된 토큰으로 갱신한다.
다음은 시크릿에 대한 샘플 구성이다.
apiVersion: v1
kind: Secret
metadata:
name: mysecretname
annotations:
kubernetes.io/service-account.name: myserviceaccount
type: kubernetes.io/service-account-token
kubectl create -f ./secret.yaml
kubectl describe secret mysecretname
kubectl delete secret mysecretname
서비스어카운트 컨트롤러는 네임스페이스에 있는 서비스어카운트를 관리하고 "default"라는 이름의 서비스어카운트가 모든 활성 네임스페이스에 존재하는지 확인한다.
지원되는 인가 모듈을 사용하여 정책을 만드는 방법을 포함한 쿠버네티스 인가에 대해 자세히 알아보자.
쿠버네티스에서는 사용자의 요청이 인가(접근 권한을 부여) 받기 전에 사용자가 인증(로그인)되어야 한다. 인증에 대한 자세한 내용은 쿠버네티스 API 접근 제어하기를 참고한다.
쿠버네티스는 REST API 요청에 공통적인 속성을 요구한다. 이는 쿠버네티스 인가가 쿠버네티스 API 이외에 다른 API를 처리할 수 있는 기존 조직 전체 또는 클라우드 제공자 전체의 접근 제어 시스템과 연동된다는 것을 의미한다.
쿠버네티스는 API 서버를 이용하여 API 요청을 인가한다. 모든 정책과 비교하여 모든 요청 속성을 평가하고 요청을 허용하거나 거부한다. 계속 진행하려면 API 요청의 모든 부분이 일부 정책에 의해 반드시 허용되어야 한다. 이는 기본적으로 승인이 거부된다는 것을 의미한다.
(쿠버네티스는 API 서버를 사용하지만, 특정 오브젝트의 특정 필드에 의존하는 접근 제어 및 정책은 어드미션 컨트롤러에 의해 처리된다.)
여러 개의 인가 모듈이 구성되면 각 모듈이 순서대로 확인된다. 어느 인가 모듈이 요청을 승인하거나 거부할 경우, 그 결정은 즉시 반환되며 다른 인가 모듈이 참고되지 않는다. 모든 모듈에서 요청에 대한 평가가 없으면 요청이 거부된다. 요청 거부는 HTTP 상태 코드 403을 반환한다.
쿠버네티스는 다음 API 요청 속성만 검토한다.
user
문자열./api
또는 /healthz
와 같이 다양한 리소스가 아닌 엔드포인트의 경로.get
, list
, create
, update
, patch
, watch
, delete
, deletecollection
과 같은 리소스 요청에 사용하는 API 동사. 리소스 API 엔드포인트의 요청 동사를 결정하려면 요청 동사 결정을 참고한다.get
, post
, put
, delete
처럼 소문자 HTTP 메서드는 리소스가 아닌 요청에 사용한다.get
, update
, patch
, delete
동사를 사용하는 리소스 요청의 경우 리소스 이름을 지정해야 한다.리소스가 아닌 요청
/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.authorization.k8s.io
API 그룹의 roles
및 clusterroles
리소스에 대한 bind
동사.users
, groups
, serviceaccounts
와 authentication.k8s.io
API 그룹의 userextras
동사.쿠버네티스 API 서버는 몇 가지 인가 모드 중 하나를 사용하여 요청을 승인할 수 있다.
rbac.authorization.k8s.io
API 그룹을 사용하면, 관리자가 쿠버네티스 API를 통해 권한 정책을 동적으로 구성할 수 있다.--authorization-mode=RBAC
로 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 요청에 대한 인가가 필요하지 않은 경우에만 이 플래그를 사용한다.하나 이상의 인가 모듈을 선택할 수 있다. 모듈이 순서대로 확인되기 때문에 우선 순위가 더 높은 모듈이 요청을 허용하거나 거부할 수 있다.
네임스페이스에서 파드를 직접, 또는 오퍼레이터와 같은 컨트롤러를 통해 생성/수정할 수 있는 사용자는 해당 네임스페이스 안에서 자신의 권한을 확대할 수 있다.
kubelet의 HTTPS 엔드포인트는 다양한 민감도의 데이터에 대한 접근을 제공하는 API를 노출하며, 노드와 컨테이너 내에서 다양한 수준의 권한으로 작업을 수행할 수 있도록 허용한다.
이 문서는 kubelet의 HTTPS 엔드포인트에 대한 접근을 인증하고 인가하는 방법을 설명한다.
기본적으로, 다른 구성의 인증 방법에 의해 거부되지 않은 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를 시작API bearer 토큰(서비스 계정 토큰 포함)을 kubelet의 HTTPS 엔드포인트 인증에 사용하려면 아래를 참고한다.
authentication.k8s.io/v1beta1
API 그룹이 사용 가능한지 확인--authentication-token-webhook
및 --kubeconfig
플래그로 kubelet을 시작TokenReview
API를 호출하여 bearer 토큰에서 사용자 정보를 결정성공적으로 인증된 모든 요청(익명 요청 포함)이 승인된다. 기본 인가 모드는 모든 요청을 허용하는 AlwaysAllow
이다.
kubelet API에 대한 접근을 세분화하는 데는 다양한 이유가 있다.
kubelet API에 대한 접근을 세분화하려면 API 서버에 권한을 위임한다.
authorization.k8s.io/v1beta1
API 그룹이 API 서버에서 사용 가능한지 확인--authorization-mode=Webhook
및 --kubeconfig
플래그로 kubelet을 시작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
플래그로 식별된 사용자에게
다음 속성에 대한 권한이 있는지 확인한다.