Tetragon vs Falco, 런타임 보안 뭘 쓸까

런타임 보안을 도입한다고 하면 결국 두 갈래로 갈린다. Falco를 깔고 SIEM에 알람을 흘릴 거냐, Tetragon으로 정책 위반을 커널 레벨에서 막을 거냐. 우리 팀은 작년에 Falco부터 시작했고, 올해 초부터 일부 클러스터에 Tetragon을 같이 굴리고 있다. 둘 다 한참 써본 뒤 정리한 얘기를 풀어보려고 한다.

겉으로 보면 "둘 다 eBPF 쓰는 컨테이너 런타임 보안 툴"인데, 막상 운영하다 보면 결이 꽤 다르다.

출발점이 다르다: 감지냐, 차단이냐

가장 큰 차이는 단순하다. Falco는 알람을 쏘고, Tetragon은 막는다. 누가 더 좋다는 얘기가 아니다.

Falco는 시스템콜과 컨테이너 이벤트를 보고 "이런 일이 벌어졌다"고 통지한다. 비유하자면 CCTV다. 의심스러운 행위가 일어나면 알람을 띄우고, 그걸 SIEM이나 Slack으로 흘려서 사람이 보고 판단한다. 룰 엔진이 성숙해서 MITRE ATT&CK 매핑이나 CIS 벤치마크 같은 게 잘 정리돼 있다. 2024년에 CNCF Graduated로 올라간 만큼 운영 안정성도 검증됐고.

Tetragon은 다르다. eBPF로 커널 훅에 들어가 있다가, 정책에 매치되는 동작을 그 자리에서 차단할 수 있다. SIGKILL을 시그널로 쏘거나, bpf_send_signal로 실행 자체를 끊는 식이다. 비유하자면 출입통제 시스템이다. 막을 수 있다는 게 매력이지만, 그만큼 잘못 막으면 운영 사고가 난다.

이게 도구 선택의 핵심 분기점이다. "탐지에 집중하고 SOC가 판단할 거다"면 Falco가 자연스럽고, "탐지 자체가 곧 자동 차단이어야 한다"면 Tetragon이 맞다.

룰 작성 경험은 어떻게 다른가

Falco 룰은 YAML로 쓴다. condition expression이 익숙해지면 빠르게 짤 수 있다.

- rule: Shell spawned in container
  desc: Detect shell processes spawned inside containers
  condition: >
    spawned_process and container and
    proc.name in (sh, bash, zsh)
  output: >
    Shell in container (user=%user.name container=%container.name
    command=%proc.cmdline)
  priority: WARNING
  tags: [container, shell, mitre_execution]

읽기 편하고, 기존에 쌓인 커뮤니티 룰 셋이 두텁다. 다만 단점이 있는데, 알람이 클러스터 전역으로 뜬다. "이 네임스페이스만 예외 처리"를 하려면 condition을 점점 길게 늘여야 하고, 룰 파일이 금방 지저분해진다. 우리 팀도 한 6개월 운영하니까 false positive 정리하는 데 시간을 더 많이 쓰는 상태가 됐다.

Tetragon의 TracingPolicy는 Kubernetes CRD다.

apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: block-shell-in-prod
spec:
  podSelector:
    matchLabels:
      env: prod
  kprobes:
  - call: "sys_execve"
    syscall: true
    args:
    - index: 0
      type: "string"
    selectors:
    - matchArgs:
      - index: 0
        operator: "Postfix"
        values:
        - "/bash"
        - "/sh"
      matchActions:
      - action: Sigkill

podSelector로 적용 범위를 명시적으로 좁힐 수 있다는 점이 제일 다르다. Falco처럼 "전부 켜놓고 예외를 길게 쓰는" 방식이 아니라, "필요한 워크로드에만 정책을 붙이는" 방식. 운영 입장에서는 이게 진짜 편하다. 다만 selector 문법은 처음에 좀 어렵다. 우리 팀 주니어 친구는 첫 정책 짜는 데 반나절 걸렸다.

성능과 자원 사용

