[Kubernetes] 쿠버네티스의 Secret 및 ConfigMap

쿠버네티스의 Secret 및 ConfigMap

쿠버네티스(Kubernetes)에서 애플리케이션을 구성할 때 ConfigMap과 Secret은 매우 중요한 리소스 유형임.

 

ConfigMap - 정의

ConfigMap은 애플리케이션이 사용하는 구성(configuration) 데이터를 키-값(key-value) 쌍 형태로 저장하는 쿠버네티스 오브젝트임.

예컨대 데이터베이스 연결 정보, 외부 API의 엔드포인트 주소, 환경 변수, 설정 파일 내용 등을 관리할 수 있음.

ConfigMap 자체는 암호화되지 않은 일반 텍스트 형태로 데이터가 저장되므로 민감하지 않은 구성 정보에 사용하는 것을 권장함.

 

ConfigMap - 주요 특징

1. Key-Value 저장 구조

data나 binaryData 필드에 JSON, YAML, INI, Properties 형식 등 거의 모든 종류의 텍스트를 저장할 수 있음.

apiVersion: v1
kind: ConfigMap
metadata:
  name: my-config
data:
  DB_HOST: my-database.example.com
  DB_PORT: "5432"
  config.properties: |
    key1=value1
    key2=value2

DB_HOST, DB_PORT 값으로도 사용하고, config.properties라는 파일 형태로도 제공함.

 

2. EnvFrom, Volume 등 다양한 매핑 방법

파드(Pod)나 컨테이너에 환경 변수로 주입(envFrom)

파일로 마운트(Volume)하여 컨테이너 내부에서 사용

CLI에서 직접 참조(kubectl create configmap --from-file=... 등)

apiVersion: v1
kind: Pod
metadata:
  name: configmap-env-pod
spec:
  containers:
  - name: myapp-container
    image: myapp-image
    envFrom:
    - configMapRef:
        name: my-config

컨테이너에서는 DB_HOST 등을 환경 변수로 사용할 수 있음.

 

 

3. 확장성

하나의 ConfigMap에 여러 값(파일)을 동시에 저장할 수 있으므로 애플리케이션 설정을 일괄적으로 관리하기가 쉬움.

보통 ConfigMap을 여러 개 만들어 도메인별로 구성 정보를 분할 관리하기도 함.

 

4. Versioning(버전 관리)

쿠버네티스 네이티브 리소스 자체로는 버전 관리 기능이 없음.

변경 이력 관리가 필요한 경우에는 GitOps 도구(예: Argo CD, Flux)나 Helm을 활용하거나, CI/CD 파이프라인에서 Manifest 파일을 Git으로 버전 관리함.

 

ConfigMap - 사용 사례

1. 외부 API 엔드포인트 주소 관리

개발/테스트/운영 환경마다 다른 엔드포인트 주소를 설정해야 할 때 유용함.

 

2. 환경 변수로 사용되는 일반 설정 값

애플리케이션이 동작하는 데 필요한 로깅 레벨, 타임아웃 값 등.

 

3. 애플리케이션 설정 파일 저장

Tomcat의 server.xml, Spring Boot의 application.yaml 등 여러 설정 파일을 ConfigMap에 담아 파드가 시작될 때 마운트해 사용.

 

4. 동적으로 변경 가능한 값

파드 재시작 없이도 참조 중인 ConfigMap을 수정하면 자동으로 업데이트(마운트된 경우는 파일 시스템 레벨에서 업데이트)되지만, 애플리케이션이 해당 변경 사항을 인식하는 별도의 로직이 있어야 함.

일부 애플리케이션은 설정 파일 변경 사항을 재로드할 수 없을 수도 있으므로 주의가 필요함.

 

Secret - 정의

Secret은 민감한 데이터(비밀번호, 토큰, 인증서 등)를 안전하게(상대적으로) 저장하기 위한 쿠버네티스 오브젝트임.

기본적으로 Base64로 인코딩되어 저장됨.

