day-log

런타임 보안을 도입한다고 하면 결국 두 갈래로 갈린다. Falco를 깔고 SIEM에 알람을 흘릴 거냐, Tetragon으로 정책 위반을 커널 레벨에서 막을 거냐. 우리 팀은 작년에 Falco부터 시작했고, 올해 초부터 일부 클러스터에 Tetragon을 같이 굴리고 있다. 둘 다 한참 써본 뒤 정리한 얘기를 풀어보려고 한다.겉으로 보면 "둘 다 eBPF 쓰는 컨테이너 런타임 보안 툴"인데, 막상 운영하다 보면 결이 꽤 다르다.출발점이 다르다: 감지냐, 차단이냐가장 큰 차이는 단순하다. Falco는 알람을 쏘고, Tetragon은 막는다. 누가 더 좋다는 얘기가 아니다.Falco는 시스템콜과 컨테이너 이벤트를 보고 "이런 일이 벌어졌다"고 통지한다. 비유하자면 CCTV다. 의심스러운 행위가 일어나면 알람을 ..

작년부터 우리 팀에서도 신규 서비스에는 Vault 대신 OpenBao를 깔기 시작했다. 처음 도입할 때만 해도 "그냥 Vault 1.14 그대로 박제된 거 아니냐"는 의심이 컸는데, 막상 1년 가까이 운영해보니 그 평가는 좀 수정해야겠다는 생각이 든다. 특히 올해 2월에 나온 2.5에서 namespace와 horizontal read scaling이 들어가면서, 단순히 Vault의 OSS 미러가 아니라 자기 방향성을 갖기 시작했다.이 글은 "OpenBao 도입 가이드"가 아니다. 그건 이미 충분히 많다. 대신 내부 구조가 Vault와 어디서 갈라지기 시작했는지, 운영자 입장에서 어느 지점을 신경 써서 봐야 하는지를 정리한다.포크 시점이 결정한 것들OpenBao는 Vault 1.14.0에서 갈라져 나왔다...

작년 말부터 컨테이너 이미지 서명을 본격적으로 강제하기 시작했다. 사내 정책상 프로덕션에 들어가는 모든 이미지는 서명되어 있어야 하고, admission controller에서 검증에 실패하면 배포가 막힌다. 그때 첫 번째로 부딪힌 질문이 "그래서 Cosign 쓸 거야, Notation 쓸 거야?" 였다.둘 다 OCI 아티팩트로 서명을 저장하고, 둘 다 표준화된 사양을 따른다. 그런데 막상 PoC 들어가니까 결이 꽤 달랐다. 5개월 정도 양쪽 다 운영해 본 입장에서 정리해본다.키 관리 모델이 가장 큰 분기점Cosign의 강점은 누가 뭐래도 keyless 서명이다. GitHub Actions의 OIDC 토큰을 Fulcio가 받아서 짧은 수명(보통 10분)의 X.509 인증서를 발급하고, 그걸로 서명한 뒤 ..

왜 Operator인가이미지 스캔(Trivy)이랑 시그니처 검증(cosign)까지는 잘 깔아뒀는데, 정작 "이 컨테이너가 지금 이상한 짓을 하고 있는지"는 안 보이더라. 빌드 타임 보안과 런타임 보안은 다른 문제다. 컨테이너 안에서 nc -e /bin/sh가 떠도 우리는 모른다. 그래서 팀에서 Falco를 본격적으로 깔았다. 헬름 차트로 한 번 깔아본 적은 있는데 이번에 Falco Operator(0.43 기준)로 새로 정비하면서 정리한 가이드다.대상 독자는 EKS/온프렘 K8s에 Falco를 처음 도입하거나, 옛날 헬름 설치를 Operator로 옮기려는 사람.지난해까진 우리도 falcosecurity/falco 헬름 차트로 깔았다. 근데 룰을 ConfigMap으로 관리하다 보니 룰 한 줄 바꾸면 Dae..

작년 봄에 시크릿 관리 체계를 갈아엎으면서 ESO(External Secrets Operator)랑 SOPS를 둘 다 도입했다. 처음엔 하나로 통일하자는 의견이 강했는데, 1년 굴려보니 둘 중 하나만으로는 답이 안 나오더라. 결국 우리 팀은 둘을 역할로 갈라놓고 쓰는 쪽으로 정착했다.최근에 신규 팀 합류한 사람한테 이 구조를 설명할 일이 있었는데, 막상 글로 정리해두니 우리도 모호하게 쓰고 있던 부분이 꽤 보였다. 그래서 한번 정리해본다.우리 환경 간단히EKS 클러스터 4개 (dev/stage/prod 2개 — 리전 분리)ArgoCD 기반 GitOpsAWS Secrets Manager, Parameter Store 둘 다 사용 중코드 저장소는 GitHub Enterprise원래는 sealed-secret..

