day-log

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에도 워크로드가 조금 있다.각각의 강점, 실..

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

지지난 주에 우리 팀이 운영하는 결제 도메인 클러스터에서 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는 ..