Base64 자체가 보안을 제공하는 것은 아니지만, ConfigMap과 달리 Secret은 쿠버네티스 RBAC(Role-Based Access Control) 정책에서 별도의 권한으로 보호됨.

쿠버네티스 v1.25 이후에는 [Secret Encryption at Rest(디스크 저장 시 암호화)] 기능이 기본적으로 활성화되는 클러스터도 많음.

이를 통해 etcd에 저장되는 Secret 데이터를 암호화할 수 있음.

 

Secret - 주요 특징

1. 민감 정보 관리

DB 비밀번호, 인증 토큰, SSH 키, TLS 인증서 등이 대표적인 예시임.

apiVersion: v1
kind: Secret
metadata:
  name: my-secret
type: Opaque
data:
  username: YWRtaW4=   # Base64 인코딩된 "admin"
  password: cGFzc3dvcmQ=  # Base64 인코딩된 "password"

실제 데이터는 data 필드에 Base64로 인코딩되어 입력됨.

 

 

2. Type 구분

Secret은 Opaque, kubernetes.io/basic-auth, kubernetes.io/ssh-auth, kubernetes.io/tls 등 다양한 유형이 있음.

 

Opaque: 일반적인 사용자 정의 Secret 유형

kubernetes.io/tls: TLS 인증서(.crt, .key) 관리

kubernetes.io/dockerconfigjson: Docker 레지스트리 접근 자격 증명(이미지 풀 시 필요)

 

Secret 타입에 따라 쿠버네티스가 자동으로 처리(예: kubernetes.io/tls는 TLS 인증서 관련 필드 자동 인식)하기도 함.

 

 

 

3. Volume, envFrom, 이미지 풀(Image Pull) 등 다양한 사용

다른 리소스와 유사하게 파드에서 환경 변수로 주입하거나 파일 형태로 마운트할 수 있음.

시크릿으로 관리된 Docker 레지스트리 자격 증명(imagePullSecrets)을 사용하여 Private 레지스트리에 접근할 수도 있음.

 

 

4. RBAC & Network Policy

쿠버네티스는 Secret에 대한 조회 권한을 별도로 설정할 수 있음(RBAC).

운영 환경에서 Secret을 안전하게 보호하려면 접근 권한 설계를 철저히 해야 함.

Pod가 Secret을 마운트해 사용하더라도, 네트워크 레벨에서 파드 컨테이너 간 트래픽 보호, Namespace 분리, RBAC 정책 연계 등을 종합적으로 고려해야 함.

 

 

5. 암호화(Encryption) & Key Management

etcd에 저장될 때 Secret을 암호화하기 위해 쿠버네티스에서는 EncryptionConfiguration을 설정할 수 있음.

GKE, EKS, AKS 등 Managed Kubernetes 환경에서는 디폴트로 Secret 암호화를 제공하거나, KMS(Key Management Service) 연동을 통해 안전하게 관리할 수 있음.

 

Secret - 사용 사례

1. 데이터베이스 사용자명/비밀번호

대부분의 애플리케이션이 DB 자격 증명을 필요로 하므로 Secret으로 관리하는 것은 필수임.

 

2. API 인증 토큰 및 인증서(TLS, SSH 키 등)

외부 서비스(예: GitHub, Payment Gateway) 사용 시 필요한 토큰이나 키를 보관.

 

3. Docker 레지스트리 인증

Private Registry에서 이미지를 당겨올 때(imagePullSecrets) Secret을 사용.

 

4. 서버 사이드 TLS 인증서

HTTPS 트래픽 종단(ingress controller 등)에 필요한 인증서(key, crt)를 Secret으로 관리.

 

ConfigMap 및 Secret 비교

1. ConfigMap

용도 : 일반 구성값 저장 (민감하지 않은 데이터)

데이터 형식 : Base64 인코딩 없이 평문 (Plain Text)

보안 : 상대적으로 낮음, RBAC에 의해 보호 가능하지만 보안 강도는 Secret 보다 약함

