ConfigMap과 Secret 완벽 가이드

쿠버네티스에서 애플리케이션 설정과 민감 정보를 관리하는 ConfigMap과 Secret의 모든 것을 다룹니다. 생성부터 활용, 보안 베스트 프랙티스까지 실무에서 바로 적용할 수 있는 내용을 담았습니다.

---

목차

1. ConfigMap_생성_방법
2. ConfigMap을_환경변수로_주입
3. ConfigMap을_볼륨으로_마운트
4. Secret_생성_및_관리
5. Secret_타입별_용도
6. 민감_정보_관리_베스트_프랙티스

---

1. ConfigMap 생성 방법

김개발 씨는 쿠버네티스를 처음 배우는 신입 개발자입니다. 어느 날 선배가 "이 애플리케이션 설정값들을 ConfigMap으로 분리해 놔"라고 지시했습니다.

ConfigMap이라니, 대체 그게 뭘까요?

ConfigMap은 쿠버네티스에서 설정 데이터를 키-값 쌍으로 저장하는 오브젝트입니다. 마치 애플리케이션의 설정 파일을 외부로 빼내어 별도로 관리하는 서랍장과 같습니다.

이를 통해 컨테이너 이미지를 다시 빌드하지 않고도 설정을 변경할 수 있습니다.

다음 코드를 살펴봅시다.

# configmap-basic.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
  namespace: default
data:
  # 단순 키-값 형태
  DATABASE_HOST: "mysql.database.svc.cluster.local"
  DATABASE_PORT: "3306"
  LOG_LEVEL: "info"
  # 파일 형태의 설정
  app.properties: |
    server.port=8080
    server.timeout=30
    cache.enabled=true

김개발 씨는 입사한 지 2주 된 신입 개발자입니다. 오늘 첫 번째 쿠버네티스 프로젝트를 맡았는데, 선배 박시니어 씨가 다가와 말했습니다.

"설정값들을 코드에 하드코딩하면 안 돼. ConfigMap으로 분리해야 해." ConfigMap이라니, 처음 듣는 용어에 김개발 씨는 고개를 갸웃거렸습니다.

그렇다면 ConfigMap이란 정확히 무엇일까요? 쉽게 비유하자면, ConfigMap은 마치 사무실의 공용 서랍장과 같습니다.

여러 사람이 필요한 문서나 물품을 서랍장에 넣어두면, 누구든 필요할 때 꺼내 쓸 수 있습니다. 서랍장의 내용물을 바꿔도 사람들이 일하는 방식을 바꿀 필요가 없는 것처럼, ConfigMap의 설정을 바꿔도 애플리케이션 코드를 수정할 필요가 없습니다.

ConfigMap이 없던 시절에는 어땠을까요? 개발자들은 설정값을 코드에 직접 넣거나, 컨테이너 이미지를 빌드할 때 설정 파일을 함께 포함시켜야 했습니다.

데이터베이스 주소가 바뀌면? 코드를 수정하고, 다시 빌드하고, 배포해야 했습니다.

개발 환경과 운영 환경의 설정이 다르면? 환경별로 다른 이미지를 만들어야 했습니다.

바로 이런 문제를 해결하기 위해 ConfigMap이 등장했습니다. ConfigMap을 사용하면 설정과 코드를 완전히 분리할 수 있습니다.

같은 컨테이너 이미지를 개발, 스테이징, 운영 환경에서 그대로 사용하면서 환경별로 다른 ConfigMap만 연결하면 됩니다. 설정 변경이 필요할 때도 ConfigMap만 수정하면 끝입니다.

위의 코드를 살펴보겠습니다. 먼저 apiVersion과 kind는 이것이 ConfigMap이라는 것을 선언합니다.

metadata 섹션에서는 이름과 네임스페이스를 지정합니다. 핵심은 data 섹션입니다.

