보안 권고에 따라 주문 DB 앱 계정의 비밀번호를 Secrets Manager로 30일마다 자동 교체하기 시작했고, 어젯밤 첫 교체가 있었습니다. 주문 API는 Secrets Manager에서 값을 읽어 오기 때문에 정상입니다. 그런데 읽기 전용 복제본(read replica)에 붙는 리포트 서비스만 오늘 아침부터 인증 실패로 리포트를 만들지 못합니다. 리포트 서비스는 쿠버네티스에서 돌고, 1년 전 다른 팀이 만들었습니다. 담당자는 복제본에 비밀번호 변경이 아직 전파되지 않았다고 봅니다.
DB 비밀번호 자동 교체 뒤 리포트 서비스만 인증 실패
보안 권고에 따라 주문 DB 앱 계정의 비밀번호를 Secrets Manager로 30일마다 자동 교체하기 시작했고, 어젯밤 첫 교체가 있었습니다.
시나리오
단서
FATAL: password authentication failed for user "orders_app" (host=orders-ro.cluster-xyz.ap-northeast-2.rds.amazonaws.com)
$ aws secretsmanager describe-secret --secret-id prod/orders/app --query 'VersionIdsToStages'
{ "a1b2…": ["AWSCURRENT"], "9f8e…": ["AWSPREVIOUS"] } # a1b2… 생성: 어젯밤 23:00
$ kubectl -n reports get secret orders-db -o jsonpath='{.metadata.creationTimestamp}'
2025-09-30T02:11:45Z
# 이 시크릿을 갱신하는 컨트롤러(ExternalSecret 등) 없음과제 원인을 좁히고, 서비스를 되살리는 순서(검증 포함)와 재발 방지책을 적어 보세요.
구독하면 이어서 볼 수 있어요
이 문제의 전체 시나리오와 점검 체크리스트, 복구 순서, 모범 풀이는 Pro 구독에서 열립니다.
먼저 볼 것
- 자격 증명을 쓰는 모든 곳(소비자) 목록
- 비밀값의 원본과 복사본
점검 체크리스트
- 실패한 서비스가 비밀번호를 어디서 읽는지(Secrets Manager 직접인지 복사본인지)
- 쿠버네티스 시크릿의 생성·갱신 시각과 동기화 수단
- 복제본이 주 DB와 같은 계정 정보를 쓰는지
복구와 재발 방지
같이 보면 좋은 질문
현장에서 본 비슷한 케이스