동블

그래프 뷰

02. ConfigMap Secret Volume 상세

9 min read

이 문서를 통해 아래 질문들에 답할 수 있게 됩니다.

  • ConfigMap, Secret, Volume은 Spring 설정 주입에서 각각 무엇을 담당하는가?
  • 설정 변경이 기존 Pod에 바로 반영되지 않을 때 무엇을 확인해야 하는가?
  • Secret을 안전하게 운영하려면 어떤 절차가 필요한가?

개요

Kubernetes에서 애플리케이션 설정은 이미지 안에 고정하지 않고 외부 리소스로 주입하는 경우가 많다.

ConfigMap은 일반 설정을 담는다.

Secret은 비밀번호, token, key 같은 민감 정보를 담는다.

Volume은 파일 형태로 값을 mount하거나 저장소를 연결할 때 쓴다.

Spring 백엔드에서는 profile, datasource URL, 외부 API endpoint, log level, 인증 정보가 이 리소스들과 연결된다.

설정 주입 방식이 불명확하면 같은 image가 환경마다 다르게 동작하고, 장애 중 어떤 값으로 실행 중인지 알기 어렵다.

ConfigMap

ConfigMap은 민감하지 않은 설정을 담는다.

예시는 다음과 같다.

apiVersion: v1
kind: ConfigMap
metadata:
  name: order-api-config
data:
  SPRING_PROFILES_ACTIVE: prod
  PAYMENT_API_BASE_URL: https://payment.example.com
  LOG_LEVEL: INFO

ConfigMap은 환경별 설정을 image와 분리하는 데 유용하다.

하지만 ConfigMap 값을 바꿨다고 모든 Pod가 자동으로 새 값을 쓰는 것은 아니다.

환경 변수로 주입한 값은 Pod가 다시 시작되어야 반영된다.

파일 mount는 kubelet 갱신 주기와 mount 방식에 따라 반영 시점이 달라질 수 있다.

Secret

Secret은 민감 정보를 위한 리소스다.

하지만 기본 Secret은 이름만으로 완전한 보안을 제공하지 않는다.

RBAC, 암호화 설정, 접근 로그, 회전 절차가 함께 있어야 한다.

apiVersion: v1
kind: Secret
metadata:
  name: order-api-secret
type: Opaque
stringData:
  DB_USERNAME: app
  DB_PASSWORD: replace-in-real-env

운영에서는 Secret 값을 manifest나 Git history에 남기지 않는 방식이 필요하다.

외부 Secret Manager, sealed secret, SOPS 같은 도구를 검토할 수 있지만 핵심은 누가 언제 어떤 값을 바꿨는지 추적 가능해야 한다는 점이다.

주입 방식

Deployment에서는 env, envFrom, volumeMount를 쓸 수 있다.

containers:
  - name: api
    image: registry.example.com/order-api:2026.07.01
    envFrom:
      - configMapRef:
          name: order-api-config
      - secretRef:
          name: order-api-secret
    volumeMounts:
      - name: app-config
        mountPath: /config
volumes:
  - name: app-config
    configMap:
      name: order-api-config

envFrom은 편하지만 어떤 key가 들어가는지 manifest만 보고 알기 어렵다.

명시적인 env는 길어지지만 중요한 값의 출처가 분명하다.

파일 mount는 인증서, 복잡한 YAML, 외부 agent 설정처럼 파일이 필요한 경우에 적합하다.

Spring 관점

Spring Boot는 환경 변수, system property, application.yml 등 여러 설정 우선순위를 가진다.

Kubernetes 설정을 설계할 때는 다음을 확인한다.

  • SPRING_PROFILES_ACTIVE가 환경별로 명확한가?
  • DB URL, username, password가 같은 출처에서 관리되는가?
  • log level 변경이 재시작 없이 필요한가?
  • 외부 API endpoint와 timeout이 환경마다 다른가?
  • 설정 파일 mount가 기본 application.yml을 의도치 않게 덮지 않는가?
  • Secret 회전 후 connection pool이 새 credential로 재연결되는가?

