🚫 Kyverno는 왜 ValidatingWebhookConfiguration과 MutatingWebhookConfiguration을 제어할 수 없을까?

Kubernetes의 Admission Webhook과 Kyverno의 정책 관리 구조를 살펴보면, 일부 리소스들은 Kyverno 정책으로 검증하거나 수정할 수 없습니다. 그 대표적인 예가 바로 ValidatingWebhookConfiguration과 MutatingWebhookConfiguration 입니다.

이 글에서는 이 현상의 이유를 깊이 있게 탐구하고, 왜 이런 설계가 필요한지, 그리고 실무적으로 어떤 대안을 고려할 수 있는지를 다룹니다.

https://kyverno.io/docs/introduction/how-kyverno-works/

---

🧩 먼저, Admission Controller란 무엇인가?

Kubernetes API 서버로 들어오는 모든 요청은 여러 단계를 거칩니다.
대표적으로 다음과 같은 과정이 있습니다:

1. Authentication (인증) – 누가 요청했는가?
2. Authorization (인가) – 요청이 허용되는가?
3. Admission Control (승인 제어) – 요청 내용을 수정(변형)하거나 검증할 수 있는가?

Admission Controller 단계에서는 두 가지 중요한 서브 시스템이 있습니다:

• Mutating Admission Webhook: 요청된 리소스를 “수정(mutating)”할 수 있음
• Validating Admission Webhook: 요청된 리소스의 유효성을 “검증(validating)”함

📘 즉, API 서버의 입장에서 보면, 어떤 리소스가 생성되거나 업데이트될 때, 외부 웹훅을 호출해 “이 리소스 괜찮은지?”, “필요한 필드 채워줄까?”를 물어보는 구조입니다.

---

🧠 Kyverno란 무엇인가?

Kyverno는 Kubernetes 네이티브 정책 엔진으로, 다음과 같은 세 가지 방식으로 리소스를 제어합니다:

• Validation Policy: 리소스가 클러스터 정책을 지키는지 검증
• Mutation Policy: 리소스 요청을 자동으로 수정
• Generation Policy: 특정 이벤트 발생 시 다른 리소스를 생성

Kyverno는 내부적으로 Admission Webhook으로 동작합니다.
즉, Kyverno 자신도 별도의 MutatingWebhookConfiguration과 ValidatingWebhookConfiguration 리소스를 등록하여, 모든 리소스 요청 흐름에 끼어드는 구조입니다.

---

🚫 그런데 문제: Kyverno로 Kyverno의 웹훅을 관리할 수는 없다?

바로 여기서 “순환적 구조(circular dependency)” 문제가 등장합니다.
Kubernetes의 Admission 단계에서 특정 리소스 타입, 즉
ValidatingWebhookConfiguration과 MutatingWebhookConfiguration 리소스에 대해서는
Admission Webhook 호출을 생략합니다.

즉, API 서버는 웹훅 관련 리소스를 또 다른 웹훅에 보내지 않습니다.

이유는 간단하지만, 매우 중요합니다.

---

⚙️ 설계 이유: 순환 호출(Circular Webhook Invocation) 방지

만약 Admission Webhook 설정 자체를 또 다른 Admission Webhook이 검증하거나 수정할 수 있다면, 이런 상황이 발생할 수 있습니다:

• Kyverno가 새로운 웹훅 구성을 수정하려고 함
• 그런데 그 행동 자체가 다시 Kyverno의 웹훅 호출을 일으킴
• 그 결과, 웹훅 호출이 자기 자신을 계속 트리거
• 결국 무한 루프(Infinite recursion) 발생 💥

Kubernetes 설계자는 이를 미리 방지하기 위해 API 서버가 ValidatingWebhookConfiguration과 MutatingWebhookConfiguration 자원 요청을 webhooks에게 전달하지 않도록 설계했습니다.

즉, Admission 단계에서 이 두 리소스는 완전히 예외 처리됩니다.
결과적으로, Kyverno는 이 리소스를 "볼" 수조차 없습니다.

---

🔒 보안적 이유도 존재한다

보안적인 관점에서도 이 결정은 매우 중요합니다.
만약 Admission Webhook이 다른 웹훅 구성을 수정할 수 있다면, 악성 설정을 주입할 가능성이 생깁니다.