마운트/주입 방식 : envForm, VolumeMounts, CLI 등 동일

기본 타입 : 없음

주요 활용 사례 : 애플리케이션 구성 파일, 환경변수 등

 

2. Secret

용도 : 비밀번호, 토큰, 인증서 및 민감 정보

데이터 형식 : 기본적으로 Base64 인코딩 후 저장

보안 : RBAC와 Encryption at Rest로 좀 더 안전한 보호 가능

마운트/주입 방식 : envForm, volumeMounts, imagePullSecrets 등 동일

기본 타입 : Opaque, TLS, Docker config 등 여러 타입

주요 활용 사례 : DB 비밀번호, API 토큰, 인증서 등 민감 정보

 

좋은 사례

1. 민감 정보와 일반 설정 값 분리

보안 사고를 예방하기 위해 민감 정보(비밀번호, 토큰 등)는 반드시 Secret을 사용하고, 일반 설정 값(API 엔드포인트 등)은 ConfigMap에 저장

 

2. RBAC 정책 설계

Secret, ConfigMap 각각에 대한 접근 권한을 최소화

원칙적으로 파드는 필요한 Secret만 참조할 수 있어야 함

가능하다면 Namespace 레벨로 분리하여, 서로 다른 팀/서비스가 다른 네임스페이스의 Secret에 접근하지 못하도록 해야함

 

3. GitOps 파이프라인과 연동

민감 정보도 Git에 평문으로 저장하면 안 됨.

HashiCorp Vault, Mozilla SOPS, Sealed Secrets 등의 도구를 활용해 민감 정보를 암호화된 형태로 Git 저장소에 보관한 후, 쿠버네티스 클러스터에 배포하는 방식을 사용함.

ConfigMap은 비교적 평문으로 Git에 저장해도 되지만, 여전히 접근 관리는 주의가 필요함.

 

4. Encryption at Rest 활성화

클라우드 벤더가 제공하는 Managed Kubernetes를 사용할 경우 대부분 디폴트로 활성화되어 있지만, 자체 관리형 쿠버네티스(온프레미스 등)라면 EncryptionConfiguration을 설정하여 etcd에 저장되는 Secret을 암호화 처리.

 

5. Rotation(주기적 교체)

Secret으로 관리되는 자격 증명은 주기적으로 교체(Rotation)하는 것이 좋음.

자동 교체 로직(예: 외부 Vault, 외부 KMS)을 사용해 자격 증명을 교체하면, 컨테이너가 해당 Secret을 변경 인식 후 재시작하거나 다이나믹하게 업데이트하도록 구성할 수 있음.

 

6. 읽기 전용 마운트(Read-Only Volume Mount)

ConfigMap과 Secret을 Pod에 마운트 시킬 때, readOnly: true 옵션을 통해 불필요한 쓰기 작업을 막고 안정성을 높일 수 있음.

 

7. 사용하지 않는 Secret/ConfigMap 정리

장기간 사용하지 않는 Secret/ConfigMap이 남아 있다면, 보안상 및 운영 측면에서 관리 오버헤드를 줄이기 위해 정기적으로 정리

 

정리

ConfigMap은 애플리케이션이 필요로 하는 일반적인 구성 정보를 관리하며, 텍스트 형태의 파일이나 키-값 쌍으로 저장할 수 있어 유연함.

Secret은 비밀번호, 인증서, 토큰 등 민감 정보를 다루며, 쿠버네티스에서 RBAC와 암호화를 통한 별도의 보호 계층을 제공함.

 

실제 운영 환경에서는 Secret과 ConfigMap을 적절히 조합하여 사용하고, RBAC와 GitOps, 키 관리(KMS, Vault) 등의 도구를 통해 안전하고 체계적으로 구성/배포/회수(rotate)할 수 있어야 함.

이를 통해 쿠버네티스 환경의 보안을 강화하면서도 애플리케이션을 유연하게 설정하고 관리할 수 있음.