여기에 키-값 쌍으로 설정을 저장합니다. 단순한 값은 DATABASE_HOST처럼 직접 적으면 됩니다.

여러 줄의 설정 파일이 필요하다면 app.properties처럼 파이프 기호를 사용해 멀티라인 문자열로 저장할 수 있습니다. 실제 현업에서는 어떻게 활용할까요?

예를 들어 마이크로서비스 아키텍처에서 여러 서비스가 공통 설정을 공유해야 할 때 ConfigMap을 활용합니다. 메시지 큐 주소, 캐시 서버 정보, 로깅 레벨 같은 것들을 ConfigMap에 저장해 두면 모든 서비스가 일관된 설정을 사용할 수 있습니다.

하지만 주의할 점도 있습니다. ConfigMap은 비밀번호나 API 키 같은 민감한 정보를 저장하면 안 됩니다.

ConfigMap의 내용은 암호화되지 않은 상태로 저장되기 때문입니다. 민감한 정보는 반드시 Secret을 사용해야 합니다.

다시 김개발 씨의 이야기로 돌아가 봅시다. 박시니어 씨의 설명을 들은 김개발 씨는 이제 ConfigMap이 왜 필요한지 이해했습니다.

"아, 설정을 외부로 분리해서 유연하게 관리하는 거군요!"

실전 팁

💡 - kubectl create configmap 명령어로 파일이나 디렉토리에서 직접 ConfigMap을 생성할 수 있습니다

• ConfigMap의 크기는 1MB로 제한되므로 대용량 설정은 다른 방법을 고려하세요

---

2. ConfigMap을 환경변수로 주입

김개발 씨는 ConfigMap을 만들었습니다. 그런데 이걸 어떻게 애플리케이션에서 사용하지?

선배는 "환경변수로 주입하면 돼"라고 했지만, 구체적인 방법이 궁금해졌습니다.

ConfigMap의 값을 컨테이너의 환경변수로 주입하면 애플리케이션이 process.env나 os.environ 같은 방식으로 설정을 읽을 수 있습니다. 마치 운영체제에 설정된 환경변수처럼 자연스럽게 사용할 수 있어서 가장 널리 쓰이는 방법입니다.

다음 코드를 살펴봅시다.

# deployment-with-env.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  template:
    spec:
      containers:
      - name: app
        image: my-app:1.0
        env:
        # 개별 키 선택적 주입
        - name: DB_HOST
          valueFrom:
            configMapKeyRef:
              name: app-config
              key: DATABASE_HOST
        # 모든 키를 한번에 주입
        envFrom:
        - configMapRef:
            name: app-config

ConfigMap을 만든 김개발 씨는 이제 다음 단계로 넘어갔습니다. 애플리케이션에서 이 설정값들을 어떻게 읽어올 수 있을까요?

박시니어 씨가 설명을 이어갔습니다. "환경변수로 주입하는 게 가장 간단해.

코드에서 그냥 환경변수 읽듯이 쓰면 돼." 환경변수 주입이란 무엇일까요? 마치 호텔 체크인을 생각해 보세요.

프론트에서 방 번호, 와이파이 비밀번호, 조식 시간 같은 정보를 적은 카드를 줍니다. 투숙객은 이 카드만 보면 필요한 정보를 바로 알 수 있습니다.

ConfigMap을 환경변수로 주입하는 것도 마찬가지입니다. 컨테이너가 시작될 때 필요한 설정 정보를 환경변수라는 카드에 담아 전달하는 것입니다.

환경변수 방식이 좋은 이유가 있습니다. 대부분의 프로그래밍 언어와 프레임워크가 환경변수를 읽는 방법을 기본으로 제공합니다.

Node.js에서는 process.env.DATABASE_HOST, Python에서는 os.environ.get('DATABASE_HOST')처럼요. 코드를 수정할 필요 없이 쿠버네티스 설정만 바꾸면 됩니다.

