Kubernetes Secret 문제

 

 

Kubernetes Secret 의 가장 큰 문제는 한 줄로 말하면:

"이름은 Secret인데,
기본 상태만으로는 완전한 보안 저장소가 아니다"

 

라는 점이다.

특히 실무에서 많이 오해한다.

---

가장 큰 오해

많은 사람들이:

Secret = 암호화 저장

 

이라고 생각한다.

---

그런데 기본 Kubernetes Secret은?

사실상:

Base64 인코딩

 

에 가깝다.

---

예시

 

apiVersion: v1
kind: Secret
data:
  password: YWRtaW4xMjM0

 

---

이 값은?

 

echo YWRtaW4xMjM0 | base64 -d

 

---

옵션 설명

옵션의미

base64	Base64 처리
-d	decode(복호화 아님)

---

결과

admin1234

 

바로 나온다.

---

즉 핵심 문제

기본 Secret은 "숨김"이지
강한 암호화가 아님

 

---

왜 이렇게 설계했나?

Kubernetes Secret 목적은 원래:

ConfigMap과 구분

 

정도 느낌이 강했다.

즉:

• 로그 노출 방지
• 일반 YAML 분리

용도.

---

실제 위험한 부분

---

문제 1 — etcd 저장

Kubernetes Secret은 결국:

etcd

 

에 저장된다.

---

etcd란?

etcd

Kubernetes의 핵심 메타데이터 저장소.

---

문제

기본 설정에서는:

etcd에 평문 수준 저장 가능

 

하다.

---

즉 etcd 접근 가능하면?

• DB Password
• API Key
• TLS Key

전부 노출 가능.

---

문제 2 — kubectl 권한

예:

 

kubectl get secret mysecret -o yaml

 

---

옵션 설명

옵션의미

get	리소스 조회
-o yaml	YAML 출력

---

권한만 있으면 Secret 조회 가능.

---

즉 RBAC 매우 중요.

---

문제 3 — Pod 내부 노출

Secret은 보통:

• env
• volume mount

방식 사용.

---

env 방식

 

env:
- name: DB_PASSWORD
  valueFrom:
    secretKeyRef:

 

---

문제

환경변수는:

process memory

 

에 존재.

---

즉:

• crash dump
• proc
• log

등으로 노출 가능.

---

volume mount 방식도 완벽 아님

 

volumeMounts:
- mountPath: /etc/secret

 

---

Pod 탈취 시 파일 읽기 가능.

---

문제 4 — Git 저장 사고

엄청 흔함.

---

예:

 

data:
  password: YWRtaW4xMjM0

 

---

개발자가:

"인코딩돼 있으니 안전"

 

착각하고 Git 업로드.

---

실제론 누구나 decode 가능.

---

문제 5 — Namespace 공유 문제

권한 잘못 설정 시:

다른 서비스 Secret 접근

 

가능할 수 있음.

---

문제 6 — Rotation 어려움

예:

DB Password 변경

 

하면:

• Secret 수정
• Pod restart

필요한 경우 많음.

---

즉 동적 관리 어려움.

---

그래서 등장한 보완책

---

1. etcd Encryption

엄청 중요.

---

Kubernetes 설정:

 

kind: EncryptionConfiguration

 

---

의미

etcd 저장 시 암호화

 

---

즉 디스크 탈취 대비 가능.

---

2. RBAC 최소화

예:

특정 Namespace만 조회 가능

 

---

핵심:

secret read 권한 최소화

 

---

3. External Secret 사용

현재 실무 핵심.

---

구조

Vault/AWS Secret Manager
↓
External Secret Operator
↓
K8s Secret

 

---

즉 Kubernetes 자체에 장기 Secret 최소화.

---

대표 도구

도구설명

External Secrets Operator	가장 유명
Sealed Secrets	암호화 Git 저장
CSI Secret Store	런타임 주입

---

4. Sealed Secret

Bitnami Sealed Secrets

---

핵심

Git에는 암호화 상태 저장

 

---

Cluster 내부에서만 복호화 가능.

---

GitOps 환경에서 많이 사용.

---

5. Secret Store CSI Driver

현재 매우 중요.

---

특징

Secret을 Pod 시작 시 동적 마운트

 

---

즉:

K8s Secret 자체 저장 최소화

 

가능.

---

Vault 연동 많이 사용.

---

실무 추천 방식

---

소규모

K8s Secret + RBAC

 

---

중대규모

Vault/AWS Secret Manager
+
External Secret

 

---

금융/고보안

동적 Secret
+
CSI Driver
+
짧은 TTL

 

---

환경변수 vs Volume

실무에서는 보통:

방식추천도

env	편하지만 노출 위험
mounted file	상대적으로 나음

---

왜 volume 선호?

환경변수는:

process 전체에 노출

 

될 수 있기 때문.

---

핵심 한 줄

Kubernetes Secret의 가장 큰 문제는:

기본 상태에서는 Base64 인코딩 수준에 가깝고,
etcd·환경변수·RBAC 설정 실수 등을 통해 쉽게 노출될 수 있다는 점

 

이며,

실무에서는 보통:

etcd Encryption
+
최소 권한 RBAC
+
Vault/AWS Secret Manager 연동

 

구조로 보완한다.