이미지 서명을 안 하는 팀은 이제 거의 없을 거다. 빌드 파이프라인에 cosign 한 줄 박는 건 어렵지도 않으니까. 문제는 검증 쪽이다. 누가 서명 안 된 이미지를 클러스터에 푸시해도 그냥 굴러간다. 결국 admission 단에서 막아야 하는데, 이걸 가장 깔끔하게 해주는 게 Kyverno의 ImageValidatingPolicy다.올해 초 Kyverno에서 기존 ClusterPolicy의 verifyImages 규칙을 ImageValidatingPolicy(IVP) 라는 별도 타입으로 분리하면서 정책 작성이 좀 더 명시적으로 바뀌었다. 우리 팀에서도 4월 초에 ClusterPolicy 기반 검증을 IVP로 옮겼는데, 옮기면서 정리한 내용을 가이드 형태로 풀어본다.사전 준비물Kubernetes 1.28..

지난주 금요일 오후 4시. 평화롭던 사무실에 메신저 알림이 떴다. "스테이징 클러스터 새로 만든 거 거의 다 됐는데, ArgoCD가 SealedSecret 못 푼다고 에러 토하는 중인데 좀 봐주실 수 있어요?" 그 메시지를 본 순간 명치가 싸늘해졌다.왜냐면 그 이전 클러스터의 sealed-secrets controller에서 발급된 master key를 백업해뒀는지 기억이 안 났거든. 결론부터 말하면 안 해놨다. 그래서 그날 퇴근은 새벽 1시였다.무슨 일이 벌어진 건가상황을 좀 정리해보자. 우리 팀은 EKS 1.28 → 1.31 업그레이드를 in-place로 안 하고 새 클러스터를 만들어서 옮기는 방식으로 진행하고 있었다. 스테이징부터. 매니페스트는 ArgoCD GitOps로 관리되니까 그냥 ArgoCD..

지난주 화요일 아침, 팀 슬랙의 #security-alert 채널을 열었더니 빨간 메시지가 화면을 가득 채우고 있었다. 멘탈이 잠깐 나갔다. CI 파이프라인에 Trivy 스캔을 새로 붙인 첫날이었고, 우리가 운영하는 서비스 47개 중 31개가 한 번에 fail 처리됐다. 보고된 CVE만 1,400개가 넘었다.당연히 본부장이 디엠을 보냈다. "이거 다 수정해야 하나요?"솔직히 말하면 그 순간엔 답을 못 했다. 이 글은 그 1,400개의 알림 폭탄을 정리하면서 우리 팀이 어떻게 신호와 소음을 분리했는지에 대한 회고다. 결론부터 말하면, 진짜로 손대야 했던 건 23개였다.처음에 뭐가 잘못됐나일단 우리가 한 게 뭐였냐면, trivy image 기본 옵션으로 모든 이미지를 스캔하고 결과를 그대로 슬랙에 던진 거였..

쿠버네티스에서 시크릿을 어떻게 가져올 것이냐. 이 질문은 보통 회사가 어느 정도 커지고 클러스터가 두세 개 늘어나는 시점에 한 번 크게 부딪힌다. 우리 팀도 그랬다. 작년 초까지는 그냥 kubectl create secret으로 박아 넣고 헬름 차트에 손으로 옮기는 식이었는데, 클러스터가 4개로 늘고 환경별로 시크릿 동기화 누락이 두 번쯤 사고로 이어지면서 더는 못 미루겠다는 결론이 났다.후보는 사실상 두 개였다. External Secrets Operator(이하 ESO)와 HashiCorp의 Vault Agent Injector. 둘 다 충분히 성숙했고 사례도 많다. 그런데 막상 비교하기 시작하면 "어느 게 더 좋은가" 자체가 잘못된 질문이라는 게 금방 드러난다. 결국 우리 팀이 어떤 시크릿을 다루고..

쿠버네티스에 정책 엔진 하나는 깔아야 한다는 얘기가 나온 게 벌써 몇 년째인지 모르겠다. 우리 팀도 처음엔 "PSP 사라지면 그때 가서 보자"고 미뤘는데, 결국 PSP 제거되고, NetworkPolicy 강제도 필요해지고, 이미지 서명 검증 요건까지 붙으면서 더 이상 미룰 수가 없었다.선택지는 사실상 둘이다. Kyverno 아니면 OPA Gatekeeper. 둘 다 CNCF 프로젝트고, 둘 다 어드미션 컨트롤러로 동작한다. 그래서 처음엔 "어차피 비슷하겠지" 싶었는데, 직접 양쪽을 작은 클러스터에 나눠 깔고 두어 달 굴려보니 꽤 결이 다른 도구라는 걸 알게 됐다. 이 글은 그 비교 노트다.정책을 어떻게 쓰는가 — YAML vs Rego이 차이가 가장 크다.Gatekeeper는 OPA를 베이스로 깔고 있어..