쿼타랩 소개
사업 영역
제품
소식
채용
Kubeshark - API 트래픽 정밀 분석기
어플리케이션 수정 없이 Request, Response 관측할 수 있는 좋은 방법을 소개합니다
Jul 18, 2023
Kubeshark - API 트래픽 정밀 분석기
Kubeshark 도입기
Kubeshark란?
・ Kubeshark는 어떻게 동작하나요?
・ TLS의 평문을 확인한다?
・ Kubeshark Architecture
┗ Kubeshark Worker
┗ Kubeshark Hub
┗ Kubeshark Fronted
┗ Kubeshark CLIQuotaLab에서는 어떻게 활용했나요?
・ 개발환경의 트러블 슈팅
┗ CORS 추적
┗ 서버간 토큰 교환 추적
┗ 제 로컬에서는 재현이 안되는데요?를 방지합니다Kubeshark의 단점은?
・ 과도한 Resource 사용
・ Pod 내부 컨테이너간 통신 확인 불가
・ Official Helm Chart의 완성도
・ Kubeshark CLI
・ 글쓰는 시점에 해결된 것?
・ *Kubeshark는 Sniff 도구입니다. 개인정보 유출에 조심합시다. *끝내며
Ref.
안녕하세요 QuotaLab DevOps 챕터의 김동규입니다.
2023년에는 여전히 Kubernetes가 메가 트렌드로 자리 잡아 나가고 있고, QuotaLab 역시 Kubernetes를 활용해 모든 워크로드를 운영 중에 있어요.
Kubernetes를 통해 매우 편리한 운영 도구와 시스템을 누릴 수 있지만, Security best practice를 따르다 보면 디버깅과 트러블 슈팅 과정이 쉽지 않아진다는 것은 흔히 경험해 볼 수 있는 상황이죠.
예를 들어 Wireshark 한번 키면 바로 원인 파악이 가능한 상황이라거나, Shell 조차 없는 distroless 이미지를 사용하고 있어 접근조차 하지 못한 상황을 겪어보셨다면 이 글을 흥미 있게 읽게 되실 거예요.
그래서 이번 글에서는 Kubeshark라는 도구를 사용해 Kubernetes 환경에서 “별도의 어플리케이션 수정 없이” 트래픽을 분석할 수 있는 도구를 소개해드릴게요.
한마디로 표현하자면, Kubernetes를 위해 재창조된 TCPDump + Wireshark라고 생각하며 읽어주시면 좋겠습니다.
Kubeshark 도입기
최근 QuotaLab에서는 코프링 (Spring + Kotlin)을 기반으로 Spring Cloud Gateway 및 인증 레이어를 분리하는 프로젝트를 진행하고 있는데요. 요청이 실패한 경우 “어느 서비스에서 응답을 준 것인지”, “라우팅이 제대로 되긴 한 것인지”, “Gateway의 filter가 제대로 동작하여 http header 등이 적절하게 수정되었는지” 수많은 케이스를 머릿속으로 생각하며 “APM Trace”, “어플리케이션에서 로그를 추가해 배포”, “Istio의 Access Log 확인” 하는 과정을 반복하곤 했습니다.
여러분도 느끼시겠지만 이 과정은 매우 느리고, 효율적이지 못합니다. 운영 환경에서는 당연히 적절한 로그와 Trace를 통해 높은 가시성을 기반으로 추측할 수 있겠지만, 처음 개발 환경을 셋업 하는 과정에서 트러블슈팅에 시간을 소비하긴 너무 아까웠습니다.
긴 시간 비효율을 겪던 중, Kubeshark 프로젝트가 있던걸 기억해 내고 도움을 받아보기로 했습니다.
Kubeshark란?
Kubeshark is an API Traffic Analyzer for Kubernetes providing real-time, protocol-level visibility into Kubernetes’ internal network, capturing, dissecting and monitoring all traffic and payloads going in, out and across containers, pods, nodes and clusters.
Kubeshark는 Wireshark의 Kubernetes 버전이라고 이해하면 쉽습니다. kubectl debug 같은 도구와 달리 트래픽에 대한 정보를 실시간으로 상세히 확인할 수 있다는 장점이 있습니다.
특히 APM 같은 일반적인 모니터링 도구에서 확인하기 어려운 HTTP Header, Payload를 평문으로 확인할 수 있다는 점이 아주 매력적이었는데요.
TCPDump처럼 단순 패킷 덤프를 보여주는 것이 아닌 아래 프로토콜/기술에 대한 트래픽을 정규화 된 상태로 저장되고 검색할 수 있다는 점이 강력한 포인트였어요.
bookinfo 서비스로 도달되는 http 요청들
/details/0 요청에 대한 http request header
/details/0 요청에 대한 http request header
Kubeshark의 PoC를 위해 Istio Bookinfo(https://istio.io/latest/docs/examples/bookinfo/) 샘플 어플리케이션과 kubeshark를 실행해봤어요. Server간 요청에 대한 정보를 브라우저 개발자 도구를 킨 것 처럼 쉽게 확인할 수 있어요.
Kubeshark가 없었더라면, bookinfo의 소스코드를 찾아 분석해 봐야 했을 텐데, 쉽게 HTTP Response를 확인할 수 있게 되었죠.
(참고로 Kubeshark HTTP/1.0, HTTP/1.1, HTTP/2, (GRPC, Graphql), AMQP, Apache Kafka, Redis, DNS 에 대한 분석을 기능을 제공하고 있어요.)
Kubeshark는 어떻게 동작하나요?
https://ebpf.io/what-is-ebpf/
Kubeshark는 핵심 기능은 eBPF(확장 BPF)를 통해 구현되었으며 커널 공간과 유저 공간의 모니터링을 통해 강력한 인사이트를 제공하고 있어요.
kprobe를 사용해 TCP 커넥션에 대한 Source, Destination의 IP Port를 저장해 두었다가 수집된 Trace로부터 Request/Response를 하나로 묶어 보여주고, 실제 TCP 패킷은 분산 파일 시스템을 통해 PCAP 파일로 임시 저장하여 다운로드 받을 수도 있어요.
또한 TLS로 암호화된 패킷을 다루는 경우, 평문을 Kubeshark에서 확인할 수 있어요.
TLS의 평문을 확인한다?
https://github.com/kubeshark/worker/blob/b1964e7667682a2dbca550686c978d20e96435fd/tracer/bpf/tcp_kprobes.c#L108-L118
Kubeshark의 한 가지 특이한 점은 OpenSSL로 암호화된 TLS 트래픽을 스니핑할 수 있다는 것인데요, eBPF와 OpenSSL 라이브러리를 통해 구현되었습니다.
BPF를 통해 저장된 TCP 소켓에 대한 연결 정보를 기반으로, 보내는 메세지가 암호화되기 전, 받는 메세지의 TLS Termination이 끝난 후의 메세지를 캡쳐하여 평문으로 확인할 수 있도록 구현되어 있어요.
다만, 이 기능을 사용하려면 tls 옵션을 활성화해야 합니다.
분량상 생략하며 첨부하는 eBPF 관련 자료들입니다.
Kubeshark Architecture
https://docs.kubeshark.co/en/anatomy_of_kubeshark
Kubeshark는 크게 4가지 컴포넌트로 나누어져 있고, 각각의 역할을 이해하신다면 수월하게 Kubeshark를 설치하고 운영하실 수 있을 거예요.
Kubeshark Worker
Kubeshark Worker는 Daemonset 형태로 설치하고 네트워크 및 시스템 관련 권한과 /hostproc, /sys 디렉토리를 마운트 시켜야 합니다. 노드에서 발생하는 모든 네트워크 패킷의 모니터링을 위해 상당히 많은 권한이 위임됩니다.
(Kubernetes 클러스터 운영자분들은 Kubeshark Worker Pod에 대한 접근 권한을 최소한으로 조정해 주셔야 합니다)
Kubeshark Worker는 위임받은 권한을 토대로 eBPF의 kprobe와 uprobe를 사용해 커널 내부의 함수 및 이벤트에 hook을 설치하고 데이터를 수집, 가공하여 Kubeshark Hub로 보내는 역할을 합니다.
사실상 eBPF와 관련된 로직을 모두 포함하고 있는 모니터링 핵심 컴포넌트라고 할 수 있어요.
Kubeshark Hub
Kubeshark Hub의 클라이언트는 Web UI, CLI 이며 모니터링 대상과 스크립트 등을 Kubeshark Hub에 전달하고 Kubeshark Worker로부터 전달받은 여러 패킷 정보를 Websocket으로 전달해 브라우저에서 유저가 데이터를 확인할 수 있게 합니다.
Hub API는 HTTP API로 호출할 수 있으며, 별도의 인증 없이 Kubeshark Worker에 명령을 내리거나, 네트워크 Raw 데이터를 확보할 수 있으니, 반드시 아무나 호출할 수 없는 Private network에 설치하시길 추천드립니다.
Kubeshark Frontend
웹 브라우저를 통해 Kubeshark Hub와 통신하며 데이터를 검색, 탐색할 수 있습니다. 무료 버전을 사용하는 경우 인증 없이 접속할 수 있으니, Ingress를 설치해서 사용하시는 경우 인증 프록시를 앞단에 두고 사용하시길 추천드립니다.
Kubeshark CLI
Kubeshark를 설치, 삭제하거나 kubeshark tap이라는 명령어를 통해 모니터링을 시작할 수 있습니다. 대부분 Kubeshark Hub에게 HTTP 요청을 보내거나 Kubernetes Service와 port-forward 하는 간단한 동작을 수행합니다.
QuotaLab에서는 어떻게 활용했나요?
개발환경의 트러블슈팅
CORS 추적
Spring Gateway를 사용한 개발 환경 세팅 중에 발생하는 CORS 정책 오류로 인해 트러블 슈팅에 상당한 시간을 잡아먹을 뻔했어요
(CORS에 대한 설명은 QuotaLab 프론트엔드 챕터 리드이신 Evan의 블로그를 참고해 주시면 이해하시는 데 도움이 되실 거예요.)
AWS Application LoadBalancer, Istio, Spring Gateway, Authentication Server, QuotaBook API Server… 총 5개 컴포넌트에 대한 로그나 지표를 확인해야 하는 상황이었죠.
웹 브라우저에서는 CORS 에러와 함께 HTTP 요청에 대한 Response를 확인할 수 없는 상황이라 에러가 발생한 컴포넌트를 특정하기 쉽지 않았는데요.
초기 개발 중인 상태라 수집 중인 지표가 충분치 않았고, 로그를 일일이 찍어보기에는 시간이 부족했습니다.
Kubeshark를 통해 Spring Gateway의 Response Status Code는 200이지만, Response의 Access-Control-Allow-* 관련 헤더에 중복 값이 있는 것을 확인했고, Spring Gateway에 설정한 Spring Security 설정이 Relay된 요청의 Header를 Replace 하는 것이 아니라 Append를 하고 있어 발생하는 문제로 확인했습니다.
QuotaBook API 서버에서 CORS 설정을 제거하고 Spring Gateway로 일원화 시키는 선택도 있었으나, 마이그레이션 과정 중 언제든 롤백이 가능해야 한다는 점을 고려하여 Istio의 CORS 설정을 적용해 CORS 관련 헤더를 응답을 주기 전 Replace 하는 것으로 해결하였습니다.
서버간 토큰 교환 추적
Spring Gateway의 필터에서 클라이언트가 보낸 인증 코드를 JWT로 교환하는 로직을 구현해 두었고, 교환된 JWT에는 유저 컨텍스트가 담긴 채로 마이크로서비스에 전달되는 상황을 기대하고 있는데요.
마이크로서비스가 제대로 Authentication 서버를 통해 교환된 JWT를 파싱 하지 못하는 이슈가 발생했습니다. 인증 코드가 JWT로 교환되지 않았거나, JWT 자체가 잘못되었을 가능성 등…. 다양한 가능성을 고려해야 했고,
Spring Gatway, Authentication Server, MicroService, Istio Proxy 총 4개의 컴포넌트 중 범인을 찾아야 하는 상황이 발생했습니다.
당연하게도 브라우저의 네트워크 탭에서는 서버 간의 토큰 교환 로직을 확인할 수 없지만, Kubeshark에는 서버 간 통신의 Request, Response Header를 직접 확인할 수 있어 문제 구간을 추적하기가 매우 쉬웠습니다.
제 로컬에서는 재현이 안되는데요? 를 방지합니다
특정 브라우저나 특정 유저에게만 발생하는 서버 이슈를 만났을 때 Kubeshark를 켜 놓는다면 굳이 개발자의 로컬에서 재현할 필요 없이 서버사이드에서 에러 구간을 빠르게 찾아내어 TCP 패킷을 Replay 할 수 있고, TCP Dump를 다운로드해 Wireshark로 패킷을 확인해 볼 수도 있습니다.
물론 이런 방식의 트러블 슈팅은 데이터나 로직의 이슈까지 찾아낼 순 없지만, 역시나 구간을 특정하는 데 시간을 매우 효과적입니다.
문제의 재현을 위해 cURL 커맨드를 주고받고, 브라우저의 개발자 도구의 스크린샷을 요구하는 등의 협업이 보다 아름답게 변화할 수 있습니다.
Kubeshark의 단점은?
과도한 Resource 사용
kubeshark tap의 대상 Pod가 너무 많은 경우 Network, Memory 자원을 과도하게 사용할 수 있습니다.
특히 클라우드에서 인프라를 운영하고 있다면 네트워크 I/O는 비용과 직결되기 때문에 PoC를 할 때에도 유의하시는 것이 좋습니다.
kubeshark tap의 대상 Namespace 혹은 Pod Name Regex를 정확히 작성하여 필요로 하는 Pod의 Trace만을 획득하도록 설정하시는 것을 추천합니다.
Pod 내부 컨테이너간 통신 확인 불가
Kubeshark로는 Pod 내부 컨테이너 간 통신 내용 추적이 불가능합니다.
특히 Istio 같은 도구를 사용하는 경우 불편한 점이 생길 수 있는데요, Source 트래픽이 어떤 service에 의해 발생했는지 알 수 없습니다.
Istio에 의해 Request/Response 내용이 변경되는 것 역시 확인할 수 없어, 유추를 통해 트러블슈팅을 해야 합니다.
Official Helm Chart의 완성도
https://github.com/kubeshark/kubeshark/tree/master/helm-chart
Kubernetes에 능숙한 고급 사용자라면 Kubeshark CLI를 통해 설치하는 방식을 빠르게 포기하시게 될 텐데요.
Node selector, Toleration 지정이 어렵고 Container Image Tag가 latest 로 고정되어 있는 등. 장기적으로 운영할 계획이 있다면 Helm chart를 통한 설치를 고려해야 하는데요. 이 차트의 완성도가 높지 않습니다.
Frontend, Hub가 Deployment가 아닌 Pod 형태로 배포됨
불필요하게 host port를 사용함
컴포넌트 별로 컨테이너 이미지 Tag를 지정할 수 없음
Namespace 리소스를 제외할 수 없음.
Frontend의 REACT_APP_HUB_HOST , REACT_APP_HUB_PORT 변수 수정 불가.
QuotaLab에서는 Official Helm Chart를 참고하여 원하는 요소를 수정한 뒤 설치하여 사용하고 있고, Kubeshark CLI는 사용하지 않습니다.
Kubeshark는 빠르게 성장하고 변화하는 프로젝트이며, 기능 추가 및 변경 역시 과격하게 진행됩니다. Helm을 직접 수정하여 버전을 고정하지 않았다면 latest로 자동 업데이트되기 때문에 무언가 제대로 동작하지 않는 상황을 자주 만나볼 수 있습니다.
Kubeshark CLI
Kubeshark CLI는 Kubernetes 운영자가 아닌 사람들에게 사용을 권장하기 쉽지 않습니다.
kubeshark tap 커맨드를 사용한 동작 방식은 편하지만 보안 및 비용 관점의 리스크를 고려하여 CLI 사용을 권장하고 싶지 않습니다.
kube-system, secret-store와 같이 마이크로서비스를 개발하고 운영하는 분들에게 권한을 부여하지 않은 컴포넌트의 트래픽을 Sniff할 수 있다는 보안 관점의 리스크와, Tap의 범위를 전체 클러스터로 두어 너무 많은 네트워크 비용이 발생할 수 있는 상황을 컨트롤할 수 없다는 단점이 존재합니다.
QuotaLab에서는, 도입 초기엔 DevOps 엔지니어가 트러블 슈팅에 함께 참여하는 방식으로 해결하고, 추후엔 Kubeshark Hub API를 대신 호출하는 DevOps Platform을 도입하여 개발자분들이 Tracing 하고자 하는 Namespace, Pod name regex와 Tracing 기간을 받아 관리하는 방식으로 개선해나갈 예정입니다.
참고로, kubeshark tap 은 아래와 같은 API를 사용하여 동일한 효과를 볼 수 있습니다.
글 쓰는 시점에 해결된 것?
Kubeshark Frontend와 Kubeshark Hub 간의 통신을 ws가 아닌 wss 통신하고자 하면 Kubeshark Frontend 소스코드의 하드코딩된 프로토콜을 변경한 후 직접 빌드 한 버전을 사용해야 했습니다.
Helm에서 Daemonset Pod에서 PVC 사용이 강제되어 있었습니다. Kubeshark CLI를 사용해 설치하던 시점이라 Daemonset에서 PVC를 요구하며 제대로 프로비저닝 되지 않아 상당히 당황스러웠습니다. (이 시점을 기준으로 직접 Chart를 수정해서 사용했습니다.)
*Kubeshark는 Sniff 도구입니다. 개인정보 유출에 조심합시다.*
API로 주고받는 모든 요청을 평문으로 확인할 수 있는 강력한 도구인 만큼, 사용하는데 각별히 주의가 필요합니다.
운영 환경에서 도입은 정말 깊게 고민해 보셔야 하며, 개발 환경에서 사용할 때에도 동료분들이 자주 사용하는 비밀번호, 주민등록번호와 같이 중요한 정보들이 쉽게 노출될 수 있습니다.
이러한 이유로 QuotaLab에서는 절대로 운영 환경에서 Kubeshark를 사용하지 않습니다.
끝내며
네트워크 모니터링 도구로 반드시 Kubeshark를 써야 하는 것은 아닙니다. Sysdig Falco, Cilium Tetragon 과 같은 eBPF를 사용한 강력한 도구들이 존재합니다.
Runtime Secutity, SIEM 관점에서는 위 도구들이 Kubeshark보다 나은 대안이 될 수 있습니다만, 개발 환경에서의 트러블 슈팅에는 Kubeshark가 확실한 강점을 보여줍니다.
개발 환경에서 복잡한 문제를 해결하기 위해 시간을 낭비해 보셨다면 한 번쯤 Kubeshark를 사용해 보시길 추천드리고 싶습니다.
Ref.
벤처금융 인프라를 함께 만들어 나갈 동료를 찾습니다.
쿼타랩 채용 바로가기
Daniel
DevOps Engineering
최고의 DevOps팀을 만들기 위해 고군분투 하고 있습니다
Kubeshark - API 트래픽 정밀 분석기
어플리케이션 수정 없이 Request, Response 관측할 수 있는 좋은 방법을 소개합니다
Jul 18, 2023
Kubeshark - API 트래픽 정밀 분석기
Kubeshark 도입기
Kubeshark란?
・ Kubeshark는 어떻게 동작하나요?
・ TLS의 평문을 확인한다?
・ Kubeshark Architecture
┗ Kubeshark Worker
┗ Kubeshark Hub
┗ Kubeshark Fronted
┗ Kubeshark CLIQuotaLab에서는 어떻게 활용했나요?
・ 개발환경의 트러블 슈팅
┗ CORS 추적
┗ 서버간 토큰 교환 추적
┗ 제 로컬에서는 재현이 안되는데요?를 방지합니다Kubeshark의 단점은?
・ 과도한 Resource 사용
・ Pod 내부 컨테이너간 통신 확인 불가
・ Official Helm Chart의 완성도
・ Kubeshark CLI
・ 글쓰는 시점에 해결된 것?
・ *Kubeshark는 Sniff 도구입니다. 개인정보 유출에 조심합시다. *끝내며
Ref.
안녕하세요 QuotaLab DevOps 챕터의 김동규입니다.
2023년에는 여전히 Kubernetes가 메가 트렌드로 자리 잡아 나가고 있고, QuotaLab 역시 Kubernetes를 활용해 모든 워크로드를 운영 중에 있어요.
Kubernetes를 통해 매우 편리한 운영 도구와 시스템을 누릴 수 있지만, Security best practice를 따르다 보면 디버깅과 트러블 슈팅 과정이 쉽지 않아진다는 것은 흔히 경험해 볼 수 있는 상황이죠.
예를 들어 Wireshark 한번 키면 바로 원인 파악이 가능한 상황이라거나, Shell 조차 없는 distroless 이미지를 사용하고 있어 접근조차 하지 못한 상황을 겪어보셨다면 이 글을 흥미 있게 읽게 되실 거예요.
그래서 이번 글에서는 Kubeshark라는 도구를 사용해 Kubernetes 환경에서 “별도의 어플리케이션 수정 없이” 트래픽을 분석할 수 있는 도구를 소개해드릴게요.
한마디로 표현하자면, Kubernetes를 위해 재창조된 TCPDump + Wireshark라고 생각하며 읽어주시면 좋겠습니다.
Kubeshark 도입기
최근 QuotaLab에서는 코프링 (Spring + Kotlin)을 기반으로 Spring Cloud Gateway 및 인증 레이어를 분리하는 프로젝트를 진행하고 있는데요. 요청이 실패한 경우 “어느 서비스에서 응답을 준 것인지”, “라우팅이 제대로 되긴 한 것인지”, “Gateway의 filter가 제대로 동작하여 http header 등이 적절하게 수정되었는지” 수많은 케이스를 머릿속으로 생각하며 “APM Trace”, “어플리케이션에서 로그를 추가해 배포”, “Istio의 Access Log 확인” 하는 과정을 반복하곤 했습니다.
여러분도 느끼시겠지만 이 과정은 매우 느리고, 효율적이지 못합니다. 운영 환경에서는 당연히 적절한 로그와 Trace를 통해 높은 가시성을 기반으로 추측할 수 있겠지만, 처음 개발 환경을 셋업 하는 과정에서 트러블슈팅에 시간을 소비하긴 너무 아까웠습니다.
긴 시간 비효율을 겪던 중, Kubeshark 프로젝트가 있던걸 기억해 내고 도움을 받아보기로 했습니다.
Kubeshark란?
Kubeshark is an API Traffic Analyzer for Kubernetes providing real-time, protocol-level visibility into Kubernetes’ internal network, capturing, dissecting and monitoring all traffic and payloads going in, out and across containers, pods, nodes and clusters.
Kubeshark는 Wireshark의 Kubernetes 버전이라고 이해하면 쉽습니다. kubectl debug 같은 도구와 달리 트래픽에 대한 정보를 실시간으로 상세히 확인할 수 있다는 장점이 있습니다.
특히 APM 같은 일반적인 모니터링 도구에서 확인하기 어려운 HTTP Header, Payload를 평문으로 확인할 수 있다는 점이 아주 매력적이었는데요.
TCPDump처럼 단순 패킷 덤프를 보여주는 것이 아닌 아래 프로토콜/기술에 대한 트래픽을 정규화 된 상태로 저장되고 검색할 수 있다는 점이 강력한 포인트였어요.
bookinfo 서비스로 도달되는 http 요청들
/details/0 요청에 대한 http request header
/details/0 요청에 대한 http request header
Kubeshark의 PoC를 위해 Istio Bookinfo(https://istio.io/latest/docs/examples/bookinfo/) 샘플 어플리케이션과 kubeshark를 실행해봤어요. Server간 요청에 대한 정보를 브라우저 개발자 도구를 킨 것 처럼 쉽게 확인할 수 있어요.
Kubeshark가 없었더라면, bookinfo의 소스코드를 찾아 분석해 봐야 했을 텐데, 쉽게 HTTP Response를 확인할 수 있게 되었죠.
(참고로 Kubeshark HTTP/1.0, HTTP/1.1, HTTP/2, (GRPC, Graphql), AMQP, Apache Kafka, Redis, DNS 에 대한 분석을 기능을 제공하고 있어요.)
Kubeshark는 어떻게 동작하나요?
https://ebpf.io/what-is-ebpf/
Kubeshark는 핵심 기능은 eBPF(확장 BPF)를 통해 구현되었으며 커널 공간과 유저 공간의 모니터링을 통해 강력한 인사이트를 제공하고 있어요.
kprobe를 사용해 TCP 커넥션에 대한 Source, Destination의 IP Port를 저장해 두었다가 수집된 Trace로부터 Request/Response를 하나로 묶어 보여주고, 실제 TCP 패킷은 분산 파일 시스템을 통해 PCAP 파일로 임시 저장하여 다운로드 받을 수도 있어요.
또한 TLS로 암호화된 패킷을 다루는 경우, 평문을 Kubeshark에서 확인할 수 있어요.
TLS의 평문을 확인한다?
https://github.com/kubeshark/worker/blob/b1964e7667682a2dbca550686c978d20e96435fd/tracer/bpf/tcp_kprobes.c#L108-L118
Kubeshark의 한 가지 특이한 점은 OpenSSL로 암호화된 TLS 트래픽을 스니핑할 수 있다는 것인데요, eBPF와 OpenSSL 라이브러리를 통해 구현되었습니다.
BPF를 통해 저장된 TCP 소켓에 대한 연결 정보를 기반으로, 보내는 메세지가 암호화되기 전, 받는 메세지의 TLS Termination이 끝난 후의 메세지를 캡쳐하여 평문으로 확인할 수 있도록 구현되어 있어요.
다만, 이 기능을 사용하려면 tls 옵션을 활성화해야 합니다.
분량상 생략하며 첨부하는 eBPF 관련 자료들입니다.
Kubeshark Architecture
https://docs.kubeshark.co/en/anatomy_of_kubeshark
Kubeshark는 크게 4가지 컴포넌트로 나누어져 있고, 각각의 역할을 이해하신다면 수월하게 Kubeshark를 설치하고 운영하실 수 있을 거예요.
Kubeshark Worker
Kubeshark Worker는 Daemonset 형태로 설치하고 네트워크 및 시스템 관련 권한과 /hostproc, /sys 디렉토리를 마운트 시켜야 합니다. 노드에서 발생하는 모든 네트워크 패킷의 모니터링을 위해 상당히 많은 권한이 위임됩니다.
(Kubernetes 클러스터 운영자분들은 Kubeshark Worker Pod에 대한 접근 권한을 최소한으로 조정해 주셔야 합니다)
Kubeshark Worker는 위임받은 권한을 토대로 eBPF의 kprobe와 uprobe를 사용해 커널 내부의 함수 및 이벤트에 hook을 설치하고 데이터를 수집, 가공하여 Kubeshark Hub로 보내는 역할을 합니다.
사실상 eBPF와 관련된 로직을 모두 포함하고 있는 모니터링 핵심 컴포넌트라고 할 수 있어요.
Kubeshark Hub
Kubeshark Hub의 클라이언트는 Web UI, CLI 이며 모니터링 대상과 스크립트 등을 Kubeshark Hub에 전달하고 Kubeshark Worker로부터 전달받은 여러 패킷 정보를 Websocket으로 전달해 브라우저에서 유저가 데이터를 확인할 수 있게 합니다.
Hub API는 HTTP API로 호출할 수 있으며, 별도의 인증 없이 Kubeshark Worker에 명령을 내리거나, 네트워크 Raw 데이터를 확보할 수 있으니, 반드시 아무나 호출할 수 없는 Private network에 설치하시길 추천드립니다.
Kubeshark Frontend
웹 브라우저를 통해 Kubeshark Hub와 통신하며 데이터를 검색, 탐색할 수 있습니다. 무료 버전을 사용하는 경우 인증 없이 접속할 수 있으니, Ingress를 설치해서 사용하시는 경우 인증 프록시를 앞단에 두고 사용하시길 추천드립니다.
Kubeshark CLI
Kubeshark를 설치, 삭제하거나 kubeshark tap이라는 명령어를 통해 모니터링을 시작할 수 있습니다. 대부분 Kubeshark Hub에게 HTTP 요청을 보내거나 Kubernetes Service와 port-forward 하는 간단한 동작을 수행합니다.
QuotaLab에서는 어떻게 활용했나요?
개발환경의 트러블슈팅
CORS 추적
Spring Gateway를 사용한 개발 환경 세팅 중에 발생하는 CORS 정책 오류로 인해 트러블 슈팅에 상당한 시간을 잡아먹을 뻔했어요
(CORS에 대한 설명은 QuotaLab 프론트엔드 챕터 리드이신 Evan의 블로그를 참고해 주시면 이해하시는 데 도움이 되실 거예요.)
AWS Application LoadBalancer, Istio, Spring Gateway, Authentication Server, QuotaBook API Server… 총 5개 컴포넌트에 대한 로그나 지표를 확인해야 하는 상황이었죠.
웹 브라우저에서는 CORS 에러와 함께 HTTP 요청에 대한 Response를 확인할 수 없는 상황이라 에러가 발생한 컴포넌트를 특정하기 쉽지 않았는데요.
초기 개발 중인 상태라 수집 중인 지표가 충분치 않았고, 로그를 일일이 찍어보기에는 시간이 부족했습니다.
Kubeshark를 통해 Spring Gateway의 Response Status Code는 200이지만, Response의 Access-Control-Allow-* 관련 헤더에 중복 값이 있는 것을 확인했고, Spring Gateway에 설정한 Spring Security 설정이 Relay된 요청의 Header를 Replace 하는 것이 아니라 Append를 하고 있어 발생하는 문제로 확인했습니다.
QuotaBook API 서버에서 CORS 설정을 제거하고 Spring Gateway로 일원화 시키는 선택도 있었으나, 마이그레이션 과정 중 언제든 롤백이 가능해야 한다는 점을 고려하여 Istio의 CORS 설정을 적용해 CORS 관련 헤더를 응답을 주기 전 Replace 하는 것으로 해결하였습니다.
서버간 토큰 교환 추적
Spring Gateway의 필터에서 클라이언트가 보낸 인증 코드를 JWT로 교환하는 로직을 구현해 두었고, 교환된 JWT에는 유저 컨텍스트가 담긴 채로 마이크로서비스에 전달되는 상황을 기대하고 있는데요.
마이크로서비스가 제대로 Authentication 서버를 통해 교환된 JWT를 파싱 하지 못하는 이슈가 발생했습니다. 인증 코드가 JWT로 교환되지 않았거나, JWT 자체가 잘못되었을 가능성 등…. 다양한 가능성을 고려해야 했고,
Spring Gatway, Authentication Server, MicroService, Istio Proxy 총 4개의 컴포넌트 중 범인을 찾아야 하는 상황이 발생했습니다.
당연하게도 브라우저의 네트워크 탭에서는 서버 간의 토큰 교환 로직을 확인할 수 없지만, Kubeshark에는 서버 간 통신의 Request, Response Header를 직접 확인할 수 있어 문제 구간을 추적하기가 매우 쉬웠습니다.
제 로컬에서는 재현이 안되는데요? 를 방지합니다
특정 브라우저나 특정 유저에게만 발생하는 서버 이슈를 만났을 때 Kubeshark를 켜 놓는다면 굳이 개발자의 로컬에서 재현할 필요 없이 서버사이드에서 에러 구간을 빠르게 찾아내어 TCP 패킷을 Replay 할 수 있고, TCP Dump를 다운로드해 Wireshark로 패킷을 확인해 볼 수도 있습니다.
물론 이런 방식의 트러블 슈팅은 데이터나 로직의 이슈까지 찾아낼 순 없지만, 역시나 구간을 특정하는 데 시간을 매우 효과적입니다.
문제의 재현을 위해 cURL 커맨드를 주고받고, 브라우저의 개발자 도구의 스크린샷을 요구하는 등의 협업이 보다 아름답게 변화할 수 있습니다.
Kubeshark의 단점은?
과도한 Resource 사용
kubeshark tap의 대상 Pod가 너무 많은 경우 Network, Memory 자원을 과도하게 사용할 수 있습니다.
특히 클라우드에서 인프라를 운영하고 있다면 네트워크 I/O는 비용과 직결되기 때문에 PoC를 할 때에도 유의하시는 것이 좋습니다.
kubeshark tap의 대상 Namespace 혹은 Pod Name Regex를 정확히 작성하여 필요로 하는 Pod의 Trace만을 획득하도록 설정하시는 것을 추천합니다.
Pod 내부 컨테이너간 통신 확인 불가
Kubeshark로는 Pod 내부 컨테이너 간 통신 내용 추적이 불가능합니다.
특히 Istio 같은 도구를 사용하는 경우 불편한 점이 생길 수 있는데요, Source 트래픽이 어떤 service에 의해 발생했는지 알 수 없습니다.
Istio에 의해 Request/Response 내용이 변경되는 것 역시 확인할 수 없어, 유추를 통해 트러블슈팅을 해야 합니다.
Official Helm Chart의 완성도
https://github.com/kubeshark/kubeshark/tree/master/helm-chart
Kubernetes에 능숙한 고급 사용자라면 Kubeshark CLI를 통해 설치하는 방식을 빠르게 포기하시게 될 텐데요.
Node selector, Toleration 지정이 어렵고 Container Image Tag가 latest 로 고정되어 있는 등. 장기적으로 운영할 계획이 있다면 Helm chart를 통한 설치를 고려해야 하는데요. 이 차트의 완성도가 높지 않습니다.
Frontend, Hub가 Deployment가 아닌 Pod 형태로 배포됨
불필요하게 host port를 사용함
컴포넌트 별로 컨테이너 이미지 Tag를 지정할 수 없음
Namespace 리소스를 제외할 수 없음.
Frontend의 REACT_APP_HUB_HOST , REACT_APP_HUB_PORT 변수 수정 불가.
QuotaLab에서는 Official Helm Chart를 참고하여 원하는 요소를 수정한 뒤 설치하여 사용하고 있고, Kubeshark CLI는 사용하지 않습니다.
Kubeshark는 빠르게 성장하고 변화하는 프로젝트이며, 기능 추가 및 변경 역시 과격하게 진행됩니다. Helm을 직접 수정하여 버전을 고정하지 않았다면 latest로 자동 업데이트되기 때문에 무언가 제대로 동작하지 않는 상황을 자주 만나볼 수 있습니다.
Kubeshark CLI
Kubeshark CLI는 Kubernetes 운영자가 아닌 사람들에게 사용을 권장하기 쉽지 않습니다.
kubeshark tap 커맨드를 사용한 동작 방식은 편하지만 보안 및 비용 관점의 리스크를 고려하여 CLI 사용을 권장하고 싶지 않습니다.
kube-system, secret-store와 같이 마이크로서비스를 개발하고 운영하는 분들에게 권한을 부여하지 않은 컴포넌트의 트래픽을 Sniff할 수 있다는 보안 관점의 리스크와, Tap의 범위를 전체 클러스터로 두어 너무 많은 네트워크 비용이 발생할 수 있는 상황을 컨트롤할 수 없다는 단점이 존재합니다.
QuotaLab에서는, 도입 초기엔 DevOps 엔지니어가 트러블 슈팅에 함께 참여하는 방식으로 해결하고, 추후엔 Kubeshark Hub API를 대신 호출하는 DevOps Platform을 도입하여 개발자분들이 Tracing 하고자 하는 Namespace, Pod name regex와 Tracing 기간을 받아 관리하는 방식으로 개선해나갈 예정입니다.
참고로, kubeshark tap 은 아래와 같은 API를 사용하여 동일한 효과를 볼 수 있습니다.
글 쓰는 시점에 해결된 것?
Kubeshark Frontend와 Kubeshark Hub 간의 통신을 ws가 아닌 wss 통신하고자 하면 Kubeshark Frontend 소스코드의 하드코딩된 프로토콜을 변경한 후 직접 빌드 한 버전을 사용해야 했습니다.
Helm에서 Daemonset Pod에서 PVC 사용이 강제되어 있었습니다. Kubeshark CLI를 사용해 설치하던 시점이라 Daemonset에서 PVC를 요구하며 제대로 프로비저닝 되지 않아 상당히 당황스러웠습니다. (이 시점을 기준으로 직접 Chart를 수정해서 사용했습니다.)
*Kubeshark는 Sniff 도구입니다. 개인정보 유출에 조심합시다.*
API로 주고받는 모든 요청을 평문으로 확인할 수 있는 강력한 도구인 만큼, 사용하는데 각별히 주의가 필요합니다.
운영 환경에서 도입은 정말 깊게 고민해 보셔야 하며, 개발 환경에서 사용할 때에도 동료분들이 자주 사용하는 비밀번호, 주민등록번호와 같이 중요한 정보들이 쉽게 노출될 수 있습니다.
이러한 이유로 QuotaLab에서는 절대로 운영 환경에서 Kubeshark를 사용하지 않습니다.
끝내며
네트워크 모니터링 도구로 반드시 Kubeshark를 써야 하는 것은 아닙니다. Sysdig Falco, Cilium Tetragon 과 같은 eBPF를 사용한 강력한 도구들이 존재합니다.
Runtime Secutity, SIEM 관점에서는 위 도구들이 Kubeshark보다 나은 대안이 될 수 있습니다만, 개발 환경에서의 트러블 슈팅에는 Kubeshark가 확실한 강점을 보여줍니다.
개발 환경에서 복잡한 문제를 해결하기 위해 시간을 낭비해 보셨다면 한 번쯤 Kubeshark를 사용해 보시길 추천드리고 싶습니다.
Ref.
벤처금융 인프라를 함께 만들어 나갈 동료를 찾습니다.
쿼타랩 채용 바로가기
Daniel
DevOps Engineering
최고의 DevOps팀을 만들기 위해 고군분투 하고 있습니다
쿼타랩 소개
사업 영역
제품
소식
채용
쿼타랩 소개
사업 영역
제품
소식
채용
Kubeshark - API 트래픽 정밀 분석기
어플리케이션 수정 없이 Request, Response 관측할 수 있는 좋은 방법을 소개합니다
Daniel
·
DevOps Engineering
최고의 DevOps팀을 만들기 위해 고군분투 하고 있습니다
Kubeshark - API 트래픽 정밀 분석기
Kubeshark 도입기
Kubeshark란?
・ Kubeshark는 어떻게 동작하나요?
・ TLS의 평문을 확인한다?
・ Kubeshark Architecture
┗ Kubeshark Worker
┗ Kubeshark Hub
┗ Kubeshark Fronted
┗ Kubeshark CLIQuotaLab에서는 어떻게 활용했나요?
・ 개발환경의 트러블 슈팅
┗ CORS 추적
┗ 서버간 토큰 교환 추적
┗ 제 로컬에서는 재현이 안되는데요?를 방지합니다Kubeshark의 단점은?
・ 과도한 Resource 사용
・ Pod 내부 컨테이너간 통신 확인 불가
・ Official Helm Chart의 완성도
・ Kubeshark CLI
・ 글쓰는 시점에 해결된 것?
・ *Kubeshark는 Sniff 도구입니다. 개인정보 유출에 조심합시다. *끝내며
Ref.
안녕하세요 QuotaLab DevOps 챕터의 김동규입니다.
2023년에는 여전히 Kubernetes가 메가 트렌드로 자리 잡아 나가고 있고, QuotaLab 역시 Kubernetes를 활용해 모든 워크로드를 운영 중에 있어요.
Kubernetes를 통해 매우 편리한 운영 도구와 시스템을 누릴 수 있지만, Security best practice를 따르다 보면 디버깅과 트러블 슈팅 과정이 쉽지 않아진다는 것은 흔히 경험해 볼 수 있는 상황이죠.
예를 들어 Wireshark 한번 키면 바로 원인 파악이 가능한 상황이라거나, Shell 조차 없는 distroless 이미지를 사용하고 있어 접근조차 하지 못한 상황을 겪어보셨다면 이 글을 흥미 있게 읽게 되실 거예요.
그래서 이번 글에서는 Kubeshark라는 도구를 사용해 Kubernetes 환경에서 “별도의 어플리케이션 수정 없이” 트래픽을 분석할 수 있는 도구를 소개해드릴게요.
한마디로 표현하자면, Kubernetes를 위해 재창조된 TCPDump + Wireshark라고 생각하며 읽어주시면 좋겠습니다.
Kubeshark 도입기
최근 QuotaLab에서는 코프링 (Spring + Kotlin)을 기반으로 Spring Cloud Gateway 및 인증 레이어를 분리하는 프로젝트를 진행하고 있는데요. 요청이 실패한 경우 “어느 서비스에서 응답을 준 것인지”, “라우팅이 제대로 되긴 한 것인지”, “Gateway의 filter가 제대로 동작하여 http header 등이 적절하게 수정되었는지” 수많은 케이스를 머릿속으로 생각하며 “APM Trace”, “어플리케이션에서 로그를 추가해 배포”, “Istio의 Access Log 확인” 하는 과정을 반복하곤 했습니다.
여러분도 느끼시겠지만 이 과정은 매우 느리고, 효율적이지 못합니다. 운영 환경에서는 당연히 적절한 로그와 Trace를 통해 높은 가시성을 기반으로 추측할 수 있겠지만, 처음 개발 환경을 셋업 하는 과정에서 트러블슈팅에 시간을 소비하긴 너무 아까웠습니다.
긴 시간 비효율을 겪던 중, Kubeshark 프로젝트가 있던걸 기억해 내고 도움을 받아보기로 했습니다.
Kubeshark란?
Kubeshark is an API Traffic Analyzer for Kubernetes providing real-time, protocol-level visibility into Kubernetes’ internal network, capturing, dissecting and monitoring all traffic and payloads going in, out and across containers, pods, nodes and clusters.
Kubeshark는 Wireshark의 Kubernetes 버전이라고 이해하면 쉽습니다. kubectl debug 같은 도구와 달리 트래픽에 대한 정보를 실시간으로 상세히 확인할 수 있다는 장점이 있습니다.
특히 APM 같은 일반적인 모니터링 도구에서 확인하기 어려운 HTTP Header, Payload를 평문으로 확인할 수 있다는 점이 아주 매력적이었는데요.
TCPDump처럼 단순 패킷 덤프를 보여주는 것이 아닌 아래 프로토콜/기술에 대한 트래픽을 정규화 된 상태로 저장되고 검색할 수 있다는 점이 강력한 포인트였어요.
bookinfo 서비스로 도달되는 http 요청들
/details/0 요청에 대한 http request header
/details/0 요청에 대한 http request header
Kubeshark의 PoC를 위해 Istio Bookinfo(https://istio.io/latest/docs/examples/bookinfo/) 샘플 어플리케이션과 kubeshark를 실행해봤어요. Server간 요청에 대한 정보를 브라우저 개발자 도구를 킨 것 처럼 쉽게 확인할 수 있어요.
Kubeshark가 없었더라면, bookinfo의 소스코드를 찾아 분석해 봐야 했을 텐데, 쉽게 HTTP Response를 확인할 수 있게 되었죠.
(참고로 Kubeshark HTTP/1.0, HTTP/1.1, HTTP/2, (GRPC, Graphql), AMQP, Apache Kafka, Redis, DNS 에 대한 분석을 기능을 제공하고 있어요.)
Kubeshark는 어떻게 동작하나요?
https://ebpf.io/what-is-ebpf/
Kubeshark는 핵심 기능은 eBPF(확장 BPF)를 통해 구현되었으며 커널 공간과 유저 공간의 모니터링을 통해 강력한 인사이트를 제공하고 있어요.
kprobe를 사용해 TCP 커넥션에 대한 Source, Destination의 IP Port를 저장해 두었다가 수집된 Trace로부터 Request/Response를 하나로 묶어 보여주고, 실제 TCP 패킷은 분산 파일 시스템을 통해 PCAP 파일로 임시 저장하여 다운로드 받을 수도 있어요.
또한 TLS로 암호화된 패킷을 다루는 경우, 평문을 Kubeshark에서 확인할 수 있어요.
TLS의 평문을 확인한다?
https://github.com/kubeshark/worker/blob/b1964e7667682a2dbca550686c978d20e96435fd/tracer/bpf/tcp_kprobes.c#L108-L118
Kubeshark의 한 가지 특이한 점은 OpenSSL로 암호화된 TLS 트래픽을 스니핑할 수 있다는 것인데요, eBPF와 OpenSSL 라이브러리를 통해 구현되었습니다.
BPF를 통해 저장된 TCP 소켓에 대한 연결 정보를 기반으로, 보내는 메세지가 암호화되기 전, 받는 메세지의 TLS Termination이 끝난 후의 메세지를 캡쳐하여 평문으로 확인할 수 있도록 구현되어 있어요.
다만, 이 기능을 사용하려면 tls 옵션을 활성화해야 합니다.
분량상 생략하며 첨부하는 eBPF 관련 자료들입니다.
Kubeshark Architecture
https://docs.kubeshark.co/en/anatomy_of_kubeshark
Kubeshark는 크게 4가지 컴포넌트로 나누어져 있고, 각각의 역할을 이해하신다면 수월하게 Kubeshark를 설치하고 운영하실 수 있을 거예요.
Kubeshark Worker
Kubeshark Worker는 Daemonset 형태로 설치하고 네트워크 및 시스템 관련 권한과 /hostproc, /sys 디렉토리를 마운트 시켜야 합니다. 노드에서 발생하는 모든 네트워크 패킷의 모니터링을 위해 상당히 많은 권한이 위임됩니다.
(Kubernetes 클러스터 운영자분들은 Kubeshark Worker Pod에 대한 접근 권한을 최소한으로 조정해 주셔야 합니다)
Kubeshark Worker는 위임받은 권한을 토대로 eBPF의 kprobe와 uprobe를 사용해 커널 내부의 함수 및 이벤트에 hook을 설치하고 데이터를 수집, 가공하여 Kubeshark Hub로 보내는 역할을 합니다.
사실상 eBPF와 관련된 로직을 모두 포함하고 있는 모니터링 핵심 컴포넌트라고 할 수 있어요.
Kubeshark Hub
Kubeshark Hub의 클라이언트는 Web UI, CLI 이며 모니터링 대상과 스크립트 등을 Kubeshark Hub에 전달하고 Kubeshark Worker로부터 전달받은 여러 패킷 정보를 Websocket으로 전달해 브라우저에서 유저가 데이터를 확인할 수 있게 합니다.
Hub API는 HTTP API로 호출할 수 있으며, 별도의 인증 없이 Kubeshark Worker에 명령을 내리거나, 네트워크 Raw 데이터를 확보할 수 있으니, 반드시 아무나 호출할 수 없는 Private network에 설치하시길 추천드립니다.
Kubeshark Frontend
웹 브라우저를 통해 Kubeshark Hub와 통신하며 데이터를 검색, 탐색할 수 있습니다. 무료 버전을 사용하는 경우 인증 없이 접속할 수 있으니, Ingress를 설치해서 사용하시는 경우 인증 프록시를 앞단에 두고 사용하시길 추천드립니다.
Kubeshark CLI
Kubeshark를 설치, 삭제하거나 kubeshark tap이라는 명령어를 통해 모니터링을 시작할 수 있습니다. 대부분 Kubeshark Hub에게 HTTP 요청을 보내거나 Kubernetes Service와 port-forward 하는 간단한 동작을 수행합니다.
QuotaLab에서는 어떻게 활용했나요?
개발환경의 트러블슈팅
CORS 추적
Spring Gateway를 사용한 개발 환경 세팅 중에 발생하는 CORS 정책 오류로 인해 트러블 슈팅에 상당한 시간을 잡아먹을 뻔했어요
(CORS에 대한 설명은 QuotaLab 프론트엔드 챕터 리드이신 Evan의 블로그를 참고해 주시면 이해하시는 데 도움이 되실 거예요.)
AWS Application LoadBalancer, Istio, Spring Gateway, Authentication Server, QuotaBook API Server… 총 5개 컴포넌트에 대한 로그나 지표를 확인해야 하는 상황이었죠.
웹 브라우저에서는 CORS 에러와 함께 HTTP 요청에 대한 Response를 확인할 수 없는 상황이라 에러가 발생한 컴포넌트를 특정하기 쉽지 않았는데요.
초기 개발 중인 상태라 수집 중인 지표가 충분치 않았고, 로그를 일일이 찍어보기에는 시간이 부족했습니다.
Kubeshark를 통해 Spring Gateway의 Response Status Code는 200이지만, Response의 Access-Control-Allow-* 관련 헤더에 중복 값이 있는 것을 확인했고, Spring Gateway에 설정한 Spring Security 설정이 Relay된 요청의 Header를 Replace 하는 것이 아니라 Append를 하고 있어 발생하는 문제로 확인했습니다.
QuotaBook API 서버에서 CORS 설정을 제거하고 Spring Gateway로 일원화 시키는 선택도 있었으나, 마이그레이션 과정 중 언제든 롤백이 가능해야 한다는 점을 고려하여 Istio의 CORS 설정을 적용해 CORS 관련 헤더를 응답을 주기 전 Replace 하는 것으로 해결하였습니다.
서버간 토큰 교환 추적
Spring Gateway의 필터에서 클라이언트가 보낸 인증 코드를 JWT로 교환하는 로직을 구현해 두었고, 교환된 JWT에는 유저 컨텍스트가 담긴 채로 마이크로서비스에 전달되는 상황을 기대하고 있는데요.
마이크로서비스가 제대로 Authentication 서버를 통해 교환된 JWT를 파싱 하지 못하는 이슈가 발생했습니다. 인증 코드가 JWT로 교환되지 않았거나, JWT 자체가 잘못되었을 가능성 등…. 다양한 가능성을 고려해야 했고,
Spring Gatway, Authentication Server, MicroService, Istio Proxy 총 4개의 컴포넌트 중 범인을 찾아야 하는 상황이 발생했습니다.
당연하게도 브라우저의 네트워크 탭에서는 서버 간의 토큰 교환 로직을 확인할 수 없지만, Kubeshark에는 서버 간 통신의 Request, Response Header를 직접 확인할 수 있어 문제 구간을 추적하기가 매우 쉬웠습니다.
제 로컬에서는 재현이 안되는데요? 를 방지합니다
특정 브라우저나 특정 유저에게만 발생하는 서버 이슈를 만났을 때 Kubeshark를 켜 놓는다면 굳이 개발자의 로컬에서 재현할 필요 없이 서버사이드에서 에러 구간을 빠르게 찾아내어 TCP 패킷을 Replay 할 수 있고, TCP Dump를 다운로드해 Wireshark로 패킷을 확인해 볼 수도 있습니다.
물론 이런 방식의 트러블 슈팅은 데이터나 로직의 이슈까지 찾아낼 순 없지만, 역시나 구간을 특정하는 데 시간을 매우 효과적입니다.
문제의 재현을 위해 cURL 커맨드를 주고받고, 브라우저의 개발자 도구의 스크린샷을 요구하는 등의 협업이 보다 아름답게 변화할 수 있습니다.
Kubeshark의 단점은?
과도한 Resource 사용
kubeshark tap의 대상 Pod가 너무 많은 경우 Network, Memory 자원을 과도하게 사용할 수 있습니다.
특히 클라우드에서 인프라를 운영하고 있다면 네트워크 I/O는 비용과 직결되기 때문에 PoC를 할 때에도 유의하시는 것이 좋습니다.
kubeshark tap의 대상 Namespace 혹은 Pod Name Regex를 정확히 작성하여 필요로 하는 Pod의 Trace만을 획득하도록 설정하시는 것을 추천합니다.
Pod 내부 컨테이너간 통신 확인 불가
Kubeshark로는 Pod 내부 컨테이너 간 통신 내용 추적이 불가능합니다.
특히 Istio 같은 도구를 사용하는 경우 불편한 점이 생길 수 있는데요, Source 트래픽이 어떤 service에 의해 발생했는지 알 수 없습니다.
Istio에 의해 Request/Response 내용이 변경되는 것 역시 확인할 수 없어, 유추를 통해 트러블슈팅을 해야 합니다.
Official Helm Chart의 완성도
https://github.com/kubeshark/kubeshark/tree/master/helm-chart
Kubernetes에 능숙한 고급 사용자라면 Kubeshark CLI를 통해 설치하는 방식을 빠르게 포기하시게 될 텐데요.
Node selector, Toleration 지정이 어렵고 Container Image Tag가 latest 로 고정되어 있는 등. 장기적으로 운영할 계획이 있다면 Helm chart를 통한 설치를 고려해야 하는데요. 이 차트의 완성도가 높지 않습니다.
Frontend, Hub가 Deployment가 아닌 Pod 형태로 배포됨
불필요하게 host port를 사용함
컴포넌트 별로 컨테이너 이미지 Tag를 지정할 수 없음
Namespace 리소스를 제외할 수 없음.
Frontend의 REACT_APP_HUB_HOST , REACT_APP_HUB_PORT 변수 수정 불가.
QuotaLab에서는 Official Helm Chart를 참고하여 원하는 요소를 수정한 뒤 설치하여 사용하고 있고, Kubeshark CLI는 사용하지 않습니다.
Kubeshark는 빠르게 성장하고 변화하는 프로젝트이며, 기능 추가 및 변경 역시 과격하게 진행됩니다. Helm을 직접 수정하여 버전을 고정하지 않았다면 latest로 자동 업데이트되기 때문에 무언가 제대로 동작하지 않는 상황을 자주 만나볼 수 있습니다.
Kubeshark CLI
Kubeshark CLI는 Kubernetes 운영자가 아닌 사람들에게 사용을 권장하기 쉽지 않습니다.
kubeshark tap 커맨드를 사용한 동작 방식은 편하지만 보안 및 비용 관점의 리스크를 고려하여 CLI 사용을 권장하고 싶지 않습니다.
kube-system, secret-store와 같이 마이크로서비스를 개발하고 운영하는 분들에게 권한을 부여하지 않은 컴포넌트의 트래픽을 Sniff할 수 있다는 보안 관점의 리스크와, Tap의 범위를 전체 클러스터로 두어 너무 많은 네트워크 비용이 발생할 수 있는 상황을 컨트롤할 수 없다는 단점이 존재합니다.
QuotaLab에서는, 도입 초기엔 DevOps 엔지니어가 트러블 슈팅에 함께 참여하는 방식으로 해결하고, 추후엔 Kubeshark Hub API를 대신 호출하는 DevOps Platform을 도입하여 개발자분들이 Tracing 하고자 하는 Namespace, Pod name regex와 Tracing 기간을 받아 관리하는 방식으로 개선해나갈 예정입니다.
참고로, kubeshark tap 은 아래와 같은 API를 사용하여 동일한 효과를 볼 수 있습니다.
글 쓰는 시점에 해결된 것?
Kubeshark Frontend와 Kubeshark Hub 간의 통신을 ws가 아닌 wss 통신하고자 하면 Kubeshark Frontend 소스코드의 하드코딩된 프로토콜을 변경한 후 직접 빌드 한 버전을 사용해야 했습니다.
Helm에서 Daemonset Pod에서 PVC 사용이 강제되어 있었습니다. Kubeshark CLI를 사용해 설치하던 시점이라 Daemonset에서 PVC를 요구하며 제대로 프로비저닝 되지 않아 상당히 당황스러웠습니다. (이 시점을 기준으로 직접 Chart를 수정해서 사용했습니다.)
*Kubeshark는 Sniff 도구입니다. 개인정보 유출에 조심합시다.*
API로 주고받는 모든 요청을 평문으로 확인할 수 있는 강력한 도구인 만큼, 사용하는데 각별히 주의가 필요합니다.
운영 환경에서 도입은 정말 깊게 고민해 보셔야 하며, 개발 환경에서 사용할 때에도 동료분들이 자주 사용하는 비밀번호, 주민등록번호와 같이 중요한 정보들이 쉽게 노출될 수 있습니다.
이러한 이유로 QuotaLab에서는 절대로 운영 환경에서 Kubeshark를 사용하지 않습니다.
끝내며
네트워크 모니터링 도구로 반드시 Kubeshark를 써야 하는 것은 아닙니다. Sysdig Falco, Cilium Tetragon 과 같은 eBPF를 사용한 강력한 도구들이 존재합니다.
Runtime Secutity, SIEM 관점에서는 위 도구들이 Kubeshark보다 나은 대안이 될 수 있습니다만, 개발 환경에서의 트러블 슈팅에는 Kubeshark가 확실한 강점을 보여줍니다.
개발 환경에서 복잡한 문제를 해결하기 위해 시간을 낭비해 보셨다면 한 번쯤 Kubeshark를 사용해 보시길 추천드리고 싶습니다.
Ref.
벤처금융 인프라를 함께 만들어 나갈 동료를 찾습니다.
쿼타랩 채용 바로가기
Kubeshark - API 트래픽 정밀 분석기
어플리케이션 수정 없이 Request, Response 관측할 수 있는 좋은 방법을 소개합니다
Daniel
·
DevOps Engineering
최고의 DevOps팀을 만들기 위해 고군분투 하고 있습니다
Kubeshark - API 트래픽 정밀 분석기
Kubeshark 도입기
Kubeshark란?
・ Kubeshark는 어떻게 동작하나요?
・ TLS의 평문을 확인한다?
・ Kubeshark Architecture
┗ Kubeshark Worker
┗ Kubeshark Hub
┗ Kubeshark Fronted
┗ Kubeshark CLIQuotaLab에서는 어떻게 활용했나요?
・ 개발환경의 트러블 슈팅
┗ CORS 추적
┗ 서버간 토큰 교환 추적
┗ 제 로컬에서는 재현이 안되는데요?를 방지합니다Kubeshark의 단점은?
・ 과도한 Resource 사용
・ Pod 내부 컨테이너간 통신 확인 불가
・ Official Helm Chart의 완성도
・ Kubeshark CLI
・ 글쓰는 시점에 해결된 것?
・ *Kubeshark는 Sniff 도구입니다. 개인정보 유출에 조심합시다. *끝내며
Ref.
안녕하세요 QuotaLab DevOps 챕터의 김동규입니다.
2023년에는 여전히 Kubernetes가 메가 트렌드로 자리 잡아 나가고 있고, QuotaLab 역시 Kubernetes를 활용해 모든 워크로드를 운영 중에 있어요.
Kubernetes를 통해 매우 편리한 운영 도구와 시스템을 누릴 수 있지만, Security best practice를 따르다 보면 디버깅과 트러블 슈팅 과정이 쉽지 않아진다는 것은 흔히 경험해 볼 수 있는 상황이죠.
예를 들어 Wireshark 한번 키면 바로 원인 파악이 가능한 상황이라거나, Shell 조차 없는 distroless 이미지를 사용하고 있어 접근조차 하지 못한 상황을 겪어보셨다면 이 글을 흥미 있게 읽게 되실 거예요.
그래서 이번 글에서는 Kubeshark라는 도구를 사용해 Kubernetes 환경에서 “별도의 어플리케이션 수정 없이” 트래픽을 분석할 수 있는 도구를 소개해드릴게요.
한마디로 표현하자면, Kubernetes를 위해 재창조된 TCPDump + Wireshark라고 생각하며 읽어주시면 좋겠습니다.
Kubeshark 도입기
최근 QuotaLab에서는 코프링 (Spring + Kotlin)을 기반으로 Spring Cloud Gateway 및 인증 레이어를 분리하는 프로젝트를 진행하고 있는데요. 요청이 실패한 경우 “어느 서비스에서 응답을 준 것인지”, “라우팅이 제대로 되긴 한 것인지”, “Gateway의 filter가 제대로 동작하여 http header 등이 적절하게 수정되었는지” 수많은 케이스를 머릿속으로 생각하며 “APM Trace”, “어플리케이션에서 로그를 추가해 배포”, “Istio의 Access Log 확인” 하는 과정을 반복하곤 했습니다.
여러분도 느끼시겠지만 이 과정은 매우 느리고, 효율적이지 못합니다. 운영 환경에서는 당연히 적절한 로그와 Trace를 통해 높은 가시성을 기반으로 추측할 수 있겠지만, 처음 개발 환경을 셋업 하는 과정에서 트러블슈팅에 시간을 소비하긴 너무 아까웠습니다.
긴 시간 비효율을 겪던 중, Kubeshark 프로젝트가 있던걸 기억해 내고 도움을 받아보기로 했습니다.
Kubeshark란?
Kubeshark is an API Traffic Analyzer for Kubernetes providing real-time, protocol-level visibility into Kubernetes’ internal network, capturing, dissecting and monitoring all traffic and payloads going in, out and across containers, pods, nodes and clusters.
Kubeshark는 Wireshark의 Kubernetes 버전이라고 이해하면 쉽습니다. kubectl debug 같은 도구와 달리 트래픽에 대한 정보를 실시간으로 상세히 확인할 수 있다는 장점이 있습니다.
특히 APM 같은 일반적인 모니터링 도구에서 확인하기 어려운 HTTP Header, Payload를 평문으로 확인할 수 있다는 점이 아주 매력적이었는데요.
TCPDump처럼 단순 패킷 덤프를 보여주는 것이 아닌 아래 프로토콜/기술에 대한 트래픽을 정규화 된 상태로 저장되고 검색할 수 있다는 점이 강력한 포인트였어요.
bookinfo 서비스로 도달되는 http 요청들
/details/0 요청에 대한 http request header
/details/0 요청에 대한 http request header
Kubeshark의 PoC를 위해 Istio Bookinfo(https://istio.io/latest/docs/examples/bookinfo/) 샘플 어플리케이션과 kubeshark를 실행해봤어요. Server간 요청에 대한 정보를 브라우저 개발자 도구를 킨 것 처럼 쉽게 확인할 수 있어요.
Kubeshark가 없었더라면, bookinfo의 소스코드를 찾아 분석해 봐야 했을 텐데, 쉽게 HTTP Response를 확인할 수 있게 되었죠.
(참고로 Kubeshark HTTP/1.0, HTTP/1.1, HTTP/2, (GRPC, Graphql), AMQP, Apache Kafka, Redis, DNS 에 대한 분석을 기능을 제공하고 있어요.)
Kubeshark는 어떻게 동작하나요?
https://ebpf.io/what-is-ebpf/
Kubeshark는 핵심 기능은 eBPF(확장 BPF)를 통해 구현되었으며 커널 공간과 유저 공간의 모니터링을 통해 강력한 인사이트를 제공하고 있어요.
kprobe를 사용해 TCP 커넥션에 대한 Source, Destination의 IP Port를 저장해 두었다가 수집된 Trace로부터 Request/Response를 하나로 묶어 보여주고, 실제 TCP 패킷은 분산 파일 시스템을 통해 PCAP 파일로 임시 저장하여 다운로드 받을 수도 있어요.
또한 TLS로 암호화된 패킷을 다루는 경우, 평문을 Kubeshark에서 확인할 수 있어요.
TLS의 평문을 확인한다?
https://github.com/kubeshark/worker/blob/b1964e7667682a2dbca550686c978d20e96435fd/tracer/bpf/tcp_kprobes.c#L108-L118
Kubeshark의 한 가지 특이한 점은 OpenSSL로 암호화된 TLS 트래픽을 스니핑할 수 있다는 것인데요, eBPF와 OpenSSL 라이브러리를 통해 구현되었습니다.
BPF를 통해 저장된 TCP 소켓에 대한 연결 정보를 기반으로, 보내는 메세지가 암호화되기 전, 받는 메세지의 TLS Termination이 끝난 후의 메세지를 캡쳐하여 평문으로 확인할 수 있도록 구현되어 있어요.
다만, 이 기능을 사용하려면 tls 옵션을 활성화해야 합니다.
분량상 생략하며 첨부하는 eBPF 관련 자료들입니다.
Kubeshark Architecture
https://docs.kubeshark.co/en/anatomy_of_kubeshark
Kubeshark는 크게 4가지 컴포넌트로 나누어져 있고, 각각의 역할을 이해하신다면 수월하게 Kubeshark를 설치하고 운영하실 수 있을 거예요.
Kubeshark Worker
Kubeshark Worker는 Daemonset 형태로 설치하고 네트워크 및 시스템 관련 권한과 /hostproc, /sys 디렉토리를 마운트 시켜야 합니다. 노드에서 발생하는 모든 네트워크 패킷의 모니터링을 위해 상당히 많은 권한이 위임됩니다.
(Kubernetes 클러스터 운영자분들은 Kubeshark Worker Pod에 대한 접근 권한을 최소한으로 조정해 주셔야 합니다)
Kubeshark Worker는 위임받은 권한을 토대로 eBPF의 kprobe와 uprobe를 사용해 커널 내부의 함수 및 이벤트에 hook을 설치하고 데이터를 수집, 가공하여 Kubeshark Hub로 보내는 역할을 합니다.
사실상 eBPF와 관련된 로직을 모두 포함하고 있는 모니터링 핵심 컴포넌트라고 할 수 있어요.
Kubeshark Hub
Kubeshark Hub의 클라이언트는 Web UI, CLI 이며 모니터링 대상과 스크립트 등을 Kubeshark Hub에 전달하고 Kubeshark Worker로부터 전달받은 여러 패킷 정보를 Websocket으로 전달해 브라우저에서 유저가 데이터를 확인할 수 있게 합니다.
Hub API는 HTTP API로 호출할 수 있으며, 별도의 인증 없이 Kubeshark Worker에 명령을 내리거나, 네트워크 Raw 데이터를 확보할 수 있으니, 반드시 아무나 호출할 수 없는 Private network에 설치하시길 추천드립니다.
Kubeshark Frontend
웹 브라우저를 통해 Kubeshark Hub와 통신하며 데이터를 검색, 탐색할 수 있습니다. 무료 버전을 사용하는 경우 인증 없이 접속할 수 있으니, Ingress를 설치해서 사용하시는 경우 인증 프록시를 앞단에 두고 사용하시길 추천드립니다.
Kubeshark CLI
Kubeshark를 설치, 삭제하거나 kubeshark tap이라는 명령어를 통해 모니터링을 시작할 수 있습니다. 대부분 Kubeshark Hub에게 HTTP 요청을 보내거나 Kubernetes Service와 port-forward 하는 간단한 동작을 수행합니다.
QuotaLab에서는 어떻게 활용했나요?
개발환경의 트러블슈팅
CORS 추적
Spring Gateway를 사용한 개발 환경 세팅 중에 발생하는 CORS 정책 오류로 인해 트러블 슈팅에 상당한 시간을 잡아먹을 뻔했어요
(CORS에 대한 설명은 QuotaLab 프론트엔드 챕터 리드이신 Evan의 블로그를 참고해 주시면 이해하시는 데 도움이 되실 거예요.)
AWS Application LoadBalancer, Istio, Spring Gateway, Authentication Server, QuotaBook API Server… 총 5개 컴포넌트에 대한 로그나 지표를 확인해야 하는 상황이었죠.
웹 브라우저에서는 CORS 에러와 함께 HTTP 요청에 대한 Response를 확인할 수 없는 상황이라 에러가 발생한 컴포넌트를 특정하기 쉽지 않았는데요.
초기 개발 중인 상태라 수집 중인 지표가 충분치 않았고, 로그를 일일이 찍어보기에는 시간이 부족했습니다.
Kubeshark를 통해 Spring Gateway의 Response Status Code는 200이지만, Response의 Access-Control-Allow-* 관련 헤더에 중복 값이 있는 것을 확인했고, Spring Gateway에 설정한 Spring Security 설정이 Relay된 요청의 Header를 Replace 하는 것이 아니라 Append를 하고 있어 발생하는 문제로 확인했습니다.
QuotaBook API 서버에서 CORS 설정을 제거하고 Spring Gateway로 일원화 시키는 선택도 있었으나, 마이그레이션 과정 중 언제든 롤백이 가능해야 한다는 점을 고려하여 Istio의 CORS 설정을 적용해 CORS 관련 헤더를 응답을 주기 전 Replace 하는 것으로 해결하였습니다.
서버간 토큰 교환 추적
Spring Gateway의 필터에서 클라이언트가 보낸 인증 코드를 JWT로 교환하는 로직을 구현해 두었고, 교환된 JWT에는 유저 컨텍스트가 담긴 채로 마이크로서비스에 전달되는 상황을 기대하고 있는데요.
마이크로서비스가 제대로 Authentication 서버를 통해 교환된 JWT를 파싱 하지 못하는 이슈가 발생했습니다. 인증 코드가 JWT로 교환되지 않았거나, JWT 자체가 잘못되었을 가능성 등…. 다양한 가능성을 고려해야 했고,
Spring Gatway, Authentication Server, MicroService, Istio Proxy 총 4개의 컴포넌트 중 범인을 찾아야 하는 상황이 발생했습니다.
당연하게도 브라우저의 네트워크 탭에서는 서버 간의 토큰 교환 로직을 확인할 수 없지만, Kubeshark에는 서버 간 통신의 Request, Response Header를 직접 확인할 수 있어 문제 구간을 추적하기가 매우 쉬웠습니다.
제 로컬에서는 재현이 안되는데요? 를 방지합니다
특정 브라우저나 특정 유저에게만 발생하는 서버 이슈를 만났을 때 Kubeshark를 켜 놓는다면 굳이 개발자의 로컬에서 재현할 필요 없이 서버사이드에서 에러 구간을 빠르게 찾아내어 TCP 패킷을 Replay 할 수 있고, TCP Dump를 다운로드해 Wireshark로 패킷을 확인해 볼 수도 있습니다.
물론 이런 방식의 트러블 슈팅은 데이터나 로직의 이슈까지 찾아낼 순 없지만, 역시나 구간을 특정하는 데 시간을 매우 효과적입니다.
문제의 재현을 위해 cURL 커맨드를 주고받고, 브라우저의 개발자 도구의 스크린샷을 요구하는 등의 협업이 보다 아름답게 변화할 수 있습니다.
Kubeshark의 단점은?
과도한 Resource 사용
kubeshark tap의 대상 Pod가 너무 많은 경우 Network, Memory 자원을 과도하게 사용할 수 있습니다.
특히 클라우드에서 인프라를 운영하고 있다면 네트워크 I/O는 비용과 직결되기 때문에 PoC를 할 때에도 유의하시는 것이 좋습니다.
kubeshark tap의 대상 Namespace 혹은 Pod Name Regex를 정확히 작성하여 필요로 하는 Pod의 Trace만을 획득하도록 설정하시는 것을 추천합니다.
Pod 내부 컨테이너간 통신 확인 불가
Kubeshark로는 Pod 내부 컨테이너 간 통신 내용 추적이 불가능합니다.
특히 Istio 같은 도구를 사용하는 경우 불편한 점이 생길 수 있는데요, Source 트래픽이 어떤 service에 의해 발생했는지 알 수 없습니다.
Istio에 의해 Request/Response 내용이 변경되는 것 역시 확인할 수 없어, 유추를 통해 트러블슈팅을 해야 합니다.
Official Helm Chart의 완성도
https://github.com/kubeshark/kubeshark/tree/master/helm-chart
Kubernetes에 능숙한 고급 사용자라면 Kubeshark CLI를 통해 설치하는 방식을 빠르게 포기하시게 될 텐데요.
Node selector, Toleration 지정이 어렵고 Container Image Tag가 latest 로 고정되어 있는 등. 장기적으로 운영할 계획이 있다면 Helm chart를 통한 설치를 고려해야 하는데요. 이 차트의 완성도가 높지 않습니다.
Frontend, Hub가 Deployment가 아닌 Pod 형태로 배포됨
불필요하게 host port를 사용함
컴포넌트 별로 컨테이너 이미지 Tag를 지정할 수 없음
Namespace 리소스를 제외할 수 없음.
Frontend의 REACT_APP_HUB_HOST , REACT_APP_HUB_PORT 변수 수정 불가.
QuotaLab에서는 Official Helm Chart를 참고하여 원하는 요소를 수정한 뒤 설치하여 사용하고 있고, Kubeshark CLI는 사용하지 않습니다.
Kubeshark는 빠르게 성장하고 변화하는 프로젝트이며, 기능 추가 및 변경 역시 과격하게 진행됩니다. Helm을 직접 수정하여 버전을 고정하지 않았다면 latest로 자동 업데이트되기 때문에 무언가 제대로 동작하지 않는 상황을 자주 만나볼 수 있습니다.
Kubeshark CLI
Kubeshark CLI는 Kubernetes 운영자가 아닌 사람들에게 사용을 권장하기 쉽지 않습니다.
kubeshark tap 커맨드를 사용한 동작 방식은 편하지만 보안 및 비용 관점의 리스크를 고려하여 CLI 사용을 권장하고 싶지 않습니다.
kube-system, secret-store와 같이 마이크로서비스를 개발하고 운영하는 분들에게 권한을 부여하지 않은 컴포넌트의 트래픽을 Sniff할 수 있다는 보안 관점의 리스크와, Tap의 범위를 전체 클러스터로 두어 너무 많은 네트워크 비용이 발생할 수 있는 상황을 컨트롤할 수 없다는 단점이 존재합니다.
QuotaLab에서는, 도입 초기엔 DevOps 엔지니어가 트러블 슈팅에 함께 참여하는 방식으로 해결하고, 추후엔 Kubeshark Hub API를 대신 호출하는 DevOps Platform을 도입하여 개발자분들이 Tracing 하고자 하는 Namespace, Pod name regex와 Tracing 기간을 받아 관리하는 방식으로 개선해나갈 예정입니다.
참고로, kubeshark tap 은 아래와 같은 API를 사용하여 동일한 효과를 볼 수 있습니다.
글 쓰는 시점에 해결된 것?
Kubeshark Frontend와 Kubeshark Hub 간의 통신을 ws가 아닌 wss 통신하고자 하면 Kubeshark Frontend 소스코드의 하드코딩된 프로토콜을 변경한 후 직접 빌드 한 버전을 사용해야 했습니다.
Helm에서 Daemonset Pod에서 PVC 사용이 강제되어 있었습니다. Kubeshark CLI를 사용해 설치하던 시점이라 Daemonset에서 PVC를 요구하며 제대로 프로비저닝 되지 않아 상당히 당황스러웠습니다. (이 시점을 기준으로 직접 Chart를 수정해서 사용했습니다.)
*Kubeshark는 Sniff 도구입니다. 개인정보 유출에 조심합시다.*
API로 주고받는 모든 요청을 평문으로 확인할 수 있는 강력한 도구인 만큼, 사용하는데 각별히 주의가 필요합니다.
운영 환경에서 도입은 정말 깊게 고민해 보셔야 하며, 개발 환경에서 사용할 때에도 동료분들이 자주 사용하는 비밀번호, 주민등록번호와 같이 중요한 정보들이 쉽게 노출될 수 있습니다.
이러한 이유로 QuotaLab에서는 절대로 운영 환경에서 Kubeshark를 사용하지 않습니다.
끝내며
네트워크 모니터링 도구로 반드시 Kubeshark를 써야 하는 것은 아닙니다. Sysdig Falco, Cilium Tetragon 과 같은 eBPF를 사용한 강력한 도구들이 존재합니다.
Runtime Secutity, SIEM 관점에서는 위 도구들이 Kubeshark보다 나은 대안이 될 수 있습니다만, 개발 환경에서의 트러블 슈팅에는 Kubeshark가 확실한 강점을 보여줍니다.
개발 환경에서 복잡한 문제를 해결하기 위해 시간을 낭비해 보셨다면 한 번쯤 Kubeshark를 사용해 보시길 추천드리고 싶습니다.
Ref.
벤처금융 인프라를 함께 만들어 나갈 동료를 찾습니다.
쿼타랩 채용 바로가기
쿼타랩 소개
사업 영역
제품
소식
채용