API 요청 처리 흐름

결론부터

API 요청은 인증으로 신원을 확인하고, 인가로 권한을 판단한 뒤, Admission으로 내용을 검사한다.

클러스터에 선언을 보내려면 API 서버의 검사를 통과해야 한다. 이 페이지에서는 각 단계의 역할과 실패 메시지를 구분한다.

요청이 통과해야 하는 세 관문

아키텍처에서 봤듯 클러스터의 모든 변경은 kube-apiserver를 거쳐 etcd에 적는 것으로 시작한다. 컨트롤러도, kubelet도, kubectl도 리소스를 읽고 변경할 때 API 서버를 이용한다. 그 문지기가 인증 → 인가 → admission(요청 내용 검사) 세 관문이고, 이 장은 그 관문의 이야기다. “선언(spec)을 적으면 컨트롤러가 실제를 거기에 맞춰 간다”는 축에서, 여기는 누가 그 선언을 적을 수 있는가를 정하는 자리다.

세 관문 앞에는 TLS 전송 경계가 있다. 클라이언트는 CA와 SAN(Subject Alternative Name)으로 API 서버 인증서를 검증한 뒤 암호화된 연결을 만들고, 서버는 그 연결에서 받은 클라이언트 인증서나 토큰으로 신원을 판정한다. 따라서 x509·인증서 이름 불일치는 인증 401보다 앞에서 끝난 실패다.

인가에서 가장 많이 쓰는 방식이 RBAC(Role-Based Access Control, 역할 기반 접근 제어) 다. 역할에 권한을 정의하고 사용자·그룹·ServiceAccount를 그 역할에 묶는다.

필요한 개념으로 이동하기

알고 싶은 것	페이지
사람이 API 서버에 로그인하는 방법	사용자 인증과 CSR
Pod 안의 프로그램이 사용하는 신원	ServiceAccount
신원에 작업 권한을 부여하는 방법	RBAC
권한을 통과한 요청의 내용을 검사하는 방법	Admission

단계별 실패 구분

요청이 인증·인가·어드미션 세 관문을 거쳐 etcd에 저장되고 각 단계에서 실패하는 지점

단계	실패 시	뜻
TLS	`x509`·인증서 검증 오류	API 서버 신원·CA·SAN 또는 유효기간이 맞지 않는다
인증	401 Unauthorized	신원을 확인할 수 없다
인가	403 Forbidden	신원은 확인됐지만 권한이 없다
admission	다양한 에러	정책·검증에 걸렸다

에러 문장을 RBAC 필드로 옮기면 그대로 답이 된다.

403 에러 메시지의 각 부분이 RBAC 오브젝트의 어느 필드에 대응하는지

요약

API 요청은 인증으로 신원을 확인하고, 인가로 권한을 판단한 뒤, Admission으로 내용을 검사한다.
TLS 검증 오류와 API 서버의 인증·인가 오류를 구분한다.
사람의 신원은 사용자 인증, Pod의 신원은 ServiceAccount에서 확인한다.