day-log

Trivy vs Grype, 컨테이너 스캐너 뭘 쓸까CI 파이프라인에 컨테이너 이미지 스캐너를 하나 박아 넣어야 하는 상황이 최근에 또 왔다. 사내에서 새 서비스 하나 띄우는데 보안팀에서 "이미지 CVE 스캔 결과 붙여주세요"라는 요구를 걸었다. 예전에는 그냥 Trivy 박고 끝이었는데, 이번엔 좀 다르게 접근해봤다.솔직히 말하면 요즘 Grype가 꽤 좋아졌다. 최근 몇 달 사이 EPSS 통합, KEV 카탈로그 반영, 컴포지트 리스크 스코어 같은 게 붙으면서 "이거 진짜 실무에 쓸만한데?" 싶은 느낌이 확실히 있다. 그래서 이번 기회에 두 스캐너를 나란히 놓고 우리 파이프라인에 뭘 넣을지 다시 판단했다.두 도구의 성격이 다르다같은 카테고리로 묶어서 비교하기엔 사실 두 도구가 지향점이 좀 다르다.Trivy..

지난달에 팀 내부에서 "이미지 취약점 스캔 좀 제대로 붙여야 하지 않냐"는 얘기가 나왔다. 그 전까진 CI 파이프라인에서 trivy image 한 줄로 빌드 시점에만 스캔하고 있었는데, 클러스터에 이미 떠 있는 워크로드는 아무도 안 챙기고 있었다. 이미지 태그가 latest인 것도 있고, 6개월 전에 배포하고 그대로인 것도 있었다. 그래서 Trivy Operator를 붙였다. 그리고 다음날 새벽에 슬랙 알림이 몇백 개 쏟아졌다.왜 Trivy Operator였나선택지는 몇 가지 있었다. Trivy Operator, Kubescape, Falco, StackRox 같은 것들. 우리는 이미 CI에서 Trivy를 쓰고 있었고 룰이 익숙했다. 그리고 Aqua가 계속 유지보수하고 있어서 커뮤니티가 가장 활발했다. ..

애플리케이션에 DB 비밀번호를 어떻게 넣어놓고 계셨나요. 우리 팀은 예전에 Kubernetes Secret에 base64로 넣어놓고, 분기마다 수동으로 로테이션했다. 근데 이게 몇 년 이어지다 보니 문제가 쌓였다. 누가 언제 그 시크릿을 봤는지 감사 로그가 없고, 로테이션 날에는 여러 서비스가 동시에 재기동되면서 P99 레이턴시가 튀었다. 결국 Vault Dynamic Secrets로 넘어갔는데, 처음 설정할 때 헤맨 부분이 좀 있어서 정리해둔다.이 글은 PostgreSQL 기준이지만 MySQL이나 MongoDB도 큰 틀은 같다. 최근 Vault 1.19에서 rotation_schedule 필드로 크론 스타일 스케줄이 정식 지원되면서 static role 운용이 훨씬 편해졌다.Dynamic Secrets..

