Kubernetes Secret 운영 가이드 - 환경변수 관리부터 외부 시크릿 연동까지

왜 Secret 운영이 어려운가

쿠버네티스 자체는 Secret 리소스를 제공하지만, 실제 문제는 “어디에 저장하고 어떻게 배포하며 누가 접근할 수 있느냐”에 있습니다.

많이 발생하는 문제:

Git에 평문 시크릿 커밋
ConfigMap과 Secret 구분 없이 사용
시크릿 변경 시 재배포 누락
운영/개발 환경 시크릿 혼용
회전 정책 부재

시크릿은 단순 YAML이 아니라 운영 프로세스의 일부입니다.

ConfigMap과 Secret 차이

둘 다 설정을 주입하는 용도로 보이지만 의미가 다릅니다.

ConfigMap:

공개 가능한 설정
환경값, 플래그, 일반 설정

Secret:

민감한 정보
DB 비밀번호
API 키
토큰
인증서

Secret도 기본적으로 base64 인코딩일 뿐 암호화 그 자체는 아닙니다. etcd 암호화와 접근 제어까지 함께 봐야 합니다.

Secret을 주입하는 방식

대표 방식은 세 가지입니다.

1. 환경변수 주입

가장 흔하지만, 프로세스 환경에 노출됩니다.

env:
  - name: DATABASE_PASSWORD
    valueFrom:
      secretKeyRef:
        name: app-secret
        key: db-password

2. 파일 마운트

인증서, 키 파일, 설정 파일 형태에는 더 적합합니다.

volumes:
  - name: secret-volume
    secret:
      secretName: tls-secret

3. CSI / External Secret 방식

외부 Secret Store에서 동적으로 가져옵니다.

운영 환경에서는 이 방식이 가장 관리성이 좋습니다.

Git에 Secret을 어떻게 둘까

가장 중요한 원칙은 평문 비밀값을 Git에 직접 저장하지 않는 것입니다.

대안:

Sealed Secrets
SOPS
External Secrets Operator
HashiCorp Vault
AWS Secrets Manager / Parameter Store

초기 팀에서는 SOPS나 Sealed Secrets가 진입장벽이 낮고, 클라우드 네이티브 운영에서는 External Secrets 조합이 많이 쓰입니다.

External Secrets Operator 예시

AWS Secrets Manager를 쓴다면 다음 패턴이 일반적입니다.

apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: app-secret
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: aws-secretsmanager
    kind: ClusterSecretStore
  target:
    name: app-secret
  data:
    - secretKey: db-password
      remoteRef:
        key: prod/app/database
        property: password

장점:

클러스터 안에 평문 저장 최소화
회전 자동 반영 가능
GitOps와 결합 쉬움

Secret 회전은 어떻게 할까

많은 팀이 생성만 하고 회전을 하지 않습니다.

회전이 필요한 대표 항목:

DB 계정
외부 API 키
OAuth client secret
TLS 인증서
내부 서비스 토큰

회전 시 고려할 것:

애플리케이션 재시작 필요 여부
connection pool 갱신 방법
롤링 업데이트 전략
구버전/신버전 동시 허용 시간

접근 제어는 RBAC와 함께 봐야 한다

Secret 리소스를 아무나 읽을 수 있으면 운영상 큰 리스크가 됩니다.

최소한 아래는 지켜야 합니다.

namespace 단위 분리
서비스 계정 권한 최소화
운영자 읽기 권한 제한
CI/CD Role의 Secret 수정 범위 제한

특히 get secrets 권한은 생각보다 민감합니다.

etcd 암호화도 확인하자

Secret이 클러스터에 저장될 때 etcd에 평문에 가까운 형태로 남아 있으면 위험합니다.

운영 클러스터라면 다음 항목을 점검하는 편이 좋습니다.

Kubernetes encryption at rest 활성화
etcd 접근 통제
백업 파일 보호

시크릿 보안은 API 서버 바깥까지 이어집니다.

운영 중 자주 겪는 문제

1. Secret 변경 후 파드에 반영되지 않음

환경변수 기반 주입은 보통 재시작이 필요합니다.

2. 여러 앱이 하나의 Secret을 공유함

편해 보여도 영향 범위가 커집니다. 앱 단위 또는 도메인 단위로 분리하는 편이 안전합니다.

3. 개발/운영 시크릿 이름이 같음

실수로 잘못된 환경 값이 들어갈 수 있습니다.

4. 누가 값을 바꿨는지 추적 안 됨

감사 로그와 GitOps 흐름이 필요합니다.

마무리

Kubernetes Secret 운영의 핵심은 “어떻게 주입할까”보다 “누가 어디서 관리하고 어떻게 회전할까”입니다.

잘 설계된 Secret 체계는 다음을 만족합니다.

Git에 평문 비밀이 없음
앱별/환경별 경계가 분명함
자동 동기화와 회전이 가능함
접근 권한이 최소화되어 있음

초기부터 이 기준으로 운영하면 나중에 보안 사고와 운영 실수를 크게 줄일 수 있습니다.