Infra

Apr 2, 2026

Kubernetes Secret 가이드: 민감한 값을 어떻게 다뤄야 할까

쿠버네티스에서 앱 설정을 분리하다 보면 곧바로 마주치는 질문이 있습니다. 일반 설정은 ConfigMap으로 뺄 수 있는데, 비밀번호나 토큰 같은 민감한 값은 어디에 둬야 할까 하는 질문입니다.

이때 등장하는 리소스가 Secret입니다. Secret은 민감한 값을 Pod에 전달하는 표준적인 방법 중 하나입니다.

이 글에서는 아래 내용을 정리합니다.

Secret이 무엇인지
ConfigMap과 어떤 차이가 있는지
환경 변수와 파일 마운트로 어떻게 쓰는지

핵심은 Secret은 일반 설정이 아니라, 노출되면 위험한 값을 분리해 전달하기 위한 리소스라는 점입니다.

Kubernetes Secret이란 무엇인가

Secret은 비밀번호, API 토큰, 인증서 키 같은 민감한 값을 저장하고 Pod에 주입하기 위한 리소스입니다.

예를 들면 이런 값들이 들어갑니다.

데이터베이스 비밀번호
외부 API 토큰
TLS private key
Docker registry 인증 정보

즉, Secret은 “설정” 중에서도 특히 보호가 필요한 값을 위한 계층입니다.

ConfigMap 과 Secret 은 무엇이 다를까

입문 단계에서는 둘 다 key-value 저장소처럼 보여서 헷갈리기 쉽습니다.

ConfigMap: 일반 설정값
Secret: 민감한 값

예를 들어:

ConfigMap: 로그 레벨, API 주소, feature flag
Secret: DB 패스워드, access token, private key

기술적으로는 ConfigMap에도 문자열을 넣을 수 있지만, 보안적으로 민감한 값은 Secret으로 분리하는 편이 맞습니다.

가장 기본적인 Secret 예시

apiVersion: v1
kind: Secret
metadata:
  name: app-secret
type: Opaque
stringData:
  DB_PASSWORD: super-secret-password
  API_TOKEN: my-token

입문용 예제에서는 stringData가 이해하기 쉽습니다. 사람이 읽는 문자열을 넣으면 Kubernetes가 내부 표현으로 처리합니다.

실무에서는 Secret 자체를 Git에 어떻게 보관할지, 외부 secret manager와 어떻게 연동할지도 같이 고민하게 됩니다. 하지만 입문 단계에서는 우선 “민감한 값을 별도 리소스로 분리한다”는 감각이 중요합니다.

환경 변수로 Secret 주입하기

가장 흔한 방식 중 하나입니다.

env:
  - name: DB_PASSWORD
    valueFrom:
      secretKeyRef:
        name: app-secret
        key: DB_PASSWORD

이렇게 하면 컨테이너 안에서 DB_PASSWORD 환경 변수로 값을 읽을 수 있습니다.

앱이 환경 변수 기반 설정을 많이 쓰는 구조라면 이 방식이 가장 직관적입니다.

파일처럼 마운트하기

인증서 파일이나 키 파일처럼, 앱이 파일 경로를 직접 읽는 경우에는 Secret을 볼륨으로 마운트하는 방식이 더 자연스럽습니다.

예를 들어 TLS 인증서나 SSH 키처럼 파일로 필요한 경우에 잘 맞습니다.

이 방식은:

인증서 파일
private key
라이브러리가 파일 경로를 요구하는 자격 증명

같은 상황에서 자주 쓰입니다.

Secret 이라고 해서 완전히 안전한가

이 부분은 너무 단순하게 생각하면 안 됩니다. Secret은 민감한 값을 위한 리소스이지만, “자동으로 완전한 보안이 보장된다”는 뜻은 아닙니다.

중요한 건:

누가 Secret을 읽을 수 있는지
etcd 암호화가 되어 있는지
Git에 어떻게 저장하는지
로그나 환경 변수 출력으로 새지 않는지

즉, Secret은 시작점이지 보안의 끝이 아닙니다.

자주 하는 실수

1. Secret 값을 Git에 그대로 커밋하기

입문 예제에서는 흔하지만, 실제 민감 정보는 그대로 커밋하지 않는 편이 맞습니다.

2. Secret을 환경 변수로 넣고 로그에 그대로 찍기

앱 디버그 로그나 에러 메시지로 값이 새는 경우가 생각보다 흔합니다.

3. Secret과 ConfigMap 경계를 대충 잡기

운영하다 보면 어떤 값이 민감한지 기준이 흐려질 수 있습니다. 애매하면 민감하게 보는 편이 더 안전합니다.

처음 공부할 때 추천하는 실습

DB 비밀번호를 Secret으로 만들기
앱에서 환경 변수로 읽기
같은 값을 ConfigMap으로 넣었을 때와 의미 차이 비교하기
인증서 파일을 볼륨 마운트하는 예시도 한 번 보기

이 실습을 해 보면 Secret이 “값 저장소”가 아니라, 민감한 값을 다루는 별도 운영 경계라는 점이 더 또렷해집니다.

FAQ

Q. Secret은 base64라서 암호화된 건가요?

기본적으로는 인코딩에 가깝습니다. 별도의 보안 구성을 같이 봐야 합니다.

Q. Secret도 환경 변수로 넣어도 되나요?

가능합니다. 다만 노출 경로와 로그 출력 습관을 같이 조심해야 합니다.

Q. 작은 프로젝트도 Secret을 나눠야 하나요?

민감한 값이라면 규모와 상관없이 분리하는 습관이 좋습니다.

먼저 읽어볼 가이드

검색 유입이 많은 핵심 글부터 이어서 보세요.