day-log

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

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

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

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