Trivy Operator vs Kubescape, 6개월 굴려보고 내린 결정

 

비교를 시작한 배경

작년 말에 Falco vs Tetragon 한 번 정리하면서 런타임 쪽은 어느 정도 정해뒀는데, 정작 더 매일같이 쓰는 "posture/이미지 취약점 스캔" 쪽이 계속 어수선했다. 우리 팀은 한동안 Trivy Operator 단일로 굴렸고, 작년 4분기쯤 Kubescape가 CNCF Incubating에서 한 단계 더 성숙해지면서 한번 다시 들여다볼 만하다는 얘기가 사내에 돌았다. 그래서 두 도구를 운영 환경에 6개월 정도 병행해서 돌려봤다. 결론부터 말하면 "둘 다 쓰긴 쓰는데 역할이 갈렸다"는 거다. 이 글은 그 갈리는 지점이 어디였는지에 대한 기록이다.

전제는 이렇다. 클러스터는 EKS 1.31 두 개(prod/stg), 노드 합 60여 대, 워크로드 300개 안팎. 컴플라이언스는 내부 보안팀이 NSA Kubernetes Hardening Guide와 CIS Benchmark를 절반 정도 합쳐서 만든 자체 기준이 있다. CI 단에서 이미지 스캔은 별도로 Trivy CLI를 돌리고 있어서, 클러스터 안에서 잡고 싶은 건 (1) admission 단계의 misconfig 차단보다는 사후 가시성, (2) running 워크로드의 누적 취약점 트래킹, (3) 보안팀 보고용 posture 리포트, 이 세 가지였다.

Trivy Operator가 잘하는 것

Trivy Operator의 강점은 깔끔하다. CRD가 잘 정리돼 있어서 VulnerabilityReport, ConfigAuditReport, ClusterRbacAssessmentReport, ExposedSecretReport 같은 게 워크로드 단위로 떨어진다. 우리는 이걸 그대로 Prometheus exporter로 긁어서 Grafana에 띄우는데, 워크로드별 CVE 트렌드를 보는 데는 정말 편하다. 솔직히 이 부분만큼은 Kubescape보다 낫다고 본다. 이미지 단위 보고를 워크로드별로 1:1 매핑해주고, 같은 이미지를 여러 deployment가 쓰면 중복 스캔을 알아서 캐싱한다.

리소스 사용량도 의외로 가볍다. 60대 클러스터에서 trivy-operator 자체는 CPU 150m, 메모리 400Mi 정도로 안정적이었다. 다만 스캔 잡(scan-job) 자체가 노드에서 짧게 튀는 건 어쩔 수 없는데, OPERATOR_CONCURRENT_SCAN_JOBS_LIMIT를 5로 묶어두니 큰 문제는 없었다. 새 이미지가 한꺼번에 50개씩 배포되는 릴리스 직후가 좀 시끄러운 정도다.

그런데 이게 약점이기도 하다. Trivy Operator는 본질적으로 "스캐너의 결과를 CRD로 노출"하는 도구지, 그 결과를 가지고 컴플라이언스 점수를 만들어주지는 않는다. ClusterComplianceReport CRD가 있긴 한데, NSA 가이드 같은 게 yaml로 들어가 있는 형태라 우리 자체 기준을 얹기엔 매핑이 좀 거칠다. 그리고 NetworkPolicy 누락이나 PSA 라벨 검증 같은 "클러스터 수준 자세" 항목은 항목 수 자체가 적다. 워크로드 단위 검사에 비해 클러스터 단위 검사가 얕다.

Kubescape가 잘하는 것

반대로 Kubescape는 처음 깔자마자 NSA, MITRE, CIS, ArmoBest 프레임워크가 다 켜져서 점수가 쫙 나온다. CNCF 안에서 ARMO가 밀고 있는 컨트롤 라이브러리가 꽤 알차고, kubescape scan framework nsa 같은 식으로 프레임워크를 분리해서 돌릴 수 있는 게 보고서 만들 때 진짜 도움이 됐다. 보안팀이 분기마다 "NSA 가이드 기준 우리 클러스터 점수" 같은 걸 원하는데, Kubescape는 그게 그냥 한 줄 커맨드다.

