Kubernetes 클러스터에서 비밀 및 민감한 데이터 관리 모범 사례

Kubernetes Secrets는 편리하지만, 객체 이름이 Secret이라고 해서 자동으로 안전한 것은 아닙니다. RBAC가 너무 광범위하거나 etcd가 암호화되지 않은 경우, 유출된 토큰은 클러스터 전체에 데이터베이스 비밀번호, API 키 및 개인 인증서를 노출할 수 있습니다.

Kubernetes Secrets를 하나의 계층으로 사용하고, 위험이 정당화되는 경우 암호화, 액세스 제어, 더 안전한 주입 패턴 및 외부 비밀 저장소를 추가하세요.

Kubernetes Secrets 이해: 기본 메커니즘

Kubernetes는 민감한 정보를 보유하도록 특별히 설계된 Secret 객체를 도입했습니다. 유용하지만, 보안과 관련된 한계와 기본 동작을 이해하는 것이 중요합니다.

기본 동작 및 주의 사항

기본적으로 Kubernetes Secrets는 모든 구성 데이터의 클러스터 백업 저장소인 etcd 내에서 저장 시 암호화되지 않습니다. 단지 Base64로 인코딩되어 실제 암호화를 제공하지 않습니다. etcd 데이터 저장소에 액세스할 수 있는 사람(예: 클러스터 관리자, 손상된 노드)은 이 값을 쉽게 디코딩할 수 있습니다.

경고: 암호화 조치를 적용하지 않고 고도로 민감한 데이터에 대해 기본 Kubernetes Secret 객체에만 의존하지 마십시오.

Base64 인코딩 대 암호화

Base64 인코딩이 보안을 제공한다는 것은 일반적인 오해입니다. Base64는 인코딩 방식이지 암호화 방식이 아닙니다. 쉽게 되돌릴 수 있습니다:

# Kubernetes Secret 값 디코딩 예시
echo 'c3VwZXItc2VjcmV0Cg==' | base64 -d
# 출력: super-secret

계층 1: 저장 시 Secrets 보호 (etcd 암호화)

Secrets를 보호하는 가장 기본적인 단계는 스토리지 계층(etcd)에서 암호화되도록 하는 것입니다. 이는 기본 데이터베이스에 직접 액세스하더라도 데이터를 보호합니다.

저장 시 암호화 활성화

저장 시 암호화는 EncryptionConfiguration 객체를 사용하여 Kubernetes API 서버를 통해 구성됩니다. 이 구성은 secrets를 포함하여 etcd에 저장된 다양한 유형의 데이터를 암호화하는 데 사용할 공급자를 지정합니다.

암호화 구성의 주요 구성 요소:

kind: EncryptionConfiguration: 리소스 유형을 선언합니다.
resources: 암호화해야 할 API 리소스를 지정합니다.
providers: 암호화 메커니즘을 정의합니다. 일반적인 공급자로는 aescbc, aesgcm 및 KMS 공급자(AWS KMS 또는 GCP KMS 등)가 있습니다.

모범 사례: 플랫폼에서 지원하는 경우 KMS 공급자를 사용하세요. 로컬 키를 사용하는 경우 키 순환을 신중하게 관리하고 기존 데이터가 다시 암호화될 때까지 이전 키를 보관하세요.

계층 2: 전송 중 및 사용 중인 Secrets 보호

etcd 암호화는 '저장 시' 문제를 해결하지만, Secrets는 Pod에 마운트될 때 Kubelet에 의해 여전히 해독됩니다. 이러한 비밀이 어떻게 그리고 어디에 나타나는지 제어해야 합니다.

전략 1: 볼륨 마운팅 Secrets

Secret 데이터를 컨테이너에 주입하는 표준 방법은 볼륨으로 마운트하는 것입니다(종종 컨테이너 파일 시스템에 파일이 생성됨).

apiVersion: v1
kind: Pod
metadata:
  name: secure-app
spec:
  containers:
  - name: my-container
    image: nginx
    volumeMounts:
    - name: secret-volume
      mountPath: "/etc/config/db"
      readOnly: true
  volumes:
  - name: secret-volume
    secret:
      secretName: my-sensitive-secret

보안 고려 사항: 마운트된 Secret 볼륨은 일반적으로 Linux 노드에서 tmpfs로 백업되지만, 값은 여전히 컨테이너 프로세스와 충분한 노드 또는 Pod 액세스 권한이 있는 사람에게 표시됩니다. readOnly: true를 사용하고, 환경 또는 구성 파일을 로그에 덤프하지 말고, 프로덕션 Pod에 대한 셸 액세스를 제한하세요.

전략 2: 환경 변수 (고감도에는 권장되지 않음)

편리하지만, Secrets에서 가져온 환경 변수를 사용하는 것은 일반적으로 고가치 비밀에 대해 권장되지 않습니다. 환경 변수는 다음을 통해 쉽게 유출될 수 있습니다:

잘못 구성된 애플리케이션에서 생성된 컨테이너 로그.
컨테이너 내부 또는 기타 권한 있는 컨테이너에서 /proc/1/environ 읽기.
컨테이너 검사 도구.