올해 초 ARMO 쪽 벤치마크나 우리 자체 측정을 종합해보면, 정상 부하 상태에서 노드당 CPU 점유는 비슷한 룰 셋을 기준으로 Tetragon이 0.7%, Falco가 1.4% 정도 나온다. 메모리는 오히려 Falco가 더 가볍게 나오는 경우도 있어서, "Tetragon이 무조건 빠르다"고 말하기는 애매하다.

다만 한 가지 확실한 건, Falco는 시스템콜 이벤트를 유저스페이스에서 후처리하는 비중이 크다. 트래픽이 많은 노드(예: 노드당 컨테이너 50개 이상에 RPS가 수천 단위)에서는 evt drop이 종종 발생한다. Tetragon은 커널 안에서 필터링과 액션을 끝내기 때문에 이 부분이 깔끔하다.

사실 우리 팀이 Tetragon을 들여다본 결정적 이유가 이거였다. 어느 날 Falco가 일부 노드에서 이벤트를 흘리고 있다는 걸 발견했는데, 추적해 보니 노드 부하 피크 시점에 syscall 큐가 밀려서 drop이 났던 거였다. 보안 도구가 "조용히 못 보고 있었다"는 게 제일 무서운 상황이다.

운영 통합과 알람 파이프라인

이건 Falco가 한참 앞선다. Falcosidekick 하나면 Slack, PagerDuty, Datadog, Elasticsearch, S3, 웬만한 SIEM에 다 붙는다. 우리도 작년에는 Falco → Falcosidekick → Loki + Slack 조합으로 충분했다.

Tetragon은 알람 통합이 아직 좀 거칠다. tetra CLI로 이벤트 스트림을 받거나, JSON 로그를 Fluent Bit/Vector로 긁어다 별도 파이프라인을 짜야 한다. Cilium의 Hubble과 통합하면 좀 낫지만, 그게 안 깔린 환경에서는 손이 한 번 더 간다. 우리는 결국 Tetragon 이벤트를 Vector로 받아서 Loki에 넣고, Grafana 대시보드를 따로 만들었다. 일이 늘었다.

그래서 우리 팀은 어떻게 결정했나

결론부터 말하자면 둘 다 쓴다. 처음엔 "한쪽으로 통일하자"는 의견이 강했는데, 한 분기 운영해 보고 나서 역할을 나누는 게 맞다는 쪽으로 정리됐다.

Falco는 클러스터 전역에 깔고, 광범위한 탐지와 규정 준수 리포팅 용도로 둔다. CIS Benchmark 매핑, 컨테이너 anomalous 행위 감지, 외부 SIEM 연동. 알람의 양은 많지만 false positive 필터링이 익숙해진 만큼 SOC 친구들도 별로 불평하지 않는다.

Tetragon은 특정 워크로드에만 붙인다. 결제, 인증 같이 "이 워크로드에서 이 행위가 나오면 일단 막아야 한다"가 명확한 곳. 예를 들어 결제 서비스 파드에서는 /etc/shadow 읽기를 시도하는 프로세스를 Sigkill로 즉시 끊는다. Falco 룰로 알람만 받았으면 SOC가 알아챘을 때는 이미 늦었을 수도 있다.

말하자면 Falco는 광역 CCTV, Tetragon은 금고실 출입통제다. 둘 다 필요한 거지, 어느 한쪽이 다른 쪽을 대체하지는 못한다는 게 우리 팀 결론이다.

도입을 고민하는 분들께

처음 도입하는 거라면 Falco부터 시작하는 걸 권한다. 운영 사고가 적고, 룰 자료가 풍부하고, 알람만 받는 거라 잘못 설정해도 워크로드는 안 죽는다. 일단 어떤 시그널이 나오는지 익숙해지는 게 먼저다.

탐지가 안정화되고, "이거는 무조건 막아야 한다"는 룰이 5~10개 정도 확실해진 시점에 Tetragon을 좁게 도입하는 게 합리적이다. 처음부터 Tetragon으로 일괄 enforce를 켜면 운영 사고가 거의 100% 한 번은 난다. 우리도 그랬다.

혹시 다른 조합으로 운영하시는 분 있으면 어떻게 구성하셨는지 궁금하다. Tracee를 같이 쓰는 케이스, Sysdig Secure로 통합하는 케이스 후기도 듣고 싶다.