위의 코드에서 두 가지 방법을 볼 수 있습니다. 첫 번째는 env와 valueFrom을 사용하는 방법입니다.

configMapKeyRef를 통해 특정 ConfigMap의 특정 키만 선택적으로 주입합니다. 이 방식은 환경변수 이름을 원하는 대로 바꿀 수 있다는 장점이 있습니다.

DATABASE_HOST를 DB_HOST로 바꿔서 주입한 것처럼요. 두 번째는 envFrom을 사용하는 방법입니다.

configMapRef로 ConfigMap 전체를 한 번에 주입합니다. ConfigMap의 모든 키가 그대로 환경변수가 됩니다.

설정이 많을 때 편리합니다. 실무에서는 어떤 방식을 선택할까요?

설정이 몇 개 안 되고 이름을 직접 제어하고 싶다면 valueFrom을 사용합니다. 설정이 많고 ConfigMap과 환경변수 이름을 동일하게 유지해도 된다면 envFrom이 편합니다.

두 방식을 섞어 쓰는 것도 가능합니다. 주의할 점이 있습니다.

환경변수로 주입된 값은 컨테이너가 시작될 때 한 번만 읽힙니다. ConfigMap을 수정해도 이미 실행 중인 컨테이너에는 반영되지 않습니다.

변경 사항을 적용하려면 Pod를 다시 시작해야 합니다. 동적으로 설정을 변경해야 한다면 볼륨 마운트 방식을 고려해야 합니다.

김개발 씨는 자신의 Node.js 애플리케이션에서 process.env.DATABASE_HOST로 설정을 읽을 수 있게 되었습니다. 코드 한 줄 수정하지 않고도 쿠버네티스와 연동된 것입니다.

실전 팁

💡 - 환경변수 이름은 대문자와 언더스코어를 사용하는 것이 관례입니다

• 필수 설정이라면 optional: false를 명시해서 ConfigMap이 없을 때 Pod 시작을 막을 수 있습니다

---

3. ConfigMap을 볼륨으로 마운트

환경변수 방식을 익힌 김개발 씨에게 새로운 과제가 떨어졌습니다. nginx 설정 파일을 ConfigMap으로 관리해야 하는데, 이건 단순 키-값이 아니라 파일 전체를 넣어야 합니다.

어떻게 해야 할까요?

ConfigMap을 볼륨으로 마운트하면 설정 데이터가 컨테이너 내부의 파일로 나타납니다. 마치 USB 드라이브를 컴퓨터에 꽂으면 파일이 보이는 것처럼, ConfigMap의 각 키가 파일이 되어 지정한 경로에 마운트됩니다.

다음 코드를 살펴봅시다.

# deployment-with-volume.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-app
spec:
  template:
    spec:
      containers:
      - name: nginx
        image: nginx:1.21
        volumeMounts:
        - name: config-volume
          mountPath: /etc/nginx/conf.d
          readOnly: true
      volumes:
      - name: config-volume
        configMap:
          name: nginx-config
          items:
          - key: nginx.conf
            path: default.conf

김개발 씨는 nginx 웹 서버를 쿠버네티스에 배포하는 일을 맡았습니다. nginx는 설정 파일을 통해 동작을 제어하는데, 이 파일을 어떻게 관리해야 할까요?

박시니어 씨가 힌트를 줬습니다. "설정 파일 자체를 ConfigMap에 넣고, 볼륨으로 마운트하면 돼." 볼륨 마운트란 무엇일까요?

도서관에서 책을 빌린다고 생각해 보세요. 책을 가져와서 책상 위에 올려놓으면 언제든 펼쳐볼 수 있습니다.

볼륨 마운트도 비슷합니다. ConfigMap이라는 책꽂이에서 설정 파일을 가져와서 컨테이너의 특정 폴더에 올려놓는 것입니다.

컨테이너는 그 경로에서 파일을 읽기만 하면 됩니다. 환경변수 방식과 무엇이 다를까요?

