설명
Kubernetes 기본 Secret은 적절한 접근 통제와 저장 암호화 아래 사용할 수 있습니다. 여러 애플리케이션과 클러스터에서 자격 증명을 운영하면 교체, 만료, 감사와 중앙 관리가 복잡해져 외부 비밀정보 저장소 연동이 유용할 수 있습니다. 기본 Secret 사용 자체가 취약점인 것은 아닙니다.
외부 저장소도 자격 증명 전달과 접근 권한을 구성해야 합니다. KMS를 통한 저장 암호화는 비밀정보 수명주기 관리와 다른 기능이며, Secret을 외부 값과 동기화하면 Kubernetes에도 사본이 남을 수 있습니다.
잠재적 영향
- 수동 교체와 만료 관리로 오래된 자격 증명이 남을 수 있습니다.
- 과도한 Secret 접근 권한이나 매니페스트에 기록된 실제 값이 비밀정보 노출로 이어질 수 있습니다.
해결 방법
- 규모와 감사·교체 요구에 맞춰 기본 Secret이나 Vault, 클라우드 비밀정보 저장소 및 Secrets Store CSI Driver 같은 연동 방식을 선택하세요. KMS 암호화만으로 비밀정보 저장소의 기능이 대체되지는 않습니다.
- 어떤 방식을 쓰든 최소 권한, 저장 암호화와 감사 설정을 적용하고 실제 비밀정보를 저장소에 커밋하지 마세요. 비밀정보 교체 후 파일·환경 변수·애플리케이션에 반영되는 방식과 필요한 재시작을 확인하세요.
예시
변경 전 값은 비운영용 예시입니다. 변경 후 SecretProviderClass는 Azure Key Vault 연동의 일부로, CSI Driver와 Azure 공급자, 사용할 ID와 Key Vault 권한, Pod의 CSI 볼륨 마운트를 별도로 구성해야 합니다. 자리표시자는 실제 환경 값으로 바꾸세요.
변경 전
yaml
apiVersion: v1
kind: Secret
metadata:
name: app-secret
stringData:
password: "my-password"
apiToken: "my-token"
매니페스트에 비밀정보 값을 직접 적습니다. 실제 값을 커밋하면 노출될 수 있으며, Secret의 base64 표현은 암호화가 아닙니다.
변경 후
yaml
apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
name: app-secrets
spec:
provider: azure
parameters:
keyvaultName: "<key-vault-name>"
tenantId: "<tenant-id>"
objects: |
array:
- |
objectName: app-password
objectType: secret
외부 app-password 값을 선택합니다. 이 리소스만으로 Pod에 마운트되거나 기존 Secret이 제거되는 것은 아닙니다.