쿠버네티스 워크로드에서 시크릿을 '아예 빼버리는' 방법, Kloak가 제안하는 새로운 시크릿 관리

쿠버네티스의 오래된 골칫거리, '시크릿(Secret)'

쿠버네티스(Kubernetes, 줄여서 K8s)에서 일해본 분들은 한 번쯤 "시크릿 관리 진짜 골치 아프다"라고 느꼈을 거예요. 시크릿이라는 게 뭐냐면, 데이터베이스 비밀번호, API 키, 인증서 같은 "바깥에 새면 큰일 나는 값들"이에요. 쿠버네티스에는 기본적으로 Secret이라는 리소스가 있긴 한데, 이게 실은 base64로 인코딩만 된 평문 이에요. 암호화가 아니에요. 그냥 "읽기 어렵게 한 글자 변환"일 뿐이라서, etcd(쿠버네티스의 데이터 저장소)에 저장될 때도 평문에 가까운 상태로 누워있어요.

그래서 보통은 외부 시크릿 매니저를 붙여요. HashiCorp Vault, AWS Secrets Manager, GCP Secret Manager 같은 것들이요. External Secrets Operator를 깔아서 외부 시크릿을 K8s Secret 리소스로 동기화해서 쓰는 패턴이 일반적이고요. 그런데 이 방식에도 빈틈이 있어요. 결국 파드(Pod, 컨테이너 묶음) 안의 환경변수나 파일에 평문 시크릿이 들어간다 는 거예요. 한 번이라도 컨테이너 안에 시크릿이 노출되면, 그 컨테이너가 해킹당했을 때 시크릿도 같이 털려요.

Kloak이 던지는 발상의 전환

이번에 공개된 Kloak 이라는 도구의 아이디어는 한마디로 이거예요. "워크로드(애플리케이션 컨테이너)가 아예 시크릿을 갖고 있지 않게 하자." 컨테이너 안에서 "DB 비밀번호 줘"라고 하지 말고, "DB에 이 쿼리 좀 보내줘"라고만 하라는 거예요. 그러면 시크릿을 들고 있는 별도의 게이트웨이가 대신 인증해주고 결과만 돌려주는 식이에요.

이게 왜 안전하냐면, 컨테이너가 해킹당해도 거기서 빼낼 시크릿이 "없기" 때문이에요. 환경변수에도 없고, 마운트된 파일에도 없고, 메모리에도 없어요. 시크릿은 별도 격리된 공간(Kloak의 프록시/사이드카 또는 클러스터 내 전용 컴포넌트)에 머물러 있고, 워크로드는 그저 "필요한 작업"을 요청할 뿐이에요. 비유하자면, 직원에게 회사 금고 비밀번호를 알려주는 대신, 금고지기를 한 명 두고 "이 서류 좀 꺼내달라"고 부탁하게 만드는 거예요. 직원이 도청을 당해도 비밀번호는 새지 않아요.

어떻게 동작하냐면

구체적인 작동 방식은 보통 이런 패턴이에요. 워크로드는 평소처럼 데이터베이스나 API 엔드포인트로 요청을 보내요. 그런데 그 요청은 사실 Kloak이 제공하는 로컬 프록시(보통 사이드카나 노드 데몬 형태)로 먼저 가요. 프록시는 "아, 이건 RDS 접속 요청이구나" 하고 판단해서, 자신이 안전하게 보관하고 있던 자격증명을 붙여서 진짜 백엔드로 트래픽을 흘려보내요. 응답이 오면 워크로드한테는 정상 응답처럼 돌려주고요.

이런 패턴은 사실 보안 업계에서 "시크릿리스(secretless) 아키텍처"라고 불러요. 또 워크로드의 신원(identity)을 검증하는 단계도 들어가는데, 보통 SPIFFE/SPIRE 같은 워크로드 신원 표준이나 K8s ServiceAccount 토큰을 통해 "이 파드가 진짜 그 파드 맞아?"를 확인해요. 신원이 확인되면 정책(Policy)에 따라 "이 파드는 이 DB는 되는데 저 API는 안 됨" 같은 규칙으로 접근을 통제하고요.

비슷한 도구들과 비교해보면

이 영역에는 이미 몇몇 강자들이 있어요. HashiCorp Boundary, CyberArk Conjur(Secretless Broker), Teleport Machine ID, 그리고 Vault Agent가 비슷한 사상을 가져요. 차이는 운영 모델과 통합 깊이에 있어요. 예를 들어 Vault Agent는 시크릿을 파일로 떨어뜨려주는 방식이라 "결국 워크로드가 한 번은 본다"는 한계가 있고요, Conjur Secretless Broker는 시크릿리스 프록시 모델이지만 통합 작업이 꽤 무거운 편이에요. Kloak은 이 "시크릿리스"를 K8s 환경에 좀 더 가볍게 끼워 넣는 데 초점을 둔 도구로 보여요.

또 하나 흐름으로 보면, 최근 보안 업계는 "제로 트러스트(Zero Trust)" 라는 사상으로 가고 있어요. "네트워크 내부도 못 믿는다, 모든 요청은 매번 검증한다"는 철학이에요. 그 흐름 위에서 "애초에 시크릿을 뿌리지 않는다"는 건 자연스러운 다음 단계예요. SPIFFE/SPIRE, Istio mTLS, 그리고 시크릿리스 프록시들이 함께 묶여서 "워크로드가 자기 신원만으로 모든 걸 해결하는 세상"을 향해 가고 있어요.

한국 개발자에게는 어떤 의미가 있냐면

실무에서 K8s를 운영 중인 팀이라면 시크릿 관리는 늘 "언젠가 정리해야지" 하는 숙제로 남아 있을 거예요. 환경변수에 박혀 있는 평문 비밀번호, Helm values.yaml에 들어간 토큰, ConfigMap에 잘못 들어간 API 키 같은 게 실수로 깃허브에 푸시돼서 사고 나는 경우가 정말 많거든요. 시크릿리스 패턴은 이런 사고의 "원인 자체"를 없애는 접근이라서, 한 번쯤 진지하게 검토할 가치가 있어요.

다만 도입 비용은 솔직히 따져봐야 해요. 모든 클라이언트 라이브러리가 프록시를 통해도 잘 동작하는지 검증해야 하고, 운영팀이 새 컴포넌트를 학습하고 모니터링해야 해요. 또 프록시가 죽으면 모든 워크로드의 외부 통신이 끊기니까, 프록시 자체의 가용성 이 새로운 단일 장애점이 될 수 있어요. 이런 트레이드오프를 알고 도입하는 것과 모르고 도입하는 건 운영 안정성에서 큰 차이를 만들어요.

작은 팀이라면 우선은 External Secrets + KMS 암호화 정도로 시작하고, 보안 성숙도가 올라갈수록 시크릿리스 모델로 넘어가는 단계적 접근을 추천해요. 핀테크나 헬스케어처럼 규제 대상 도메인이라면 처음부터 시크릿리스 아키텍처를 고려해두는 게 감사(audit) 대응 면에서도 유리하고요.