환경변수는 단순한 문자열 값에 적합합니다. 데이터베이스 주소, 포트 번호 같은 것들이요.

하지만 nginx.conf나 application.yaml처럼 복잡한 구조의 설정 파일 전체를 다뤄야 할 때는 볼륨 마운트가 필요합니다. 위의 코드를 단계별로 살펴보겠습니다.

volumes 섹션에서 ConfigMap을 볼륨으로 선언합니다. nginx-config라는 ConfigMap에서 nginx.conf 키의 내용을 default.conf라는 파일명으로 사용하겠다고 지정합니다.

volumeMounts 섹션에서 이 볼륨을 컨테이너의 어느 경로에 마운트할지 정합니다. /etc/nginx/conf.d 경로에 마운트하면 nginx가 자동으로 이 설정을 읽어갑니다.

볼륨 마운트의 큰 장점이 있습니다. ConfigMap이 변경되면 마운트된 파일도 자동으로 업데이트됩니다.

환경변수와 달리 Pod를 재시작하지 않아도 됩니다. 물론 애플리케이션이 파일 변경을 감지하고 다시 읽어야 하지만, nginx처럼 reload 명령을 지원하는 애플리케이션이라면 무중단으로 설정을 변경할 수 있습니다.

주의할 점도 있습니다. subPath를 사용하면 자동 업데이트가 동작하지 않습니다.

또한 마운트된 경로의 기존 파일들이 숨겨질 수 있으니 주의해야 합니다. 특정 파일만 마운트하고 싶다면 items를 사용해 명시적으로 지정하는 것이 좋습니다.

김개발 씨는 nginx 설정 파일을 ConfigMap으로 관리하면서 버전 관리와 배포가 훨씬 깔끔해졌다고 느꼈습니다. Git으로 ConfigMap YAML 파일을 관리하면 설정 변경 이력까지 추적할 수 있으니까요.

실전 팁

💡 - readOnly: true를 설정하면 컨테이너가 실수로 설정 파일을 수정하는 것을 방지할 수 있습니다

• defaultMode로 파일 권한을 지정할 수 있습니다 (예: 0644)

---

4. Secret 생성 및 관리

김개발 씨가 데이터베이스 연결 설정을 ConfigMap에 넣으려고 했더니 박시니어 씨가 급히 말렸습니다. "잠깐, 비밀번호는 ConfigMap에 넣으면 안 돼!

Secret을 써야 해." 그렇다면 Secret은 무엇이 다른 걸까요?

Secret은 비밀번호, API 키, 인증서 같은 민감한 정보를 저장하기 위한 쿠버네티스 오브젝트입니다. ConfigMap과 비슷하지만, 데이터가 Base64로 인코딩되어 저장되고 접근 권한을 더 엄격하게 관리할 수 있습니다.

다음 코드를 살펴봅시다.

# secret-basic.yaml
apiVersion: v1
kind: Secret
metadata:
  name: db-credentials
type: Opaque
data:
  # Base64 인코딩된 값
  # echo -n 'admin' | base64 -> YWRtaW4=
  username: YWRtaW4=
  password: cXdlcjEyMzQ=
---
# stringData를 사용하면 평문으로 작성 가능
apiVersion: v1
kind: Secret
metadata:
  name: api-keys
type: Opaque
stringData:
  api-key: "my-super-secret-api-key"
  webhook-secret: "webhook-secret-value"

김개발 씨는 깜짝 놀랐습니다. ConfigMap에 데이터베이스 비밀번호를 넣으려던 참이었거든요.

박시니어 씨가 막지 않았다면 보안 사고로 이어질 뻔했습니다. "ConfigMap은 암호화되지 않아.

누구든 kubectl get configmap으로 내용을 볼 수 있거든." 박시니어 씨의 설명이 이어졌습니다. Secret이란 정확히 무엇일까요?

