Admission Webhook — API 서버가 저장하기 직전 마지막 관문
Kubernetes DaemonSet 및 Admission Webhook 공식 문서 종합 (웹 리서치, 2026) — Kubernetes 공식 문서(concepts/workloads/controllers/daemonset, reference/access-authn-authz/admission-controllers) Kubernetes 공식문서 Admission Control in Kubernetes
이 모듈을 다 읽으면
- Mutating Webhook과 Validating Webhook이 인증·인가(k8s-learn-18의 RBAC) 다음 단계로, 서로 다른 순서에 위치한다는 것을 설명할 수 있다
- Mutating Webhook 안에서는 순서를 보장 안 하지만 이름으로 순서를 강제하는 실무 우회법을 설명할 수 있다
k8s-learn-18에서 다룬 RBAC(누가 API에 접근할 수 있는가)를 전제로, 그 인증·인가를 통과한 요청이 etcd에 실제로 저장되기 전 마지막으로 거치는 관문인 Admission Webhook의 위치와 순서를 정리한다.
요청 흐름 안의 위치 — 인증·인가 다음, 저장 직전
API 요청은 인증(Authentication) → 인가(k8s-learn-18의 RBAC 등 Authorization) → Mutating Webhook(순서대로, 객체를 수정 가능) → 객체 스키마 검증 → Validating Webhook(병렬로, 승인/거부만) → etcd에 최종 저장 순서로 흐른다. 즉 RBAC가 '이 사용자가 이 동작을 할 권한이 있는가'를 판단하는 단계라면, Admission Webhook은 그 권한 있는 요청이 통과한 뒤 '이 객체 내용 자체가 정책에 맞는가'를 마지막으로 검사·수정하는 단계다.
핵심 포인트
- 흐름: 인증→인가(RBAC, k8s-learn-18)→Mutating Webhook(수정 가능)→스키마 검증→Validating Webhook(승인/거부만)→etcd 저장
- RBAC: '이 사용자가 할 권한이 있는가' / Admission Webhook: 권한 있는 요청이 통과한 뒤 '객체 내용 자체가 정책에 맞는가'를 마지막 검사·수정
Mutating이 Validating보다 먼저 — 그리고 순서 안 보장 문제
Mutation이 Validation보다 먼저 실행된다는 게 핵심이다 — 그래서 만약 어떤 라벨을 자동으로 주입하는 Mutating Webhook과, 그 라벨이 있는지 요구하는 Validating Webhook을 함께 쓰면, 먼저 라벨을 주입한 뒤에 그 존재를 검사하는 순서가 성립한다. 다만 같은 타입(Mutating끼리, 혹은 Validating끼리) 안에서는 API 서버가 웹훅들을 순서 없이(무작위로) 호출한다는 함정이 있다 — 여러 Mutating Webhook 간의 실행 순서에 의존하는 로직을 짜면 안 된다는 뜻이다. 실무에서 순서를 강제하고 싶으면 웹훅 이름 앞에 번호를 붙여 알파벳순 정렬을 유도하는 우회법을 쓴다.
핵심 포인트
- Mutation이 Validation보다 먼저 실행 — 라벨 자동 주입(Mutating) 후 그 라벨 존재 검사(Validating) 같은 조합이 성립
- 같은 타입끼리는 순서 보장 안 됨(API 서버가 무작위 호출) — 실무에서는 웹훅 이름에 번호를 붙여 알파벳순 정렬로 순서 강제