day-log

지난주에 인프라 비용 리뷰가 있었다. 평소 같으면 EC2랑 NAT Gateway 위주로 훑고 지나갔을 자리인데, 이번엔 AWS Secrets Manager 라인이 유난히 눈에 띄었다. 전월 대비 4배. 절대 금액이 큰 건 아닌데(정확히는 $180 정도), 갑자기 4배가 뛴 게 이상해서 파보다가 며칠 날렸다.결론부터 말하면 범인은 External Secrets Operator였다. 정확히는 ExternalSecret 리소스에 박아둔 refreshInterval: 15s.왜 15초로 뒀었나원래 이 값은 팀에서 붙인 게 아니고, 초창기에 ESO를 도입한 사람이 "빠르게 반영되면 좋겠지" 하고 넣어둔 걸 아무도 안 건드린 채 굴러왔다. 몇 년 지나면서 ExternalSecret 개수도 슬금슬금 늘어서 지금 확인..

Trivy를 처음 붙였을 때 우리 팀은 CVE 몇천 개짜리 리포트 앞에서 멘탈이 나갔다. CVSS 9.8이 수백 개인데 이걸 다 이번 스프린트에 잡으라니. 근데 그게 진짜로 다 위험한 걸까? 결론부터 말하면 아니다. CVSS는 "이 취약점이 뚫리면 얼마나 아플까"만 알려주지, "누가 지금 이걸 실제로 뚫고 있냐"는 답하지 않는다.이 글은 CVSS 하나로만 우선순위를 매기다가 지친 팀을 위한 실무 가이드다. EPSS로 실제 익스플로잇 확률을, KEV로 이미 공격당하고 있는 CVE를 걸러내서 컨테이너 이미지 스캔 결과를 실행 가능한 수준으로 줄이는 방법을 다룬다.세 지표가 서로 다른 질문에 답한다먼저 각 지표가 뭐에 답하는 도구인지 정리하자.CVSS는 "이론적으로 얼마나 심각한가"에 답한다. 인증 없이 원격..

쿠버네티스 admission 정책 엔진 이야기가 나오면 결국 Kyverno와 OPA Gatekeeper 두 개로 좁혀진다. 몇 년 전에는 "Gatekeeper 쓰면 뭔가 있어 보인다"는 분위기였는데, 최근 우리 팀에서 클러스터 3개에 적용해보고 나니 생각이 좀 바뀌었다. 이번 글은 그 판단 근거를 정리한 것이다.결론부터 말하면, 순수 K8s admission만 필요한 상황에서는 지금 시점에 Kyverno가 손이 훨씬 덜 간다. 다만 그렇다고 Gatekeeper가 죽은 프로젝트냐 하면 그건 또 아니다.정책 언어부터 갈린다Gatekeeper는 Rego를 쓴다. OPA 진영에서 오래 굴려온 언어라 표현력은 확실히 강력하다. 대신 팀 안에 Rego 아는 사람이 한두 명이면 그 사람이 병목이 된다. 실제로 우리 ..

sigstoreDevSecOpsGitHub-Actions공급망보안keyless 오늘 후배가 "이미지 서명하려는데 KMS 키 발급받아야 하냐"고 물어서 답해준 김에 정리한다. 2026년에 아직도 cosign에 개인 키 파일 물려서 쓰고 있다면 이 글이 도움 될 거다. GitHub Actions만 쓰면 키 관리 자체가 필요 없다.keyless가 뭐하는 건가cosign keyless는 서명할 때 개인 키 대신 CI의 OIDC 토큰을 쓴다. 흐름은 이렇다.GitHub Actions가 워크플로우 실행 중에 짧은 수명의 OIDC 토큰을 발급한다. 이 토큰에는 리포지토리, 브랜치, 워크플로우 경로 같은 identity 정보가 들어있다.cosign이 이 토큰을 Sigstore의 Fulcio에 넘긴다. Fulcio는 토..