예를 들어, 공격자가 Kyverno 정책이나 다른 MutatingWebhook을 통해 자신만의 웹훅을 자동 생성할 수 있다면, 클러스터의 모든 API 요청을 가로채는 것이 가능해집니다.
이는 Cluster compromise 수준의 취약점으로 이어질 수 있습니다.

따라서, 이러한 “self-mutation”을 원천적으로 막는 것은 시스템 안정성과 보안 유지의 핵심 설계 철학입니다.

---

👀 실제로 어떻게 동작할까?

실제로 kubectl apply로 MutatingWebhookConfiguration을 생성하거나 변경할 때, kube-apiserver는 아래 단계만 수행합니다:

1. etcd 저장 전 기본 스키마 검증 수행
2. 등록된 Admission Webhook 목록 확인 (MutatingWebhookConfiguration, ValidatingWebhookConfiguration 타입에 대해서는 호출 스킵)
3. 리소스를 etcd에 커밋

이 과정에서 Kyverno는 이 요청을 관찰하거나 수정할 기회를 얻지 못합니다.

Kyverno의 로그를 보면, 다른 리소스(Deployment, Pod 등)는 webhook request로 들어오지만
WebhookConfiguration 관련 이벤트는 아예 감지되지 않습니다.

---

🧩 그렇다면 정책으로는 전혀 제어가 불가능할까?

Kyverno 단독으로는 불가능합니다. 그러나 다음과 같은 대안들이 존재합니다.

✅ 방법 1: External Admission Controller 사용

자체적으로 Admission Webhook을 구현하여 WebhookConfiguration 리소스를 감시할 수 있습니다. 다만, K8s 자체 설계 때문에 “변경 차단”은 불가능하며, 감시(audit-only) 용도로 제한됩니다.

✅ 방법 2: Controller-level 감시

Kyverno가 아닌 Controller나 Operator 형태로 kube-apiserver의 etcd 저장 후 이벤트를 감시하여, 부적절한 Webhook 구성이 감지되면 즉시 복원(mitigate)합니다.

예: Controller Runtime, Kubernetes Informer 기반의 Go 애플리케이션으로 “webhook-config watcher”를 구축.

✅ 방법 3: RBAC으로 보호

가장 현실적이고 안전한 방법입니다.
MutatingWebhookConfiguration과 ValidatingWebhookConfiguration 리소스는 ClusterScope 객체이므로, 이를 편집할 수 있는 권한(Role, ClusterRole)을 최소화하는 방식으로 관리자의 접근 제어를 적용해야 합니다.

---

⚠️ DevOps 운영 시 주의점

클러스터 운영 중, Kyverno를 CI/CD 파이프라인에서 자동화 도구로 사용하는 경우, 간혹 다음과 같은 오류를 볼 수 있습니다:

text

Error: Policy cannot be applied to resource type MutatingWebhookConfiguration

이 경우, 문제가 아니라 정상 동작입니다 😀
Kyverno가 설계된 대로 제한된 리소스를 무시하는 것이며, 이를 억지로 변경하려 하지 않아야 합니다.

---

💡 정리하자면

항목설명Kyverno 정책 적용 여부

Deployment / Pod	일반 리소스	✅ 가능
Namespace	일반 클러스터 리소스	✅ 가능
CustomResourceDefinition (CRD)	리소스 정의	⚠️ 제한적 (특별 설정 필요)
MutatingWebhookConfiguration	Admission 시스템 구성	❌ 불가능
ValidatingWebhookConfiguration	Admission 시스템 구성	❌ 불가능

---

🔍 결론: 제어보다 신뢰 경계의 분리

Kubernetes의 핵심 철학은 “제어(Control)”보다 “경계(Separation of Trust)”를 강조합니다.
Admission Webhook은 클러스터의 심장부에 개입하므로, 이 컴포넌트를 또 다른 Webhook이 제어하거나 검증한다면, 시스템의 무결성을 위협할 수 있습니다.

따라서 Kyverno가 Webhook 설정 리소스를 관리하지 않도록 한 것은 단순한 제약이 아니라,
시스템 안정성과 보안을 위한 필수적인 방어선입니다.

---