[쿠버네티스 어나더 클래스 - Sprint1] #6. Application 기능으로 이해하기#2 - Configmap, Secret

[참고]
본 글은 인프런의
<쿠버네티스 어나더 클래스 - Sprint 1, 2 (#실무기초 #설치 #배포 #Jenkins #Helm #ArgoCD)>
강의 내용과 실습을 바탕으로 정리한 기록입니다.

 

Configmap, Secret 기본 개념

쿠버네티스에서 ConfigMap과 Secret은 애플리케이션 코드와 설정값을 분리하여 외부에서 환경 데이터를 주입하기 위해 사용되는 오브젝트입니다.

• ConfigMap에 저장되는 데이터:
  • 인프라 환경 관련 값: 개발/검증/운영 환경(dev, stage, prod)에 따라 달라지는 설정
  • App 기능 제어 값: 기능 On/Off 스위치, 로깅 레벨 등
  • 외부 환경 주입 값: 외부 API 엔드포인트 URL 등 일반 설정 정보
• Secret에 저장되는 데이터:
  • DB 접속 정보: DB URL, 계정 및 비밀번호 (작성 시 stringData 필드 활용 가능)
  • 인코딩 방식: Secret 내부 데이터는 Base64로 인코딩되어 저장 (🚨 암호화가 아닌 단순 인코딩에 불과함)

 

 

 

💡 알아두면 좋은 점

• 중요 데이터를 반드시 Secret에 넣어야 하는 것은 아니며, 상황에 따라 ConfigMap에 두어도 동작상 문제는 없습니다.
• Secret은 보안 목적 외에도 쿠버네티스 내부 리소스 간 규격화된 데이터를 다룰 때 자주 활용됩니다.
• 데이터 암호화는 ConfigMap/Secret 오브젝트 자체의 기능과 별개의 영역으로 다루어야 합니다.

 

 

ConfigMap과 Secret을 수정하더라도 애플리케이션에 즉시 반영되지 않을 수 있습니다. 주입 방식에 따라 실시간 반영 여부가 결정됩니다.

• 환경변수(envFrom, env) 주입: App 기동 시점에 값이 결정되므로, ConfigMap/Secret을 수정해도 Pod를 재시작하기 전까지는 반영되지 않음
• 볼륨(volumes, volumeMounts) 주입: 파일 형태로 Pod 내부 디렉토리에 마운트되며, ConfigMap/Secret 변경 시 실시간(수 초~수 분 내)으로 파일 내용이 업데이트됨

 

 

 

 

 

 

🖥️ 동작 확인

✅ Configmap, Secret 입력값 확인

• 대시보드에서 확인하기

 

 

• 명령어로 확인하기

// Configmap 확인
$ kubectl describe -n anotherclass-123 configmaps api-tester-1231-properties
$ kubectl get -n anotherclass-123 configmaps api-tester-1231-properties -o yaml
$ kubectl get -n anotherclass-123 configmaps api-tester-1231-properties -o jsonpath='{.data}'

 

// Secret 확인
$ kubectl get -n anotherclass-123 secret api-tester-1231-postgresql -o yaml
$ kubectl get -n anotherclass-123 secret api-tester-1231-postgresql -o jsonpath='{.data}'

 

// Secret data에서 postgresql-info가 Key인 Value값만 조회 하기
kubectl get -n anotherclass-123 secret api-tester-1231-postgresql -o jsonpath='{.data.postgresql-info\.yaml}'

 

// Secret data에서 postgresql-info가 Key인 Value값을 Base64 디코딩해서 보기
kubectl get -n anotherclass-123 secret api-tester-1231-postgresql -o jsonpath='{.data.postgresql-info\.yaml}' | base64 -d

 

 

 

 

✅ 컨테이너 내부 주입 데이터 확인

 

// Configmap 환경 변수 확인
env

// Secret 파일 확인
ls /usr/src/myapp/datasource
cat /usr/src/myapp/datasource/postgresql-info.yaml

// java 실행 인자 확인
jps -v

 

 

 

 

✅ App API 조회 (/info), (/properties)

 

 

 

 

✅ Configmap 수정

configmap 만 수정했을 땐 app 기동 설정이 바뀌지 않음

application_role 이 여전히 ALL

 

 

 

 

secret 을 수정하면, 볼륨 마운트에 연결시켜놨기 때문에 값이 바뀜

 

 

 

 

✅ API 재확인 (/info), (/properties)

파드 삭제 전에는, configmap 은 적용 안되어 있고, secret 은 적용이 된 상태.

 

파드 재생성 후, Configmap 의 수정된 설정값 Role = GET

 

 

 

 

 

이름 때문에 기대가 컸던 Secret

 

Secret은 목적에 따라 type을 지정할 수 있으며, 각 타입에 맞는 정해진 Key-Value 템플릿 구조를 제공합니다.

• type: Opaque: 가장 기본 유형으로 ConfigMap과 유사한 Key-Value 구조
• type: kubernetes.io/docker-registry: 비공개 레지스트리(Docker Hub 등) 인증 정보 저장용 (정해진 Key값 사용)
• type: kubernetes.io/tls: Ingress 등에서 HTTPS 통신을 위한 TLS 인증서 및 개인키(tls.crt, tls.key) 저장용

 

이처럼 쿠버네티스는 사용자 편의를 위한 템플릿(Type)을 제공하지만, 어떤 Type도 데이터 자체를 암호화해주지는 않습니다.

 

 

 

그래서 중요 데이터에 대한 암호화는 어떻게 해야하나?

 

 

 

Secret이 자체 암호화를 제공하지 않기 때문에, 실무에서는 중요 데이터를 안전하게 관리하기 위해 다음 3가지 방안을 사용합니다.

• 관리방안 1. 클러스터 내 직접 관리 (접근 제어)
  • RBAC(Role-Based Access Control)을 사용해 Secret 리소스에 접근할 수 있는 권한을 엄격히 제한
• 관리방안 2. 애플리케이션 단 자체 암호화 (추천 ⭐)
  • Secret에는 처음부터 암호화된 값을 저장하고, App 내부 복호화 로직을 통해 실행 시점에 복호화하여 사용
• 관리방안 3. 서드파티 솔루션 연동 (추천 ⭐)
  • Vault, AWS Secrets Manager 등 전문 외부 보안 관리 솔루션을 연동하여 사용

 

 

Secret이라는 이름 때문에 당연히 데이터 암호화를 제공할 것으로 기대하기 쉽지만, 실상은 Base64 인코딩일 뿐입니다.

데이터 노출을 원천 차단하려면 관리방안 2, 3 처럼 관리하는 것이 권장됩니다.