Kubelet Authentication & Authorization
Kubelet 인증
기본적으로, 다른 구성된 인증 방법에 의해 거부되지 않는 kubelet의 HTTPS 엔드포인트로의 요청은 익명 요청으로 처리되며 system:anonymous
사용자 이름과 system:unauthenticated
그룹이 부여됩니다.
3 가지 인증 방법은:
익명 (기본값):
--anonymous-auth=true
매개변수를 설정하거나 구성을 사용합니다.
Webhook: 이것은 kubectl API 베어러 토큰을 인증으로 활성화합니다 (유효한 토큰이면 모두 유효합니다). 다음과 같이 허용하십시오:
API 서버에서
authentication.k8s.io/v1beta1
API 그룹이 활성화되어 있는지 확인하십시오.kubelet을
--authentication-token-webhook
및--kubeconfig
플래그와 함께 시작하거나 다음 설정을 사용하십시오:
kubelet은 구성된 API 서버에서 TokenReview
API를 호출하여 bearer 토큰에서 사용자 정보를 결정합니다.
X509 클라이언트 인증서: X509 클라이언트 인증서를 통해 인증을 허용합니다.
자세한 내용은 apiserver 인증 문서를 참조하십시오.
--client-ca-file
플래그를 사용하여 CA 번들을 제공하여 클라이언트 인증서를 확인하거나 구성으로 kubelet을 시작하십시오.
Kubelet 권한 부여
성공적으로 인증된 모든 요청(익명 요청 포함)은 그런 다음 권한이 부여됩니다. 기본 권한 부여 모드는 **AlwaysAllow
**이며 모든 요청을 허용합니다.
그러나 다른 가능한 값은 **webhook
**입니다(일반적으로 찾을 수 있는 값). 이 모드는 인증된 사용자의 권한을 확인하여 작업을 허용하거나 거부합니다.
익명 인증이 활성화되어 있더라도 익명 액세스가 어떤 작업도 수행할 수 있는 권한을 가지고 있지 않을 수 있다는 점을 유의하십시오.
Webhook을 통한 권한 부여는 --authorization-mode=Webhook
매개변수를 사용하여 구성하거나 다음과 같이 구성 파일을 통해 설정할 수 있습니다:
kubelet은 각 요청이 인가되었는지를 결정하기 위해 구성된 API 서버에서 SubjectAccessReview
API를 호출합니다.
kubelet은 apiserver와 동일한 요청 속성 접근 방식을 사용하여 API 요청을 인가합니다:
동작
HTTP 동사 | 요청 동사 |
---|---|
POST | create |
GET, HEAD | get (개별 리소스용), list (컬렉션용, 전체 객체 내용 포함), watch (개별 리소스 또는 리소스 컬렉션을 감시하는 데 사용) |
PUT | update |
PATCH | patch |
DELETE | delete (개별 리소스용), deletecollection (컬렉션용) |
Kubelet API와 통신하는 리소스는 항상 nodes이며 하위 리소스는 들어오는 요청 경로에서 결정됩니다:
Kubelet API | 리소스 | 하위 리소스 |
---|---|---|
/stats/* | nodes | stats |
/metrics/* | nodes | metrics |
/logs/* | nodes | log |
/spec/* | nodes | spec |
나머지 모든 것 | nodes | proxy |
예를 들어, 다음 요청은 권한 없이 kubelet의 pods 정보에 액세스하려고 시도했습니다:
우리는 금지를 받았으므로 요청은 인증 확인을 통과했습니다. 그렇지 않으면, 우리는 그냥
인가되지 않음
메시지를 받았을 것입니다.사용자 이름 (이 경우 토큰에서)
리소스가 노드이고 서브리소스가 프록시인지 확인하세요 (이전 정보와 일치함)
참고 자료
Last updated