Falco vs Tetragon, 둘 다 6개월 써본 결정

IT/DevSecOps

Falco vs Tetragon, 둘 다 6개월 써본 결정

gfrog 2026. 5. 28. 09:15

왜 단일화를 시도했나

작년 가을부터 클러스터 런타임 보안 도구를 다시 들여다보고 있었다. 그전까지 우리 팀은 Falco만 돌리고 있었는데, 알람이 너무 시끄러웠다. 새벽에 페이지가 울리면 열에 아홉은 false positive였고, 나머지 한 번도 사실 우리가 미처 룰을 안 다듬어서 생긴 노이즈였다. 보안팀이 받는 신뢰도가 점점 떨어지는 게 보였다.

그래서 Tetragon을 검토 후보로 올렸다. Isovalent(현재는 Cisco) 쪽에서 미는 eBPF 기반 도구고, Cilium을 이미 쓰고 있던 우리 환경이랑 잘 맞는다는 얘기가 컨퍼런스마다 나왔다. 결론부터 말하면 6개월 동안 둘을 병행해서 돌렸고, 지금은 둘 다 운영 중이다. 한쪽으로 단일화하려다가 다시 두 개 다 유지하기로 했는데, 그 과정에서 알게 된 것들을 정리해 본다.

처음 목표는 명확했다. "둘 다 유지하기엔 운영 비용이 너무 크다." 노드 100대 정도 되는 프로덕션 클러스터에 두 개의 DaemonSet을 깔아두면 일단 리소스부터 부담이다. Falco는 노드당 평균 메모리 200~300MB, CPU는 워크로드 따라 5~10% 정도 먹는다. Tetragon은 메모리는 비슷한데 CPU는 1% 미만이다. 이건 Tetragon이 처음부터 eBPF 커널 훅으로 동작하니까 당연한 결과다. Falco도 modern_ebpf 드라이버로 바꾸면 오버헤드가 줄긴 하는데, 이벤트 파싱이 결국 유저스페이스에서 일어나서 한계가 있다.

그런데 단순히 오버헤드만 보면 안 된다는 게 6개월 동안의 결론이다.

디텍션 커버리지가 다르다

처음 1개월은 둘이 같은 이벤트를 얼마나 잘 잡나 비교했다. 의도적으로 컨테이너 안에서 의심 행위를 재현하는 스크립트를 짜서 둘 다 알람이 오는지 확인했다. 결과는 흥미로웠다.

Falco가 더 잘 잡는 케이스는 쉘 명령어 패턴(예: curl | sh 같은 안티패턴), 컨테이너 내부에서 systemctl 호출하는 시도, /etc/shadow 같은 민감 파일 읽기 같은 것들이다.

Tetragon이 더 잘 잡는 케이스는 파일 디스크립터 리다이렉트로 우회한 쓰기(> /etc/passwd 같은 식), 컨테이너 탈출 시도(네임스페이스 조작), 프로세스 트리에서 부모-자식 관계가 끊긴 후의 행동 같은 패턴이다.

특히 두 번째 그룹이 우리한테 중요했다. 작년에 한 번 사고가 있었는데, 공격자가 셸 리다이렉트로 파일을 변조했고 Falco는 이걸 못 잡았다. 사후 분석 때 보니까 Falco의 syscall 파싱 레이어에서 open 다음에 따라오는 write가 임시 파일 경로를 통해서 일어나면 룰이 안 맞는 케이스가 있었다. 커널 레벨에서 inode 단위로 추적하는 Tetragon은 같은 시나리오를 재현했을 때 정확히 잡았다.

룰 작성 경험은 정반대

이게 운영자 관점에서 큰 차이다. Falco의 룰은 YAML로 쓰는데, 거의 SQL처럼 직관적이다.

- rule: Write below etc
  desc: an attempt to write to any file below /etc
  condition: >
    write_etc_common
    and not proc.name in (known_etc_writers)
  output: >
    File below /etc opened for writing (user=%user.name
    command=%proc.cmdline file=%fd.name)
  priority: ERROR

이런 식으로 평문에 가깝게 쓸 수 있어서 신입 SRE한테 인계할 때 부담이 적다. 그리고 falco-rules 커뮤니티 룰셋이 워낙 잘 되어 있어서 50% 정도는 가져다 쓰면 된다.

Tetragon은 다르다. TracingPolicy라는 CRD를 작성해야 하는데, 커널 내부 동작을 어느 정도 이해해야 한다.

apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: sensitive-file-write
spec:
  kprobes:
    - call: "security_file_permission"
      syscall: false
      args:
        - index: 0
          type: "file"
        - index: 1
          type: "int"
      selectors:
        - matchArgs:
            - index: 0
              operator: "Prefix"
              values:
                - "/etc/"
            - index: 1
              operator: "Equal"
              values:
                - "2"  # MAY_WRITE
          matchActions:
            - action: Sigkill

