Kubernetes Secret의 base64를 암호화로 생각하면 안 되는 이유
Secret의 data 표현은 쉽게 되돌릴 수 있는 인코딩입니다. 인코딩했으니 저장소에 올려도 된다고 판단하면 자격증명이 노출될 수 있습니다. Secret 객체를 읽을 권한 자체를 민감한 접근으로 다뤄야 합니다.
먼저 기억할 핵심
- base64는 비밀을 읽지 못하게 하는 암호화가 아닙니다
- 저장·접근·주입 경로를 각각 보호합니다
- 유출이 의심되면 값 교체와 사용처 갱신을 계획합니다
base64는 비밀을 읽지 못하게 하는 암호화가 아닙니다
Secret의 data 표현은 쉽게 되돌릴 수 있는 인코딩입니다. 인코딩했으니 저장소에 올려도 된다고 판단하면 자격증명이 노출될 수 있습니다. Secret 객체를 읽을 권한 자체를 민감한 접근으로 다뤄야 합니다.
저장·접근·주입 경로를 각각 보호합니다
etcd 저장 암호화, API 접근 권한, Pod에 전달되는 범위를 따로 검토합니다. 운영자가 디버깅 중 내용을 화면에 출력하는 경로도 관리합니다. 특정 네임스페이스에 객체를 두었다는 것만으로 모든 읽기 권한이 차단되는 것은 아닙니다.
유출이 의심되면 값 교체와 사용처 갱신을 계획합니다
파일을 지우는 것만으로 이미 복사된 토큰이 무효화되지 않습니다. 실제 자격증명 발급처에서 교체하고 이를 쓰는 워크로드가 새 값을 사용하도록 확인합니다. 공개 예제에는 비밀처럼 보이는 실값 대신 명확한 가짜 값을 씁니다.
서버 운영 실행 전 점검표
- base64는 비밀을 읽지 못하게 하는 암호화가 아닙니다
- 저장·접근·주입 경로를 각각 보호합니다
- 유출이 의심되면 값 교체와 사용처 갱신을 계획합니다
이 가이드의 근거 문서
출처 확인일: 2026-11-04. 공식 문서에 기반한 편집 가이드이며 직접 수행한 벤치마크가 아닙니다. 비용 사례는 명시된 가정에 한합니다.
오류 제보 방법