마치 은행의 금고와 일반 서랍장의 차이라고 생각하면 됩니다. 일반 서류는 서랍장에 넣어도 되지만, 인감도장이나 중요 계약서는 금고에 보관해야 합니다.

ConfigMap이 서랍장이라면 Secret은 금고입니다. 둘 다 물건을 보관하지만 보안 수준이 다릅니다.

Secret이 ConfigMap보다 안전한 이유가 있습니다. 첫째, Secret의 데이터는 etcd에 저장될 때 암호화될 수 있습니다.

클러스터 설정에 따라 다르지만, 많은 환경에서 at-rest encryption을 활성화합니다. 둘째, RBAC을 통해 접근을 제한할 수 있습니다.

특정 사용자나 서비스 계정만 Secret을 읽을 수 있도록 설정할 수 있습니다. 위의 코드를 살펴보겠습니다.

data 필드를 사용할 때는 값을 Base64로 인코딩해야 합니다. echo -n 'admin' | base64 명령으로 변환할 수 있습니다.

주의할 점은 Base64는 암호화가 아니라는 것입니다. 단지 바이너리 데이터를 텍스트로 표현하기 위한 인코딩일 뿐입니다.

stringData 필드를 사용하면 평문으로 작성할 수 있습니다. 쿠버네티스가 자동으로 Base64로 변환해서 저장합니다.

작성은 편하지만, YAML 파일에 평문 비밀번호가 남는다는 점을 주의해야 합니다. 실무에서는 어떻게 관리할까요?

Secret YAML 파일을 Git에 직접 커밋하는 것은 매우 위험합니다. 대신 Sealed Secrets, External Secrets, Vault 같은 도구를 사용해 안전하게 관리합니다.

이 도구들은 암호화된 형태로 Secret을 저장하거나 외부 비밀 관리 시스템과 연동합니다. Secret을 Pod에서 사용하는 방법은 ConfigMap과 동일합니다.

환경변수로 주입하거나 볼륨으로 마운트할 수 있습니다. 다만 메모리에만 저장되는 tmpfs로 마운트되어 디스크에 기록되지 않는다는 차이가 있습니다.

김개발 씨는 데이터베이스 비밀번호를 Secret으로 안전하게 저장했습니다. "보안은 처음부터 신경 써야 하는 거구나"라고 되새기면서요.

실전 팁

💡 - kubectl create secret generic 명령으로 파일이나 리터럴 값에서 직접 Secret을 생성할 수 있습니다

• Secret은 네임스페이스에 종속되므로 다른 네임스페이스의 Pod에서 접근할 수 없습니다

---

5. Secret 타입별 용도

김개발 씨는 Secret을 만들면서 type: Opaque라는 부분이 눈에 띄었습니다. Opaque가 뭐지?

다른 타입도 있나? 문득 궁금해진 김개발 씨는 쿠버네티스 공식 문서를 찾아보기로 했습니다.

쿠버네티스 Secret은 여러 가지 타입을 제공합니다. 용도에 맞는 타입을 사용하면 데이터 구조가 검증되고, 쿠버네티스의 자동화 기능과 연동됩니다.

Opaque는 범용 타입이고, 그 외에 Docker 인증, TLS 인증서, 서비스 계정 토큰 등 특수 목적의 타입이 있습니다.

다음 코드를 살펴봅시다.

# Docker 레지스트리 인증 Secret
apiVersion: v1
kind: Secret
metadata:
  name: docker-registry-cred
type: kubernetes.io/dockerconfigjson
data:
  .dockerconfigjson: eyJhdXRocyI6ey...base64인코딩...
---
# TLS 인증서 Secret
apiVersion: v1
kind: Secret
metadata:
  name: tls-secret
type: kubernetes.io/tls
data:
  tls.crt: LS0tLS1CRUdJTi...base64인코딩...
  tls.key: LS0tLS1CRUdJTi...base64인코딩...