security_file_permission이 LSM 훅이라는 걸 알아야 하고, MAY_WRITE 상수가 뭔지 알아야 한다. 그리고 enforcement까지 가려면 Sigkill 같은 액션을 명시해야 하는데, 이게 잘못 쓰면 클러스터를 정지시킬 수 있다. 사실 우리 팀에서 한 번 룰 잘못 적어서 kubelet이 쓰는 디렉토리 접근에 SigKill을 걸어버린 적이 있었다. 노드가 NotReady로 빠지면서 멘탈이 나갔다.

그런데 익숙해지고 나면 이 강력함이 매력이다. 단순 알람을 넘어서 실제로 막을 수 있다. Falco는 본질적으로 디텍션 도구라 막는 건 외부 시스템(Falcosidekick + 사이드 액션)으로 위임해야 한다. Tetragon은 그게 한 도구 안에서 끝난다.

알람 노이즈 비교

이 부분이 제일 차이가 컸다. 동일한 워크로드에서 한 달 동안 모은 데이터다.

Falco는 알람 약 12,000건, 그중 실제 조사 가치 있는 건 35건(0.29%). Tetragon은 알람 약 1,800건, 그중 실제 조사 가치 있는 건 41건(2.28%).

Falco는 룰을 아무리 튜닝해도 컨테이너 빌드 도구, init 컨테이너, 정상적인 cron 같은 게 노이즈로 잡혔다. exclude 리스트를 늘리는 게 결국 진짜 공격 패턴까지 가리는 방향으로 흘렀다. Tetragon은 처음부터 컨테이너/파드 컨텍스트를 알고 동작하니까 같은 행위라도 어느 파드에서 누가 했는지 구분이 명확하다. 그래서 selector를 정교하게 짜기 좋다.

근데 Tetragon이 알람 적은 게 마냥 좋은 것만은 아니다. 우리가 룰을 안 짠 영역은 아예 안 본다는 뜻이기도 하다. Falco는 기본 룰셋이 워낙 광범위해서 "일단 켜두면" 뭐라도 본다. Tetragon은 명시적으로 적은 만큼만 본다. 보안팀이 룰 작성 리소스가 부족하면 Falco가 훨씬 안전한 선택이다.

그래서 왜 둘 다 유지하기로 했나

원래는 Tetragon으로 단일화하려고 했다. 그런데 다음 세 가지 이유로 결정을 뒤집었다.

첫째, Falco의 커뮤니티 룰셋과 즉시성을 포기할 수 없었다. 새로운 CVE가 터졌을 때 falco-rules 레포에 PR이 올라오는 속도가 정말 빠르다. 우리가 직접 TracingPolicy를 쓰는 것보다 훨씬 빠르게 대응 가능했다.

둘째, 감사 로그 요구사항. 컴플라이언스 쪽에서 "어떤 시점에 어떤 syscall이 발생했는지" 다 기록되어야 했는데, Falco의 audit_log 출력 포맷이 우리 SIEM이랑 더 잘 맞았다. Tetragon은 좋은 구조화된 이벤트를 내보내긴 하지만 SIEM 측 통합 코스트가 추가로 들었다.

셋째, 책임 분리. Falco는 보안팀이 룰을 관리하고, Tetragon은 플랫폼팀이 룰을 관리하는 식으로 자연스럽게 나뉘었다. 둘 다 같은 영역을 봤지만 관점이 달랐다. 보안팀은 "무엇이 일어났나"에 관심이 있고, 플랫폼팀은 "무엇을 막을 것인가"에 집중했다. 한 도구로 합쳤다면 이 경계가 모호해졌을 것 같다.

오버헤드는 둘 다 켜둔 상태에서 노드당 추가 비용이 메모리 400MB, CPU 5% 정도다. 큰 부담은 아니다. 그리고 알람 중복은 두 시스템의 알람을 키 기반으로 디둡하는 작은 컨슈머를 하나 만들어서 처리했다.

만약 다시 처음부터 고른다면

신규 클러스터에서 둘 중 하나만 고르라면 우리 팀 상황에서는 Tetragon을 먼저 깐다. 그리고 컴플라이언스가 강제되거나 룰 작성 인력이 부족할 때 Falco를 추가한다. 거꾸로 가지는 않을 것 같다. 이유는 단순하다. Tetragon이 enforcement까지 되니까 보안 도구의 가치가 더 크고, 룰 작성 학습 곡선만 넘으면 더 정확한 디텍션을 얻는다.

하지만 이건 우리 환경(Cilium 사용 중, 보안팀과 플랫폼팀 분리)에서의 판단이라는 점을 강조하고 싶다. Cilium을 안 쓰는 환경에서 Tetragon만 위해 Cilium 도입하는 건 추천하지 않는다. 그리고 보안팀이 SRE를 겸직하는 작은 조직이면 Falco가 운영하기 더 편하다.

혹시 비슷한 고민 하시는 분 있으면 어떤 환경에서 어떻게 결정했는지 댓글로 남겨주시면 좋겠다. 우리도 아직 6개월짜리 경험이라 모르는 게 더 많다.

저작자표시 비영리 동일조건 (새창열림)