CNCF: AI 샌드박싱이 Kubernetes의 순간을 맞이하다 — 워크로드별 격리된 커널이 새로운 보안 표준으로

Edera의 Field CTO Jed Salazar는 2026년 4월 30일 CNCF 블로그에 분석을 게재하며, Kubernetes 인프라가 AI 산업이 안전한 에이전트 시스템 개발에서 이미 경험한 것과 동일한 전환점을 겪고 있다고 주장했습니다.

공유 커널이 구조적 보안 문제인 이유는 무엇입니까?

문제는 Kubernetes의 기본 아키텍처에 있습니다: 클러스터 내의 모든 워크로드가 하나의 Linux 커널을 공유합니다. 이는 컨테이너 간의 격리가 OS 수준에서 완전하지 않다는 것을 의미합니다 — 더 높은 추상화 레이어에만 존재합니다.

Salazar의 주장에 따르면, 하나의 커널 침해가 모든 워크로드에 연쇄 영향을 미칩니다. 커널 공간의 취약점을 악용한 공격자는 모든 컨테이너 수준의 보안 메커니즘을 우회하고 완전히 다른 애플리케이션에서 실행 중인 민감한 데이터나 프로세스에 접근할 수 있습니다.

AISI 조사 결과는 위협의 심각성에 대해 무엇을 말합니까?

Salazar는 AI 모델이 소프트웨어 시스템에서 제로데이 취약점을 자율적으로 발견한다는 것을 기록한 AI 안전연구소(AISI)의 조사 결과에 의존합니다. 이는 이론적 위협이 아닙니다: 커널 취약점에 대한 공격 자동화가 더 광범위한 행위자에게 이용 가능해지고 있습니다.

Salazar는 탐지 기반 보안 — 공격이 발생한 후 탐지하는 접근법 — 이 이 맥락에서 불충분하다고 주장합니다. 공격자가 커널을 침해하면 피해는 이미 발생한 것입니다.

AI 샌드박싱 원칙은 Kubernetes 격리를 어떻게 해결합니까?

Salazar가 제안하는 해결책은 워크로드별 격리된 커널 인스턴스입니다 — 각 Kubernetes 파드 또는 디플로이먼트가 클러스터의 나머지 부분과 커널을 공유하는 대신 자체 커널을 갖습니다.

이 원칙은 새로운 것이 아닙니다: AI 산업은 에이전트 시스템의 샌드박싱에 이미 적용하여 침해된 AI 세션이 인프라나 다른 에이전트에 영향을 미치는 것을 방지하고 있습니다. Salazar의 주장은 동일한 논리가 AI 워크로드만이 아닌 모든 클라우드 네이티브 인프라에 적용되어야 한다는 것입니다.

클라우드 네이티브 커뮤니티를 위한 더 넓은 맥락

Kubernetes, Prometheus 및 수십 개의 관련 프로젝트를 유지하는 Cloud Native Computing Foundation의 발언 플랫폼인 CNCF 블로그에 게재됨으로써 클라우드 네이티브 생태계 내에서 이 주장에 특정한 무게가 더해졌습니다.

Edera는 커널 수준의 워크로드 격리 도구를 개발하므로 Salazar는 이 토론에서 상업적 입장을 가지고 있습니다. 그럼에도 불구하고, 단일 실패 지점으로서의 공유 커널에 대한 구조적 주장은 보안 연구자 커뮤니티 내에서 기술적 합의로 남아 있습니다.