Access denied for user - Base64의 함정(?)

문제

---

2025-08-12T15:59:30.088Z WARN 1 --- [ main] o.m.jdbc.message.server.ErrorPacket : Error: 1698-28000: Access denied for user 'root
'@'192.xxx.x.xxx'

 

쿠버네티스 클러스터 내에서 ArgoCD로 배포를 진행하는 와중에 특정 서비스에서 저런 에러 로그가 발생했다.

말 그대로 DB 연결이 안된다는 의미다. 

처음에는 "뭐지? 환경 변수가 잘못됐나?" 싶어서 Base64로 인코딩된 변수들을 직접 디코딩해보았다. 문제가 없었다! 값은 잘 있다.

그래서 다음엔 DB 계정의 아이디, 비밀번호, 권한 순으로 찾아보았다. 이 또한 잘못된 것은 없었다.

Deployment yaml 파일이 잘못 작성되었나 싶었다. 물론 이것도 이상한 건 없었다.

마지막으로 혹시 모르니 JDBC URL에 아이디와 비밀번호를 명시하고 실행해보았다. 접속이 되었다! 그런데 Secret 파일에 명시한 내용 그대로 넣었을 뿐이다. 환경 변수 바인딩이 안될 이유가 전혀 없다. 원인을 규명하던 중 다시 환경 변수를 분석해보았다.

 

해결

---

아니나 다를까, 환경 변수의 문제가 맞았다.

디코딩만 확인했기에 이번엔 인코딩까지 해볼까 싶어서 확인해봤더니

cm9vdAo=   --> root/n  원문 + 엔터
cm9vdA==   --> root   원문

 

원문에 개행 문자(/n)가 삽입돼있었다. 이러니 디코딩을 해도 표시되지 않았던 것이다.

팀원이 secret 파일을 적용하는 과정에서 -n 옵션을 명시하지 않은 것이었다..!

Base64는 블록체인에 사용되는 해시가 아니기 때문에 점 하나 들어간다고 기존 인코딩 결과 전체가 바뀌지 않는다. 그래서 더욱 식별하기 어려웠다. 초기에 예상했던 환경변수 문제가 맞았는데 이런 특성을 놓쳐서 시간이 더 오래 걸렸던 것 같다.

괜찮다. 실수할 수 있다. 이번 경험 덕분에 Base64에 대해 더 알아가게 됐다. 얻은 건 있다.

있어

 

 

생각

---

Base64는 암호화가 아니라 바이너리 데이터를 위한 변환이다. 문득 "그럼 왜 Secret이지?"라는 생각이 들었다. YAML이나 JSON 같은 텍스트 기반 매니페스트에서 바이너리 데이터를 직접 다룰 수 없어 Base64 인코딩을 사용해 이진 데이터를 안전한 텍스트 문자열로 변환한다. 이는 암호화가 아니라 단순 난독화로, 데이터 호환성만을 보장한다. 자체적으로 보안을 수행하는 게 아니니 Secret이라고 불릴 이유가 없다고 생각했다. 그리하여 찾아보니 쿠버네티스 초기 설계에서 민감 정보를 분리하는 데에 초점을 두어서 그렇다고 한다. 실제 보안은 RBAC 제한과 etcd 암호화에 의존하지만 명칭이 Secret이란 것만으로 민감한 정보라는 것을 바로 알 수 있다. 쿠버네티스를 사용한다면 다수가 협업하는 상황일 테고 직관적으로 중요한 정보라는 것을 알려주는 명칭이 확실히 효율적이다.