특히 좋았던 건 kubescape scan --submit 없이 in-cluster 모드(kubescape-operator)로 돌렸을 때다. 컨트롤 결과가 ConfigurationScanSummary CRD로 떨어지는데, 여기서 컨트롤 ID별로 어떤 리소스가 위반인지가 명확하다. Trivy의 ConfigAuditReport보다 컨텍스트 정보가 풍부했다. 예를 들면 PSA 위반이 발생했을 때 "어떤 컨트롤의 어느 조항"인지까지 추적이 가능했다.

다만 단점도 분명했다. 첫째, 리소스를 꽤 먹는다. prod 클러스터에서 kubescape-operator 풀스택(operator + kubevuln + storage + node-agent) 합쳐서 메모리 2GB 가까이 갔다. 특히 node-agent는 eBPF로 런타임 정보를 수집하는데, 우리 워크로드 특성상 그건 Tetragon이랑 겹쳐서 결국 꺼버렸다. 둘째, 이미지 취약점 스캔(kubevuln) 결과는 Trivy Operator 쪽이 더 안정적이었다. 같은 이미지에서 CVE 카운트가 미묘하게 다르게 나오는 경우가 종종 있어서, 보안팀과 "어느 숫자가 맞느냐"로 잠깐 실랑이를 했다. 셋째, CRD 이름이 한 번씩 바뀐다. 마이너 버전 올라가면서 VulnerabilityManifest가 어디론가 옮겨가서 우리 exporter가 한 번 깨졌다.

그래서 우리는 둘 다 쓰기로 했다

처음엔 하나만 남기려고 했는데, 6개월쯤 굴려보니 책임 경계가 자연스럽게 갈렸다.

• 이미지 취약점 / 워크로드별 CVE 트래킹: Trivy Operator. CRD가 깔끔하고, 워크로드-이미지 매핑이 정확하고, exporter가 안정적이다. 개발팀이 매일 보는 대시보드는 여기서 나온다.
• 클러스터 컴플라이언스 / 프레임워크 점수: Kubescape. NSA/CIS 프레임워크 매핑이 압도적으로 풍부하다. 보안팀 분기 리포트는 여기서 뽑는다. 단, kubevuln과 node-agent는 꺼버렸다.

리소스 부담을 줄이려고 Kubescape는 prod에는 안 깔고 stg 클러스터에만 두고 주기적으로 스캔을 돌린다. 어차피 NSA 컨트롤 같은 건 prod/stg가 거의 동일하니까. 이미지 취약점 쪽은 prod가 본진이라 거기서만 본다.

이 분리가 깔끔하지는 않다. 같은 misconfiguration 항목을 두 도구가 다르게 잡아내는 경우도 있고, 두 도구 모두 똑같이 놓치는 항목도 분명히 있다. 그래서 분기마다 한 번씩 두 도구 결과를 diff 떠서 갭을 보는 일을 사내 노션 페이지에 따로 정리한다. 귀찮긴 한데 이게 가장 정직한 방법이긴 했다.

결론

DevSecOps 쪽 도구 선택은 보통 "하나로 다 되겠지" 기대로 시작했다가 "안 되는구나" 깨닫고 두 개 세 개를 붙이게 되는 흐름이 반복된다. 이번도 비슷했다. Trivy Operator는 워크로드 가시성, Kubescape는 프레임워크 점수 — 이렇게 역할을 가르면 둘 다 자기 일을 잘한다.

물론 우리 환경 기준이다. K8s만 보는 게 아니라 IaC, SBOM, Git까지 한 도구로 묶고 싶으면 Trivy 한쪽으로 더 쏠릴 거고, 반대로 NSA/MITRE 매핑 보고가 압도적으로 중요한 조직이면 Kubescape 하나로 갈 수도 있다. 정답은 없다. 다만 "한 도구로 컴플라이언스부터 CVE까지 다 되는 그림"은 적어도 우리한테는 환상이었다는 게 결론이다.

혹시 다른 조합 쓰시는 분 있으면 댓글로 알려주세요. 특히 Kyverno의 ImageVerification이나 Sigstore 쪽이랑 같이 묶어 운영하는 사례가 궁금하다.