Access denied for user - Kubernetes + ArgoCD

문제

---

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

 

플젝하랴, 이력서 작성하랴 바쁘게 지내고 있는데 쿠버네티스 클러스터 내에서 ArgoCD로 배포를 진행하는 와중에 특정 서비스에서 저런 에러 로그가 발생했다.

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

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

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

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

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

 

해결

---

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

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

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

 

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

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

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

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

있어

 

내친 김에 Base64도 알아보자!

 

Base64란 무엇인가

---

Base64는 이진 데이터를 64개의 ASCII 문자로 변환하는 인코딩 방식이다. 이 방식은 8비트 이진 데이터를 문자 코드에 영향을 받지 않는 공통 ASCII 문자로 바꾸어, 텍스트 기반 시스템에서 안전하게 전송할 수 있게 한다. 주로 이메일 첨부나 HTML에 이미지를 포함할 때 사용되며, 데이터 크기가 약 33% 증가하지만 플랫폼 간 호환성을 보장한다.

Base64는 바이너리 데이터의 손실을 막기 위해 개발되었다. ASCII는 7비트 인코딩인데, 시스템마다 나머지 1비트를 다르게 처리하거나 제어 문자 코드가 달라 문제가 발생할 수 있다. Base64는 안전한 64개 문자(A-Z, a-z, 0-9, +, /)만 사용해 이러한 문제를 해결한다. 예를 들어, API 응답에서 이진 데이터를 전송하거나 인증 키를 HTTP 헤더로 보낼 때 유용하다.

Base64 인코딩 과정

인코딩은 3바이트(24비트) 이진 데이터를 4개의 6비트 그룹으로 나누어 처리한다. 각 그룹을 10진수로 변환한 후, Base64 테이블에 매핑된 문자로 바꾼다. 만약 데이터가 3바이트 단위가 아니면 =으로 패딩한다. 예를 들어, "Man"은 이진으로 01001101 01100001 01101110이 되고, 6비트로 나누어 TWFu로 인코딩된다.

아래는 Base64 변환 테이블의 예시이다.

값	범위문자
0-25	A-Z
26-51	a-z
52-61	0-9
62	+
63	/

 

토스페이먼츠 API처럼 시크릿 키를 Base64로 변환해 인증에 활용한다. 이미지 데이터를 HTML에 직접 포함할 때도 Base64를 사용한다.

주의점과 한계

Base64는 암호화가 아니라 단순 변환일 뿐이므로 보안 목적으로는 부적합하다. 데이터 크기 증가로 효율이 떨어질 수 있으니, 대용량 파일에는 압축 후 적용하는 게 좋다.

 

 

생각

---

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