설정 주입은 애플리케이션 코드와 운영 manifest 사이의 계약이다.

장애 신호

  • 새 ConfigMap을 적용했지만 기존 Pod가 예전 값을 사용한다.
  • Secret 회전 후 일부 Pod만 DB 인증에 실패한다.
  • namespace별 ConfigMap 값이 달라 같은 image가 다르게 동작한다.
  • env key 오타로 Spring이 기본값을 사용한다.
  • volume mount가 기존 설정 디렉터리를 덮어써 애플리케이션이 시작하지 못한다.
  • kubectl describe 공유본에 Secret 값이나 민감 경로가 노출된다.
  • 설정 변경과 애플리케이션 배포 이력이 따로 남아 원인 추적이 어렵다.

이 신호는 설정 주입과 rollout 절차가 함께 관리되지 않는다는 뜻이다.

안전한 완화 조치

  • 설정 변경 장애가 의심되면 어떤 Pod가 어떤 ConfigMap/Secret revision을 쓰는지 확인한다.
  • 환경 변수 주입 값은 rollout restart로 새 Pod에 반영한다.
  • Secret 회전은 새 Secret 생성, rollout, 연결 확인, 이전 Secret 제거 순서로 진행한다.
  • 오타가 의심되면 Spring effective configuration과 로그를 확인한다.
  • 민감 정보가 노출되면 token 폐기와 Secret 회전을 먼저 수행한다.
  • 급한 완화라도 Secret 값을 공개 채널에 붙여 넣지 않는다.

하지 말아야 할 대응

  • Secret 값을 평문 YAML로 Git에 저장하지 않는다.
  • ConfigMap을 Secret 대용으로 쓰지 않는다.
  • 값 변경 후 Pod 재시작 필요 여부를 확인하지 않고 정상 반영됐다고 판단하지 않는다.
  • kubectl exec env 결과를 그대로 공유 채널에 올리지 않는다.
  • subPath mount의 업데이트 반영 한계를 모른 채 동적 설정으로 사용하지 않는다.

인프라 담당자와 공유할 자료

  • namespace, Deployment, ConfigMap, Secret 이름
  • 변경한 key와 변경 시각
  • 주입 방식: env, envFrom, volumeMount
  • 현재 Pod 재시작 여부와 rollout 상태
  • Secret 회전 절차와 이전 Secret 폐기 계획
  • 설정 변경 후 발생한 오류 로그와 영향 기능

공유 자료는 값 자체보다 출처, 반영 방식, 반영 시각을 중심으로 작성한다.

운영 체크리스트

  • 일반 설정과 민감 정보가 분리되어 있는가?
  • ConfigMap/Secret 변경과 Deployment rollout이 연결되어 있는가?
  • Secret 접근 권한이 최소화되어 있는가?
  • Secret 회전 절차와 검증 API가 있는가?
  • 파일 mount가 기존 설정 파일을 덮지 않는가?
  • 설정 변경 이력이 배포 이력과 함께 추적되는가?

확인 질문

확인 질문

  • ConfigMap 변경이 기존 Pod에 바로 반영되지 않을 수 있는 이유는 무엇인가?
    • 환경 변수로 주입된 값은 Pod 시작 시 결정되고, 파일 mount도 방식에 따라 반영 시점이 다르기 때문이다.
  • Secret이 안전하려면 Secret 리소스 외에 무엇이 필요한가?
    • RBAC, 저장 시 암호화, 회전 절차, 접근 기록, 출력 공유 통제가 필요하다.
  • Spring 설정 장애에서 확인할 핵심은 무엇인가?
    • 어떤 key가 어떤 리소스에서 어떤 방식으로 주입되어 현재 Pod에 반영됐는지다.

리뷰 체크포인트

  • ConfigMap, Secret, Volume의 용도가 분리되어 있는가?
  • env와 volumeMount의 반영 시점 차이가 설명되어 있는가?
  • Secret 회전과 권한 통제가 문서화되어 있는가?
  • Spring 설정 우선순위와 연결되어 있는가?
  • 설정 변경 후 rollout과 검증 절차가 있는가?

관련 문서

백링크