day-log

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

Kubernetes에 시크릿을 어떻게 넣을지 팀 내부에서 얘기가 몇 번 오갔다. Sealed Secrets는 GitOps랑 궁합이 좋긴 한데 로테이션이 귀찮고, kubectl create secret은 GitOps 원칙에 어긋난다. 결국 우리 팀은 External Secrets Operator(ESO) + AWS Secrets Manager 조합으로 갔다. 6개월 정도 운영해보니 손이 덜 가서 만족스럽다.이 글은 ESO를 처음 도입할 때 필요한 IRSA 설정, ClusterSecretStore/SecretStore 결정, 그리고 실무에서 자주 걸리는 몇 가지 함정을 정리했다. 최근 v0.10 대에서 문법이 조금씩 바뀐 부분도 반영했다.왜 ESO인가간단히 말하면 AWS Secrets Manager를 원본(..

Falco를 클러스터에 깔아본 사람은 많지만, 이게 정확히 어떤 식으로 syscall을 잡아내는지 끝까지 따라가본 사람은 의외로 적다. 우리 팀에서도 한동안은 "그냥 eBPF로 커널 이벤트 본다더라" 수준의 이해로 운영했다. 그러다가 노드 일부에서 syscall drop이 튀기 시작했고, 원인을 디버깅하다 보니 결국 probe 내부 구조까지 파게 됐다. 이번 글은 그때 정리한 내용을 풀어서 쓴 것이다.사실 내부적으로는 Falco가 모든 일을 직접 하지 않는다. 사용자 공간에서 룰을 평가하는 falco 데몬과, 커널 공간에서 syscall을 가로채는 probe가 분리돼 있다. 우리가 보통 Helm 차트 옵션에서 driver.kind: modern_ebpf라고 한 줄 적고 넘어가는 그 probe가, 실은 꽤..

지지난 주에 우리 팀이 운영하는 결제 도메인 클러스터에서 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 프로바이더까지 지원이 거의 ..

내부 보안팀에서 "프로덕션 클러스터에 서명 안 된 이미지 못 들어오게 하자"는 얘기가 나온 지 한참 됐다. 우리 팀은 GitHub Actions로 빌드한 이미지를 ECR에 푸시하고 있었고, Cosign keyless 서명 자체는 이미 파이프라인에 붙여둔 상태였다. 문제는 검증. 클러스터 어드미션에서 막는 부분이 없었다.Kyverno ImageValidatingPolicy(IVP)로 정리한 결과를 적어둔다. 1.13에서 들어온 새 정책 타입인데, 기존 ClusterPolicy의 verifyImages 룰보다 모듈화가 잘 돼 있어서 운영하기 편하다.전제: Cosign keyless 서명이 무엇을 보장하나Keyless는 키 파일을 보관하지 않는다. 대신 Sigstore Fulcio가 OIDC ID(예: Git..

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