---
# 기본 인증 Secret
apiVersion: v1
kind: Secret
metadata:
  name: basic-auth
type: kubernetes.io/basic-auth
stringData:
  username: admin
  password: secretpassword

김개발 씨가 문서를 찾아보니 Secret 타입이 생각보다 많았습니다. 왜 이렇게 종류가 다양할까요?

박시니어 씨가 설명해 줬습니다. "타입별로 용도가 다르거든.

적절한 타입을 쓰면 쿠버네티스가 알아서 검증도 해주고, 자동으로 연동도 해줘." 주요 Secret 타입들을 하나씩 살펴보겠습니다. Opaque는 가장 기본적인 타입입니다.

별다른 제약 없이 어떤 키-값 쌍이든 저장할 수 있습니다. 데이터베이스 비밀번호, API 키 같은 일반적인 민감 정보에 사용합니다.

타입을 지정하지 않으면 기본값으로 Opaque가 됩니다. kubernetes.io/dockerconfigjson은 Docker 레지스트리 인증 정보를 저장합니다.

프라이빗 레지스트리에서 이미지를 가져올 때 필요합니다. Pod의 imagePullSecrets에 이 Secret을 지정하면 쿠버네티스가 자동으로 인증을 처리합니다.

kubernetes.io/tls는 TLS 인증서와 개인 키를 저장합니다. Ingress에서 HTTPS를 설정할 때 주로 사용합니다.

이 타입을 사용하면 tls.crt와 tls.key 키가 반드시 있어야 하고, 쿠버네티스가 형식을 검증합니다. kubernetes.io/basic-auth는 사용자 이름과 비밀번호를 저장합니다.

Git 저장소 인증이나 기본 HTTP 인증에 사용됩니다. username과 password 키를 요구합니다.

kubernetes.io/ssh-auth는 SSH 개인 키를 저장합니다. Git 저장소에 SSH로 접근할 때 사용합니다.

ssh-privatekey 키가 필요합니다. kubernetes.io/service-account-token은 서비스 계정 토큰을 저장합니다.

이 타입은 직접 만들기보다 쿠버네티스가 자동으로 생성합니다. Pod가 쿠버네티스 API와 통신할 때 사용하는 인증 정보가 담깁니다.

실무에서는 왜 올바른 타입을 선택해야 할까요? 첫째, 데이터 검증이 됩니다.

TLS 타입에 tls.crt가 없으면 생성 자체가 실패합니다. 실수를 미리 잡을 수 있습니다.

둘째, 자동 연동이 됩니다. dockerconfigjson 타입은 imagePullSecrets과 자연스럽게 연동됩니다.

셋째, 가독성이 좋아집니다. Secret 목록을 볼 때 타입만 봐도 용도를 알 수 있습니다.

김개발 씨는 이제 상황에 맞는 Secret 타입을 선택할 수 있게 되었습니다. "아무거나 Opaque로 만들 게 아니라, 용도에 맞게 골라야겠구나."

실전 팁

💡 - kubectl create secret 명령에 --type 옵션으로 타입을 지정할 수 있습니다

• kubectl create secret docker-registry, kubectl create secret tls 같은 편의 명령도 제공됩니다

---

6. 민감 정보 관리 베스트 프랙티스

어느 날 회사에서 보안 감사가 진행되었습니다. 감사관이 김개발 씨에게 물었습니다.

"Secret 관리는 어떻게 하고 계세요?" 김개발 씨는 당황했습니다. 그냥 YAML 파일로 만들어서 적용하고 있었거든요.

과연 이게 최선의 방법일까요?

쿠버네티스 Secret만으로는 완벽한 보안을 제공하지 않습니다. 베스트 프랙티스를 따라야 진정한 보안을 달성할 수 있습니다.

RBAC 권한 설정, etcd 암호화, 외부 시크릿 관리 도구 활용, Git에 평문 저장 금지 등이 핵심입니다.