꼭 필요한 경우에만 낮은 민감도의 구성 데이터에 대해 환경 변수를 사용하세요.

계층 3: 외부 비밀 저장소를 사용한 고급 관리

가장 안전한 패턴은 민감한 데이터를 Kubernetes 제어 플레인(etcd) 외부에 완전히 유지하고 특수 도구를 사용하여 런타임에 동적으로 검색하는 것입니다.

외부 Secrets Operator 사용

외부 Secrets Operator는 전용 볼트(HashiCorp Vault, AWS Secrets Manager, Azure Key Vault 등)에 안전하게 저장된 비밀과 기본 Kubernetes Secret 객체 간의 격차를 해소합니다.

저장: 실제 비밀은 외부 볼트에만 존재합니다.
동기화/주입: Operator는 사용자 정의 리소스(예: ExternalSecret)를 감시하고 볼트에서 데이터를 가져옵니다.
생성: 그런 다음 Operator는 Pod에 마운트할 수 있는 표준 Kubernetes Secret 객체를 로컬로 생성합니다.

이점: 진실의 근원이 클러스터 외부에 유지되어 순환 및 감사 가능성이 향상됩니다. 그러나 동기화된 Kubernetes Secret은 여전히 클러스터에 존재하므로 RBAC, etcd 암호화 및 네임스페이스 격리가 여전히 필요합니다.

Secrets Store CSI 드라이버 사용

비밀을 etcd에 로컬로 저장하지 않고 직접 임시 액세스가 필요한 애플리케이션의 경우, Secrets Store CSI 드라이버가 우수한 선택입니다.

드라이버는 공급자(예: Vault 공급자, Azure 공급자)를 활용합니다.
외부 저장소에서 Pod의 파일 시스템으로 비밀을 임시 볼륨으로 직접 마운트하여 비밀 데이터를 etcd에 기록할 필요가 없습니다.

이는 etcd 데이터베이스에서 비밀을 완전히 제거하여 가장 높은 수준의 보안을 제공합니다.

비밀 관리를 위한 운영 모범 사례

기술적 저장 메커니즘 외에도 운영 위생은 안전한 태세를 유지하는 데 중요합니다.

1. 최소 권한 원칙(PoLP)

Pod와 연결된 서비스 계정이 필요한 특정 Secret만 읽을 수 있는 권한을 가지고 다른 Secret은 읽을 수 없도록 하세요. 역할 기반 액세스 제어(RBAC)를 사용하여 권한을 엄격하게 범위를 지정하세요.

2. 비밀을 자주 순환

모든 자격 증명에 대해 자동화된 순환 일정을 구현하세요. 수명이 긴 비밀은 손상 가능성을 높입니다. 외부 볼트와 통합된 도구는 종종 이 순환을 자동으로 처리합니다.

3. 액세스 감사 및 모니터링

누가 Secret 객체를 읽거나 수정하는지 추적하도록 감사 로깅을 구성하세요. 외부 볼트(예: Vault Agents 또는 CSI 드라이버)와 통합된 도구는 외부 저장소에 대한 액세스 시도도 기록해야 합니다.

4. Git에 비밀을 커밋하지 마세요

이것은 기본 규칙입니다. 개인 저장소라도 Git 저장소에 원시 또는 Base64 인코딩된 비밀을 저장하지 마세요. git-secrets와 같은 도구나 구성 관리 템플릿 도구(Helm 또는 Kustomize 등)를 외부 비밀 주입 메커니즘과 결합하여 배포 매니페스트를 관리하세요.

Kustomize 사용 예시 (외부 참조):

템플릿을 사용할 때 매니페스트 파일에 자리 표시자를 사용하고, YAML을 클러스터에 적용하기 전에 볼트에서 안전하게 검색된 실제 비밀 값을 주입하기 위해 빌드 단계 또는 CI/CD 파이프라인에 의존할 수 있습니다.

관리 전략 비교

전략	보안 수준	Etcd 노출?	복잡성	최적 대상
기본 K8s Secret (etcd 암호화 없음)	매우 낮음	예 (일반 텍스트)	낮음	임시 테스트 전용
etcd 암호화가 있는 K8s Secret	중간	예 (암호화됨)	중간	일반 구성 데이터
외부 Secrets Operator	높음	예 (Operator 관리 Secret)	높음	비밀 관리 표준화
Secrets Store CSI 드라이버	가장 높음	아니요 (직접 마운트)	높음	고도로 민감한 자격 증명 및 토큰

etcd 암호화를 활성화하고 RBAC를 강화하는 것부터 시작하세요. 그런 다음 각 워크로드가 동기화된 Secrets, 직접 CSI 마운트 또는 외부 볼트의 동적 자격 증명을 사용할 수 있는지 결정하세요. 가장 좋은 설정은 누가 비밀을 읽을 수 있는지, 어디에 저장되는지, 노출 후 얼마나 오래 유용한지 제한하는 설정입니다.