Kubernetes에 시크릿을 어떻게 넣을지 팀 내부에서 얘기가 몇 번 오갔다. Sealed Secrets는 GitOps랑 궁합이 좋긴 한데 로테이션이 귀찮고, kubectl create secret은 GitOps 원칙에 어긋난다. 결국 우리 팀은 External Secrets Operator(ESO) + AWS Secrets Manager 조합으로 갔다. 6개월 정도 운영해보니 손이 덜 가서 만족스럽다.이 글은 ESO를 처음 도입할 때 필요한 IRSA 설정, ClusterSecretStore/SecretStore 결정, 그리고 실무에서 자주 걸리는 몇 가지 함정을 정리했다. 최근 v0.10 대에서 문법이 조금씩 바뀐 부분도 반영했다.왜 ESO인가간단히 말하면 AWS Secrets Manager를 원본(..

Falco를 클러스터에 깔아본 사람은 많지만, 이게 정확히 어떤 식으로 syscall을 잡아내는지 끝까지 따라가본 사람은 의외로 적다. 우리 팀에서도 한동안은 "그냥 eBPF로 커널 이벤트 본다더라" 수준의 이해로 운영했다. 그러다가 노드 일부에서 syscall drop이 튀기 시작했고, 원인을 디버깅하다 보니 결국 probe 내부 구조까지 파게 됐다. 이번 글은 그때 정리한 내용을 풀어서 쓴 것이다.사실 내부적으로는 Falco가 모든 일을 직접 하지 않는다. 사용자 공간에서 룰을 평가하는 falco 데몬과, 커널 공간에서 syscall을 가로채는 probe가 분리돼 있다. 우리가 보통 Helm 차트 옵션에서 driver.kind: modern_ebpf라고 한 줄 적고 넘어가는 그 probe가, 실은 꽤..

지지난 주에 우리 팀이 운영하는 결제 도메인 클러스터에서 Vault 토큰 관련 알람이 30분 가까이 폭주했다. P99 레이턴시도 같이 튀었고, 무엇보다 새벽 2시였다. 결론부터 말하면 Vault Agent injector가 만든 sidecar가 init 컨테이너가 이미 받아둔 토큰을 재사용한다고 믿고 있었는데, 실제로는 그렇지 않아서 매번 다시 인증을 시도하다가 Vault 서버 쪽 rate limit에 걸린 사건이었다.좀 더 풀어서 적어둔다. 같은 함정 밟는 분 있을지도 모르니까.어떻게 발견했는가알람은 단순했다. vault-agent 컨테이너에서 permission denied와 429 too many requests가 번갈아 찍히고 있었다. 처음에는 정책(vault policy) 문제인가 싶었다. 그런..

External Secrets Operator(ESO)를 처음 도입하면 보통 ExternalSecret 리소스부터 만든다. AWS Secrets Manager나 Vault에 있는 시크릿을 Kubernetes Secret으로 끌어오는 흐름. 이 정도는 어렵지 않다. 그런데 운영을 6개월쯤 하다 보면 다음 두 가지가 슬슬 필요해진다.첫째, 클러스터에서 생성한 시크릿(예: 앱이 동적으로 만든 API 키)을 외부 시크릿 저장소로 밀어 올리고 싶어진다. 둘째, 클러스터 단위로 한 번만 SecretStore를 정의하고 여러 네임스페이스에서 공유하고 싶어진다. 전자가 PushSecret, 후자가 ClusterSecretStore다.이 글은 두 리소스를 실무에 적용할 때 빠지기 쉬운 함정과, 우리 팀에서 정착시킨 패턴..

내부 보안팀에서 "프로덕션 클러스터에 서명 안 된 이미지 못 들어오게 하자"는 얘기가 나온 지 한참 됐다. 우리 팀은 GitHub Actions로 빌드한 이미지를 ECR에 푸시하고 있었고, Cosign keyless 서명 자체는 이미 파이프라인에 붙여둔 상태였다. 문제는 검증. 클러스터 어드미션에서 막는 부분이 없었다.Kyverno ImageValidatingPolicy(IVP)로 정리한 결과를 적어둔다. 1.13에서 들어온 새 정책 타입인데, 기존 ClusterPolicy의 verifyImages 룰보다 모듈화가 잘 돼 있어서 운영하기 편하다.전제: Cosign keyless 서명이 무엇을 보장하나Keyless는 키 파일을 보관하지 않는다. 대신 Sigstore Fulcio가 OIDC ID(예: Git..

지난 화요일 새벽이었다. 4시 12분에 휴대폰이 부르르 울렸다. PagerDuty.vault-prod cluster: all nodes sealed침대에서 일어나면서 머릿속이 멍했다. 보통 vault가 sealed 상태로 돌아가는 일은 없다. unseal key는 사람이 들고 있지도 않다 — auto-unseal로 AWS KMS에 위임해놨으니까. 그런데 sealed라니. 노트북을 열면서 솔직히 멘탈이 좀 나갔다.첫 30분: 뭐가 죽었는지조차 몰랐다처음엔 vault 자체 이슈인 줄 알았다. 컨테이너가 OOM이라도 났나 싶어서 노드부터 확인했다. CPU도 메모리도 멀쩡했다. Pod도 다 running이었고. 그런데 vault status를 때려보면 매번 같은 응답이 돌아왔다.Sealed: trueTotal ..