다음 코드를 살펴봅시다.

# RBAC으로 Secret 접근 제한
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: secret-reader
  namespace: production
rules:
- apiGroups: [""]
  resources: ["secrets"]
  resourceNames: ["app-secrets"]  # 특정 Secret만 허용
  verbs: ["get"]
---
# External Secrets Operator 예시
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: app-secrets
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: aws-secrets-manager
    kind: SecretStore
  target:
    name: app-secrets
  data:
  - secretKey: db-password
    remoteRef:
      key: production/database
      property: password

보안 감사에서 지적을 받은 김개발 씨는 박시니어 씨와 함께 Secret 관리 방식을 전면 검토하기로 했습니다. "쿠버네티스 Secret은 기본적인 보호만 제공해.

제대로 된 보안을 위해서는 추가적인 조치가 필요하지." 박시니어 씨의 말이 이어졌습니다. 첫 번째 원칙: RBAC으로 접근을 제한하세요. 기본적으로 클러스터 관리자는 모든 Secret을 볼 수 있습니다.

이건 위험합니다. 필요한 사람에게만, 필요한 Secret에만 접근 권한을 부여해야 합니다.

Role과 RoleBinding을 사용해 네임스페이스별로, 심지어 특정 Secret별로 접근을 제한할 수 있습니다. 두 번째 원칙: etcd 암호화를 활성화하세요. Secret은 etcd에 저장됩니다.

기본 설정에서는 Base64로만 인코딩되어 있어서 etcd에 직접 접근하면 내용을 볼 수 있습니다. EncryptionConfiguration을 설정해 etcd에 저장되는 데이터를 암호화해야 합니다.

관리형 쿠버네티스 서비스(EKS, GKE, AKS)는 대부분 이 기능을 제공합니다. 세 번째 원칙: Git에 평문 Secret을 저장하지 마세요. YAML 파일에 평문 비밀번호를 넣고 Git에 커밋하는 것은 최악의 실수입니다.

Git 히스토리에 영원히 남습니다. 대신 Sealed Secrets, SOPS, External Secrets Operator 같은 도구를 사용하세요.

Sealed Secrets는 암호화된 형태로 Secret을 Git에 저장합니다. 클러스터 내의 컨트롤러만 복호화할 수 있습니다.

External Secrets Operator는 AWS Secrets Manager, HashiCorp Vault, Azure Key Vault 같은 외부 비밀 관리 시스템과 연동합니다. 비밀번호는 외부 시스템에 저장하고, 쿠버네티스는 참조만 합니다.

네 번째 원칙: Secret을 환경변수보다 볼륨으로 마운트하세요. 환경변수는 프로세스 목록이나 로그에 노출될 위험이 있습니다. 볼륨으로 마운트하면 tmpfs에 저장되어 더 안전합니다.

또한 Secret이 변경되면 자동으로 업데이트됩니다. 다섯 번째 원칙: 정기적으로 Secret을 교체하세요. 비밀번호와 키는 정기적으로 교체해야 합니다.

자동화된 교체 메커니즘을 구축하세요. External Secrets Operator를 사용하면 refreshInterval로 자동 동기화할 수 있습니다.

여섯 번째 원칙: 감사 로깅을 활성화하세요. 누가 언제 어떤 Secret에 접근했는지 기록해야 합니다. 쿠버네티스 감사 로깅을 설정하면 모든 API 호출을 추적할 수 있습니다.

보안 감사 이후, 김개발 씨의 팀은 External Secrets Operator를 도입하고 RBAC 정책을 강화했습니다. 이제 Secret 관리에 대한 자신감이 생겼습니다.

실전 팁

💡 - kubeseal 명령으로 Sealed Secrets를 쉽게 생성할 수 있습니다

• 운영 환경에서는 반드시 etcd 암호화 상태를 확인하세요

---

이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!