비밀 교체의 완료는 저장소에 새 값을 게시한 시점이 아니라 실제 요청이 새 버전을 사용하고 옛 자격이 정책에 맞게 거부되는 시점입니다. 전달 경로, 앱 캐시, 만료와 장애 fallback을 각 경계의 상태로 나누어 확인합니다.
Base64 인코딩과 Git 저장의 비밀 보호 한계
Kubernetes Secret의 data 값을 base64로 바꾸면 사람이 바로 읽기 어려워 보이지만 누구나 되돌릴 수 있습니다. 비밀값을 그대로 인코딩해 Git에 넣으면 저장소·포크·캐시·로그를 통해 원문이 노출된 것과 다르지 않습니다. 나중 커밋에서 지워도 이미 복제된 값은 회수되지 않습니다.
GitOps에서는 암호화된 선언을 저장하고 복호화 권한을 배포 환경에만 주거나, 외부 비밀 저장소의 이름·버전을 참조하게 할 수 있습니다. 어느 방식이든 Git을 읽는 권한과 운영 비밀을 해독·조회하는 권한을 분리해야 합니다. base64 Secret을 API 서버가 받았다는 사실만으로 저장소 암호화·RBAC·노드 접근이 모두 안전해지는 것은 아닙니다.
Base64 decode가 가능한 사람은 원문을 얻을 수 있으므로 보호 경계는 인코딩이 아니라 암호화 키와 복호화 주체입니다. 이미 Git clone·CI 로그·이미지 레이어에 퍼진 값은 커밋 삭제만으로 회수되지 않으므로 노출 시 회전과 유효 경로 폐기를 함께 계획합니다.
전달 경로별 원문 노출 주체와 통제
| 경로 | 필요한 통제 | 자주 빠지는 노출 |
|---|---|---|
| Git의 암호문 | KMS·복호화 주체 분리 | CI가 평문 diff 출력 |
| 외부 Secret 참조 | workload별 최소 조회 권한 | 모든 namespace 공용 자격 |
| 배포 프로세스 | 신뢰된 배포 코드·로그 마스킹 | 비신뢰 PR에서 운영 자격 사용 |
| 앱 런타임 | 필요한 프로세스만 접근 | crash dump·환경 출력·디버그 API |
비밀을 저장소에서 안전하게 꺼냈더라도, 빌드·테스트 과정에서 그 비밀이 이미지 레이어나 테스트 snapshot에 기록되면 그 복사본을 읽는 경로가 다시 생깁니다. 그래서 비신뢰 PR의 스크립트에는 운영 비밀을 주지 않고, 검증과 배포를 수행하는 주체를 분리해야 합니다. Secret 읽기 권한은 다른 서비스의 자격을 얻는 간접 경로가 될 수 있으므로 권한 이름만 보고 저위험으로 분류하지 않습니다.
각 경로에서 “누가 원문을 읽을 수 있는가”를 주체별로 적습니다. 비신뢰 PR runner가 운영 secret을 읽을 수 있으면 Git 선언이 암호화돼도 위험이 남고, 앱이 정상적으로 읽은 뒤 crash dump에 남기면 런타임 경계가 새 복사본이 됩니다. 로그에는 원문 대신 version·operation 결과만 남깁니다.
파일 갱신 시각과 실제 사용 키 버전
프로세스가 K1을 환경 변수로 읽고 실행 중일 때 Secret 객체를 K2로 바꿔도, 환경 변수는 일반적으로 시작 시 정해진 값이라 기존 프로세스에는 K2가 들어오지 않습니다. 그래서 재시작이나 롤링 교체가 필요할 수 있습니다. 파일 마운트는 플랫폼이 K2로 갱신해도 앱이 처음 읽은 문자열을 캐시하거나 열린 파일 핸들·기존 SDK client를 계속 쓰면 실제 호출은 K1로 나갑니다. 파일이 바뀐 시각과 요청에 쓰인 키 버전이 다른 이유가 여기에 있습니다.
Secret volume은 객체 변경 직후 모든 소비 경계에 도착한다고 보면 안 됩니다. Kubernetes에서는 volume 갱신에 전파 지연이 있고 subPath 마운트는 자동 갱신 대상이 아닙니다. 또 원자적 파일 교체 뒤에도 기존 핸들은 이전 inode를 가리킬 수 있으므로, 변경 감지 코드에서는 파일을 한 번 읽는 경우와 영구 핸들을 유지하는 경우를 구분해야 합니다.
그림을 글로 읽기
- 비밀 저장소 K2 게시
- 환경 재시작·파일 갱신
- 앱이 전체 묶음 재읽기
- 새 client·호출에 적용: 버전 지표로 확인
- 비밀 저장소 K2 게시 → 환경 재시작·파일 갱신: 플랫폼 전달
- 환경 재시작·파일 갱신 → 앱이 전체 묶음 재읽기: 앱 갱신 계약
- 앱이 전체 묶음 재읽기 → 새 client·호출에 적용: 검증 후 교체
인증서·개인키·체인처럼 짝이 맞아야 하는 파일은 각각 읽는 도중 버전이 섞이지 않게 합니다. 버전 디렉터리나 snapshot으로 전체를 읽고 일관성을 검증한 뒤 실행 중 설정 참조를 한 번에 바꿉니다. 새 설정이 잘못됐으면 명시된 기한 안에서 이전 정상값을 유지하고 경고하되, 만료·회수된 값을 무기한 유지하지 않습니다.
K1 환경 변수를 읽은 프로세스는 Secret 객체가 K2로 바뀌어도 재시작 전까지 K1을 사용할 수 있습니다. 파일 watcher가 K2를 발견해도 기존 SDK client가 K1을 캐시하면 실제 요청은 바뀌지 않으므로, reload는 파일 timestamp가 아니라 새 client가 실제 호출에 사용한 version으로 완료 판정합니다.
저장소 장애와 마지막 정상 자격의 신뢰 범위
마지막 정상값을 사용하는 정책은 이미 검증된 자격의 제한적 재사용입니다. 처음 시작한 인스턴스에 자격이 없거나 새로운 고권한 작업에 필요한 증명이 없으면 임의 기본값·평문 fallback으로 통과시키지 않습니다.
계산을 위해 자격이 10:00에 발급되고 10:10에 만료된다고 하겠습니다. 정책이 마지막 확인 후 3분까지만 stale 사용을 허용하면, 10:08에 마지막 확인한 경우 stale 한계는 10:11이므로 원래 만료 시각인 10:10에 먼저 중단합니다.
10:04에 마지막 확인한 경우에는 stale 한계인 10:07에 먼저 중단합니다. 따라서 실제 사용 기한은 원래 만료 시각과 마지막 확인 시각에 3분을 더한 시각 중 이른 때입니다.
3분은 예시 정책일 뿐이며, 적절한 시간은 자산·회수 요구로 정합니다. 이미 회수됐다는 신호가 있으면 저장소가 불안정해도 옛 자격을 다시 사용하지 않습니다.
저위험 기존 조회와 신규 관리자 작업은 같은 fail-open 정책으로 묶지 않습니다.
복구 시 모든 인스턴스가 동시에 조회하지 않도록 jitter·backoff·공유 갱신을 적용합니다. 최신 발급·회수 버전을 확인하고 원문 비밀을 로그나 임시 설정 파일에 복사해 장애를 우회하지 않습니다.
실제 사용 한계는 min(expiry, last_verified + stale_window)입니다. 10:08 검증·10:10 만료·3분 stale 정책이면 10:10에 먼저 중단하며, revoke 신호는 stale window보다 우선합니다. 최초 기동에 검증된 자격이 없거나 고권한 신규 작업이면 평문·임의 기본값 fallback을 허용하지 않습니다.
비밀 교체와 소비자 적용 결과 시험
새 키를 받아들이는 검증자를 먼저 준비한 뒤 소비자를 전환하고, 환경 변수 프로세스·파일 재읽기 프로세스·장기 SDK client 각각의 실제 호출 키 버전을 관찰합니다. 로그에는 키 원문 대신 버전과 사용 성공·실패만 남깁니다.
저장소 중단·파일 일부 오류·짝이 안 맞는 인증서·재시작·subPath·만료를 테스트 배포에서 재현합니다. 새 값을 읽었다는 로그만으로 완료하지 않고 구 키 폐기 뒤에도 모든 허용 경로가 정상이며 금지된 옛 자격은 실패하는지 확인합니다. 이 노트는 배포 설계 설명이며 실제 Kubernetes 클러스터에서 실행한 결과는 아닙니다.
K2를 게시한 뒤 환경 변수 프로세스, 파일 재읽기 프로세스, 장기 SDK client를 각각 관찰합니다. 예측 결과는 파일 갱신 로그만으로 완료가 아니고 실제 호출 version이 K2가 되어야 완료이며, K1 폐기 뒤 금지된 옛 자격의 호출은 실패해야 합니다. Kubernetes cluster 실험을 이 환경에서 수행한 것은 아닙니다.