Admission Webhook만으로는 부족한 이유
Kubernetes 환경에서 컨테이너 공급망 보안을 구현할 때 가장 먼저 떠올리는 것이 Admission Webhook이다. Kyverno, OPA Gatekeeper, Sigstore Policy Controller 같은 도구들은 Pod 생성 요청을 가로채 이미지 서명과 어테스테이션을 검증한 뒤 허용 또는 거부 결정을 내린다. 그러나 이 방식에는 구조적인 한계가 존재한다.
핵심 문제는 API 서버 레이어를 우회하는 경로가 실제로 존재한다는 점이다. 대표적인 예가 Static Pod다. Static Pod는 kubelet이 직접 관리하므로 미러 Pod가 Admission 단계에서 거부되더라도 실제 컨테이너는 실행된다. 잘못된 네임스페이스 이름을 가진 Static Pod는 API 서버에서 아예 보이지 않기 때문에 Admission Webhook 자체가 작동할 기회조차 없다. kubelet API에 직접 접근하거나 namespace selector 설정이 잘못된 경우도 마찬가지로 검증이 조용히 건너뛰어진다.
가용성 문제도 있다. OPA Gatekeeper의 fail-closed 설정은 클러스터 전체 노드 삭제 이후 노드 복구를 막는 교착 상태를 유발할 수 있다. 보안을 강화할수록 운영 안정성이 위협받는 딜레마가 발생하는 것이다.
NRI(Node Resource Interface) 기반 런타임 검증
NRI는 컨테이너 런타임(CRI-O, containerd) 수준에서 플러그인이 컨테이너 생명주기 이벤트에 개입할 수 있도록 설계된 인터페이스다. Supply Chain NRI Plugin은 이 인터페이스를 활용해 컨테이너가 스케줄된 방식과 무관하게, 실제 실행 직전 런타임 수준에서 공급망 검증을 수행한다.
원래는 CRI-O의 인트리(in-tree) 기능으로 제안되었지만, 커뮤니티 피드백을 반영해 플러그인 형태로 설계 방향이 바뀌었다. 덕분에 CRI-O와 containerd 모두 지원하고, 런타임의 크리티컬 패스를 단순하게 유지하면서 독자적인 릴리스 사이클로 운영할 수 있다.
[Pod 생성 요청]
│
▼
[Admission Webhook] ← 기존 검증 레이어 (우회 가능)
│
▼
[kubelet → CRI (containerd/CRI-O)]
│
▼
[NRI Plugin: 공급망 검증] ← 런타임 수준 검증 (우회 불가)
│
▼
[컨테이너 실행]
Admission Webhook이 완전히 스킵되더라도, NRI 플러그인은 모든 컨테이너가 반드시 통과해야 하는 경로에 위치하기 때문에 누락 없는 검증이 가능하다.
실무 운영 관점에서의 도입 전략
NRI 기반 검증은 기존 Admission Webhook을 대체하는 것이 아니라 보완하는 심층 방어(defense-in-depth) 전략으로 접근해야 한다. 두 레이어를 함께 운영하면 다음과 같은 이점이 생긴다.
- Admission Webhook: API 레이어에서 조기 차단, 감사 로그 통합, 정책 관리 UI 활용
- NRI Plugin: Static Pod, kubelet 직접 접근, webhook 우회 시도 등 누락 경로 보완
- 두 레이어 모두 실패 시에도 NRI가 런타임에서 최종 방어선 역할 수행
운영 환경에서 고려해야 할 점은 NRI 플러그인이 런타임에 추가되는 만큼 컨테이너 시작 지연이 발생할 수 있다는 것이다. 검증 로직의 타임아웃 설정과 캐싱 전략을 충분히 검토해야 한다. 또한 CRI-O나 containerd의 버전 호환성, NRI 지원 여부를 사전에 확인하는 것이 필수적이다.
정리
- Admission Webhook은 Static Pod, kubelet 직접 접근 등 구조적 우회 경로가 존재해 단독으로는 완전한 공급망 검증을 보장하지 못한다.
- NRI Plugin은 컨테이너 런타임 수준에서 스케줄 방식에 무관하게 모든 컨테이너에 검증을 적용하는 심층 방어 레이어를 제공한다.
- 기존 Admission Webhook과 병행 운영하는 보완 전략으로 도입하되, 런타임 성능 영향과 버전 호환성을 반드시 사전 검토해야 한다.