Kubernetes Secret의 base64 값을 Git에 넣어 배포하려 합니다. 이 값은 비밀로 보호되며 어떻게 안전하게 전달·교체해야 하나요?

Kubernetes Secret의 data 값이 base64라는 것은 암호화됐다는 뜻이 아닙니다. 누구나 디코딩할 수 있는 텍스트 표현이므로 실제 비밀번호·토큰과 같은 비밀로 취급해야 합니다. GitOps의 선언적 변경 추적과 비밀 원문의 보관·전달은 분리하고, 이미 Git 이력에 들어간 값은 파일을 삭제하는 것보다 먼저 회수하고 새 값으로 교체해야 합니다.

저장소와 복호화 경계를 나눕니다

예를 들어 aGVsbG8=는 키 없이 hello로 되돌릴 수 있는 인코딩입니다. 따라서 Secret YAML을 private Git에 넣었다는 사실만으로 충분하지 않습니다. 외부 비밀 저장소를 런타임 controller가 참조하게 하거나, Git에는 암호화된 선언만 두고 복호화 키를 별도의 키 관리 시스템과 제한된 권한으로 보관하는 방식을 선택하겠습니다. 복호화 키와 암호문을 같은 접근 범위에 두면 저장소 유출 시 보호 경계가 약해집니다.

Argo CD나 Secret controller가 어느 namespace에 어떤 Secret을 만들 수 있는지, 어떤 service account가 값을 읽을 수 있는지 최소 권한으로 지정합니다. Git 저장소 읽기 권한, 클러스터 API 권한, 외부 비밀 저장소 권한을 하나의 운영자 권한으로 합치지 않겠습니다. diff·CI 로그·배포 이벤트·애플리케이션 로그에 원문이 나오지 않는지 확인하고, 비밀 이름이나 버전만 관측값으로 사용합니다. 개발·스테이징·운영의 경로와 키를 분리해 환경 혼동도 차단합니다.

전달과 실제 적용을 검증합니다

새 값이 Secret 객체에 반영됐다고 프로세스가 즉시 새 값을 사용하는 것은 아닙니다. 환경 변수 주입은 대개 프로세스 시작 시점의 값이고, 파일 마운트는 kubelet이 파일을 갱신해도 애플리케이션이 다시 읽거나 reload해야 반영됩니다. Deployment를 재시작해야 하는지, 앱이 파일 변경을 감시하는지, 연결 풀이 기존 자격을 계속 쓰는지를 확인하겠습니다. ‘Secret 생성 성공’, ‘Pod가 새 값을 읽음’, ‘외부 서비스가 새 자격을 승인함’을 서로 다른 검증 단계로 둡니다.

정상 교체는 새 자격을 먼저 만들고 소비자에게 전달한 뒤 생산자·애플리케이션을 전환하고, 모든 사용 경로가 새 버전으로 바뀐 것을 확인한 뒤 이전 자격을 폐기하는 순서가 안전합니다. 양쪽 키를 잠시 허용할 수 없는 자격은 짧은 중첩 기간 대신 조정된 점검 창과 즉시 회수 계획이 필요합니다. 유출이 의심되면 가용성을 위해 이전 키를 롤백하지 않고 즉시 revoke·rotate하며 접근 로그와 영향 범위를 조사합니다.

검증에는 Git 이력 검색, 권한이 다른 계정의 읽기 시도, controller 장애, Secret 갱신 뒤 Pod 재시작·reload, 이전 자격 폐기를 넣겠습니다. base64 디코딩이 가능한지를 확인하는 것만으로 끝내지 않고, 어느 사람이 어떤 경로로 원문에 접근할 수 있는지와 교체 뒤 실제 호출이 성공하는지를 기준으로 판단합니다.

비밀을 암호화해 Git에 저장하는 경우에도 키 접근이 배포 파이프라인 전체에 퍼지지 않게 하겠습니다. CI가 모든 환경의 복호화 키를 갖고 있고 신뢰하지 않는 PR 코드를 그 권한으로 실행하면, 빌드 코드나 로그를 통해 운영 비밀이 노출될 수 있습니다. 환경별 controller가 자기 namespace의 참조만 읽도록 하고, 복호화 시점과 메모리·임시 파일의 수명도 제한합니다. Secret 변경이 실패하면 새 Pod를 무조건 배포해 기존 연결을 끊기보다 마지막 정상 자격을 유지할지, 새 버전 rollout을 중단할지 명확히 정하겠습니다. 변경 전후의 버전과 실제 외부 인증 성공을 함께 기록해야 선언 상태와 실행 상태가 어긋난 채 정상으로 보이지 않습니다.