Kubernetes Secret을 base64로 관리하는 시대는 이제 좀 지나갔다. etcd에 평문으로 들어가는 걸 감안하면 그냥 인코딩된 문자열일 뿐이다. 그래서 대부분 팀은 외부 시크릿 매니저(AWS Secrets Manager, Vault, GCP Secret Manager 등)로 옮겨간다.문제는 이걸 어떻게 Pod까지 안전하게, 그리고 회전(rotation)까지 자동으로 반영되도록 연결하냐는 것이다. External Secrets Operator(이하 ESO)가 이 자리를 채운다. 올해 초 나온 ESO 2026 가이드들을 훑어보면 대부분 "설치하고 SecretStore 만들고 ExternalSecret 정의하면 끝"이라고 쓰여있는데, 실제 프로덕션에 넣어보면 IRSA 권한, refreshInter..

시크릿 관리 도구 얘기가 나오면 늘 "그거 Vault로 하면 되잖아요" 아니면 "AWS 쓰면 Secrets Manager가 편하지" 두 진영으로 갈린다. 우리 팀도 작년까지는 그랬다. 지금은? 둘 다 쓴다. 하이브리드로 굴러가는 지 반 년쯤 됐고, 나름 안정화됐다. 그 과정에서 알게 된 것들을 정리한다.작년 초 IBM이 HashiCorp을 인수하면서 Vault Enterprise 라이선스 정책이 조금씩 바뀌기 시작했다. 우리는 커뮤니티 에디션을 쓰고 있었지만, 로드맵이 IBM 포트폴리오와 얽히기 시작한 게 살짝 불안하긴 했다. 그렇다고 AWS Secrets Manager로 다 옮기자니 우리 워크로드가 AWS 온리도 아니었다. 온프렘 DB가 아직 남아있고, GCP에도 워크로드가 조금 있다.각각의 강점, 실..

올해 2월에 Kyverno 1.17이 나오면서 재밌는 변화가 하나 있었다. ClusterPolicy와 CleanupPolicy가 공식적으로 Deprecated로 마킹된 것. 아직 지워지진 않았지만, Kyverno 팀이 CEL(Common Expression Language) 중심 아키텍처로 방향을 확 틀었다는 신호다. 우리 팀은 지난달부터 조금씩 이 전환을 시작했는데, 처음 시작하는 팀들을 위해 몇 가지 정리해두려고 한다.왜 갑자기 CEL인가간단히 말하면, Kubernetes 자체가 1.30부터 ValidatingAdmissionPolicy(VAP)를 GA로 넣으면서 admission control 계층에 CEL 기반 표현식을 표준으로 밀기 시작했다. Kyverno가 오랫동안 자체 DSL로 정책을 표현해..

지난주 새벽에 겪은 이야기다. 프로덕션 EKS 두 개 중 한 쪽에서 신규 파드가 시크릿을 못 읽는다는 알림이 왔다. 처음엔 대수롭지 않게 봤는데, 결국 External Secrets Operator(ESO) 전체 sync가 멈춰 있는 상태였다. 우리 팀이 ESO를 IRSA + AWS Secrets Manager 조합으로 3년 넘게 쓰고 있는데, 이런 식으로 죽는 건 처음이었다.증상은 조용했다관측 가능한 신호가 애매했다. kubectl get externalsecret -A 를 찍으면 상태는 죄다 SecretSyncedError 였다. 근데 컨트롤러 파드는 살아 있고, CPU도 정상이고, 리더 election 로그도 잘 남고 있었다. Prometheus에서 externalsecret_sync_calls_e..

지난주에 클러스터 두 개 사이에 SPIRE Federation을 붙이려고 하다가 정말 삽질을 오지게 했다. 결국 붙이긴 했는데, 그 과정에서 문서만 봐서는 절대 안 걸리는 함정 몇 개를 밟았다. 다음에 또 이런 걸 세팅할 나 자신을 위한 기록이자, 혹시 지금 SPIRE federation을 붙이려는 분들을 위한 삽질 로그다.상황우리 팀은 원래 단일 EKS 클러스터에서 SPIRE로 워크로드 identity를 발급받아 쓰고 있었다. Istio가 sidecar mTLS에 SPIFFE ID를 쓰고, 몇몇 배치 잡이 Vault 대신 SPIRE-issued SVID로 S3에 접근한다. 잘 돌아갔다.문제는 데이터플랫폼 팀이 별도 계정, 별도 VPC, 별도 EKS 클러스터를 굴리기 시작하면서 시작됐다. 그쪽에서 우리 ..