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는 ..

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