728x90
✅ 목표: Kubernetes에서 Secret을 애플리케이션에 전달할 때 사용하는
env 방식과 volumeMount 방식의 차이점을 정리하고,
보안 설계 전략 관점에서 어떤 방식이 적합한지 실습을 통해 비교합니다.
🔎 이번 글에서 수행할 작업 요약
- Secret 전달 방식 종류(env, volumeMount) 정리
- 각각의 방식으로 MinIO 인증 정보 주입 실습
- 보안, 편의성, 자동화 측면에서의 장단점 비교
- 실제 환경에서의 설계 가이드 정리
🧠 1단계: Secret 전달 방식 개념 정리
| 전달 방식 | 설명 | 장점 | 단점 |
| env | 환경 변수로 주입 | 간편, 코드 수정 불필요 | 환경 변수 노출 가능성 있음 |
| volumeMount | 파일로 마운트 | 파일 접근 제어 가능, 자동 회전 대응 | 코드가 파일 참조해야 함 |
✅ 민감 정보의 노출을 줄이기 위해 volumeMount 방식이 더 안전하다는 평가가 많음
그러나 Spark, PySpark 등 일부 툴은 환경 변수 방식에 더 최적화되어 있음
🛠️ 2단계: volumeMount 방식 Secret 전달 실습 (라인별 주석 포함)
# secret-vol-pod.yaml
apiVersion: v1
kind: Pod
metadata:
name: spark-secret-vol # 테스트 파드 이름
namespace: etl
spec:
containers:
- name: spark
image: bitnami/spark:latest # Spark 예제 이미지
command: ["sleep", "3600"] # 파드 대기 유지
volumeMounts:
- name: creds
mountPath: /etc/minio-secrets # 🔐 Secret이 파일로 마운트될 경로
readOnly: true # 읽기 전용 권장
volumes:
- name: creds
secret:
secretName: minio-credentials # 참조할 Secret 이름
kubectl apply -f secret-vol-pod.yaml
✅ 해당 파드에 들어가면 /etc/minio-secrets/AWS_ACCESS_KEY_ID 와 같은 파일이 생성되어 있음
MinIO 환경에서 MINIO_ACCESS_KEY와 MINIO_SECRET_KEY 환경 변수를 사용해야 하며,
이 값을 Secret으로 전달하여 MinIO에 접근할 수 있음.
🧪 3단계: 파드 내에서 두 방식 비교 확인
# 파드 접속
kubectl exec -it spark-secret-vol -n etl -- bash
# volumeMount 방식으로 확인
cat /etc/minio-secrets/MINIO_ACCESS_KEY
cat /etc/minio-secrets/MINIO_SECRET_KEY
# 환경 변수 방식은 설정되어 있지 않음
echo $MINIO_ACCESS_KEY
echo $MINIO_SECRET_KEY
☑️ volumeMount 방식은 파일 경로에 접근해야 하며, 코드 또는 설정에서 이 경로를 참조해야 함
🔍 4단계: 설계 시 고려할 보안 요소
- Secret의 자동 회전에 volumeMount 방식이 더 유리함 (파일 자동 갱신)
- 환경 변수는 kubectl describe pod 등으로 쉽게 노출될 수 있음
- RBAC과 함께 사용할 경우 volumeMount는 PodSpec 단위로 제한 가능
- 민감 정보가 CLI에 직접 노출되지 않도록 환경 구성 필요
📎 요약 및 핵심 정리
- Kubernetes Secret을 전달할 때 env와 volumeMount 방식은 각각의 장단점이 존재함
- env는 간편하지만 보안에 취약할 수 있고, volumeMount는 안전하지만 구현이 다소 복잡할 수 있음
- 보안 중심 설계에서는 volume 방식이 적합하며, 주기적 회전이나 RBAC 제한 적용도 용이함
- Spark와 같이 환경 변수 기반 구성이 필수인 경우에는 env 방식을 사용할 수 있으나,
운영 환경에서는 사전 보안 정책 검토가 반드시 필요함
728x90