day-log

지지난 주에 우리 팀이 운영하는 결제 도메인 클러스터에서 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다.이 글은 두 리소스를 실무에 적용할 때 빠지기 쉬운 함정과, 우리 팀에서 정착시킨 패턴..

Terraform 쓰면서 가장 찜찜한 게 뭐였냐고 물으면, 솔직히 나는 terraform.tfstate에 시크릿이 평문으로 박히는 거였다. RDS 마스터 패스워드, API 토큰, OAuth 클라이언트 시크릿. data 블록으로 Secrets Manager에서 가져온 값조차 state에 그대로 기록된다.그동안은 state 백엔드(S3 + KMS)에 의존하거나, write-only 패턴을 억지로 끼워넣거나, 아예 Terraform 밖에서 처리하는 식으로 우회했다. 그런데 작년 말 1.10에서 나온 ephemeral resources가 1년 좀 넘게 실무에서 굴려보니 꽤 쓸 만하다. 최근 6월 기준 AWS, Azure, Vault, Kubernetes, random, 그리고 GCP 프로바이더까지 지원이 거의 ..

지난 화요일 새벽이었다. 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 ..

시크릿 관리는 처음엔 SealedSecret로 시작했다가, SOPS로 갔다가, 결국 External Secrets Operator(ESO)에 정착하는 팀이 꽤 많다. 우리도 비슷한 경로를 걸었다. 이 글은 ESO를 도입한 뒤 한참을 SecretStore 기반으로 운영하다가 ClusterSecretStore로 갈아탄 과정에서 정리한 내용이다.ESO 자체 입문 글은 검색하면 많이 나오는데, 막상 운영에 들어가면 "네임스페이스마다 SecretStore를 만들어야 하나, 아니면 ClusterSecretStore 하나로 묶어야 하나" 같은 부분에서 한참을 헤맨다. 어제도 신규 팀이 와서 같은 질문을 했길래, 그동안 정리한 내용을 한번 풀어본다.언제 ClusterSecretStore를 쓰는가SecretStore는 ..

오늘 알게 된 건데, 의외로 모르는 분 꽤 많더라. External Secrets Operator(ESO) 쓰면서 ClusterSecretStore를 그냥 kind: ClusterSecretStore만 박아두고 끝내는 경우. 그러면 클러스터 안의 모든 네임스페이스가 그 SecretStore를 참조할 수 있게 된다. 즉, Vault나 AWS Secrets Manager로 가는 인증 경로가 사실상 클러스터 전체에 열려 있는 셈이다.ESO 공식 문서의 보안 베스트 프랙티스에서도 ClusterSecretStore와 ClusterExternalSecret는 cluster-scoped라 특히 조심하라고 강조한다. 근데 막상 helm chart로 깔고 나면 example manifest를 그대로 복붙해서 쓰니까 이 ..

Terraform ephemeral과 write-only, 1년 굴리고 정리한 진짜 사용 패턴작년 이맘때쯤 Terraform 1.10이 나왔고, 그때부터 ephemeral 블록과 write-only 인자를 본격적으로 우리 코드베이스에 섞기 시작했다. 1.11에서 managed resource에도 write-only argument가 들어오면서 본격적으로 "state에서 시크릿을 빼는" 작업을 했고, 지금은 1.15.3까지 와있다. 1년이 지난 지금 다시 보면, 처음에 우리가 잘못 이해하고 있던 것들이 꽤 있었다. 단순히 "state에 안 남는 변수"가 아니라, 라이프사이클 자체가 다른 객체라는 것을 운영하면서야 체감했다.이 글은 "ephemeral이 뭔지 알려주는" 글이 아니다. 그건 hashicorp ..

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

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