Koray Oksay CNCF 앰배서더는 조직들이 Kyverno를 보안 팀의 책임 아래 두고 Kubernetes 설정을 검증하거나 루트 권한으로 실행되는 컨테이너를 차단하고 컨테이너 보안 표준을 적용하는 데 주로 사용한 뒤, 그 기능의 상당 부분을 외면하는 경우가 많다고 본다. Oksay의 주장에 따르면 이러한 사고방식은 Kyverno를 잘못된 설정을 차단하는 ‘게이트’ 역할로 한정하지만, 플랫폼 팀이 서비스와 운영 규칙을 구축하는 기반 구성 요소로도 활용할 수 있다.
이 견해는 2023년 KCD Munich 콘퍼런스에서 ‘Kyverno를 사용한 Kubernetes 워크로드 보안’이라는 제목의 발표로 시작된 저자의 경험에 바탕을 둔다. 그는 프로덕션 환경에서 3년간 작업한 뒤 관심이 거버넌스, CEL, 플랫폼 셀프서비스로 옮겨갔으며, Kyverno를 ‘정책 엔진’이라고 부르는 것만으로는 그 범위를 더 이상 충분히 설명할 수 없다고 말한다.
보안 분류만으로는 왜 충분하지 않은가?
Oksay는 Kyverno의 보안 기능을 부정하지 않는다. 플랫폼은 안전하지 않은 설정을 차단하고, Pod Security Standards를 적용하며, 컨테이너 이미지 서명을 검증할 수 있다. 그러나 이를 보안에만 연결하면 정책을 주된 목표가 거부인 장벽으로 보는 모델이 굳어지고, 성공 여부를 차단된 배포 수로 측정하게 된다.
반면 저자는 Kyverno의 네 가지 주요 기능을 검증, 수정, 생성, 이미지 검증으로 구분한다. 검증 기능은 장벽 모델에 직접 속하고, 수정은 리소스가 클러스터에 들어가기 전에 변경하며, 생성은 특정 이벤트에 대응해 새로운 리소스를 만들고, 이미지 검증은 위협 차단만이 아니라 이미지에 대한 신뢰 구축에 초점을 둔다. 따라서 그는 네 가지 기능 중 세 가지가 구축적인 성격을 지닌다고 보지만, 많은 조직은 검증 정책만 사용한다고 지적한다.
플랫폼의 핵심 구성 요소란 무엇인가?
Oksay는 ‘핵심 구성 요소’라는 표현을 프로그래밍 언어에서 사용하는 의미와 유사하게 사용한다. 즉, 더 큰 시스템을 구축하기 위해 조합할 수 있는 작고 이해하기 쉬운 구성 블록을 뜻한다. 이 구성 블록이 플랫폼에서 실제 역할을 하려면 개발자에게 복잡성을 숨기고, 자동화된 보장을 제공하며, 다른 구성 블록과 통합되고, 수동 요청이나 지원 대기열에 의존하지 않고 셀프서비스로 이용 가능해야 한다.
이러한 의미에서 Kyverno 정책은 Pods, Services, ConfigMaps, Crossplane 구성과 같은 구성 요소와 유사하다. 조직이 채택한 규칙을 플랫폼 내부의 자동화된 동작으로 전환하기 때문이다.
플랫폼 팀은 이를 어떻게 사용하는가?
- 네임스페이스 준비: 네임스페이스가 생성될 때 Kyverno는 기본 NetworkPolicy, ResourceQuota, LimitRange, RoleBindings를 생성할 수 있다. 따라서 개발자에게 여러 수동 단계를 기억하도록 요구하지 않아도 네임스페이스가 준비된 상태로 나타난다.
- 사이드카 컨테이너 주입: 승인 단계에서 모니터링 에이전트, 네트워크 에이전트 또는 비밀 동기화 컨테이너를 Pod 사양에 추가할 수 있어 Deployment 파일을 간단하게 유지할 수 있다.
- 이미지 참조 재작성: nginx:1.25와 같은 참조를 mirror.internal/nginx:1.25로 변환해 이미지 가져오기 작업이 내부 미러를 거치도록 할 수 있다. 모든 개발자에게 접두사를 수동으로 추가하도록 요구할 필요가 없다.
- 기본 리소스 요청 추가: CPU 및 메모리 요청을 지정하지 않은 Pods를 차단하는 대신 적절한 값을 주입하고 필요할 때 조정할 수 있다.
- 소유권 태그 지정: 값이 명확할 때 팀, 비용 센터, 환경 태그를 추가하거나, 모호성이 영향을 미치는 경우 이를 강제할 수 있다.
실제로 무엇이 달라지는가?
이러한 사용 사례는 하나의 아이디어로 모인다. 즉, 조직의 원칙을 보이지 않는 자동화된 보장으로 전환하는 것이다. 규칙은 높은 권한을 가진 컨테이너를 차단하는 보안 규칙일 수도 있고, 리소스 제한을 강제하는 운영 규칙일 수도 있으며, 모든 리소스를 비용 센터 태그와 연결하는 재무 규칙일 수도 있다. 이러한 규칙이 위키, 체크리스트 또는 한 명의 엔지니어가 가진 지식에 머무르는 대신, 코드로 작성된 정책이 되어 Git에 저장되고 GitOps 도구와 Kyverno를 통해 적용된다.
이 관점은 정책을 조직의 의도를 표현하는 플랫폼의 인터페이스로 다룰 것을 제안한다. 이를 적용하면 Kyverno의 기능은 서로 다른 수준으로 전환된다. 검증은 가드레일을 제공하고, 수정은 개발자를 위한 ‘포장된 길’을 만들며, 생성은 템플릿이나 초기 준비를 제공하고, 이미지 검증은 신뢰를 구축한다.
또한 팀은 정책을 버전, 사용자, 중단 주기, 추적 가능한 예외를 가진 제품으로 다루게 된다. 정책 배포는 감사에서 시작해 경고를 거친 뒤 점진적인 강제로 이어질 수 있다. 저자는 Argo CD 또는 Flux가 소유한 것으로 간주하는 리소스를 정책이 수정할 때 발생할 수 있는 조정 문제도 언급하며, 이로 인해 동기화 루프가 발생할 수 있다고 지적한다.
Oksay가 제시하는 결론은 Kyverno를 보안 가이드로만 읽으면 그 인터페이스와 기능의 상당 부분을 가리게 된다는 것이다. 그의 견해에서 Kyverno는 클러스터 입구에 서 있는 경비원이 아니라, 플랫폼 팀의 관점을 리소스와 애플리케이션의 실제 동작과 연결하는 계층이다.