Kubernetes Secrets 모범 사례
Kubernetes Secrets 모범 사례 (Good practices for Kubernetes Secrets)
클러스터 관리자와 애플리케이션 개발자를 위한 좋은 Secret 관리 원칙과 관행이에요.
Kubernetes에서 Secret은 비밀번호, OAuth 토큰, SSH 키 같은 민감한 정보를 저장하는 객체예요. Secret은 민감한 정보가 사용되는 방식을 더 잘 제어하게 해주고 우발적 노출 위험을 줄여줘요. Secret 값은 base64 문자열로 인코딩되며 기본적으로 암호화 없이 저장되지만, 저장 시 암호화(encryption at rest)로 구성할 수 있어요.
Pod는 볼륨 마운트나 환경 변수 등 다양한 방식으로 Secret을 참조할 수 있어요. Secret은 기밀 데이터용, ConfigMaps은 비기밀 데이터용으로 설계됐어요.
클러스터 관리자
저장 시 암호화 구성
기본적으로 Secret 객체는 etcd에 암호화 없이 저장돼요. etcd에서 Secret 데이터 암호화를 구성하세요. 자세한 내용은 Encrypt Secret Data at Rest를 참고하세요.
Secrets에 대한 최소 권한 구성
RBAC 같은 접근 통제를 계획할 때 다음 지침을 고려하세요.
- 컴포넌트:
watch/list접근을 가장 권한 있는 시스템 수준 컴포넌트로만 제한하세요.get접근은 컴포넌트의 정상 동작이 요구하는 경우에만 부여하세요. - 사람: Secrets에 대한
get/watch/list접근을 제한하세요.etcd에는 클러스터 관리자만 접근을 허용하세요.
주의: Secrets에
list접근을 부여하면 그 주체가 Secrets의 내용을 가져올 수 있어요. Secret을 사용하는 Pod를 만들 수 있는 사용자는 그 Secret의 값을 볼 수도 있어요. 노출 영향은 짧은 수명의 Secret 사용, 특정 이벤트(예: 단일 사용자의 여러 Secret 동시 읽기)에 알리는 audit 규칙 같은 것으로 감지·제한할 수 있어요.
Secrets 접근 제한
마운트된 Secrets에 대한 접근을 격리하려면 별도의 네임스페이스를 사용하세요.
etcd 관리 정책 개선
더 이상 사용하지 않으면 etcd가 쓰는 영구 저장소를 지우거나 파쇄(wiping/shredding)하는 것을 고려하세요. 여러 etcd 인스턴스가 있으면 인스턴스 간 통신에 SSL/TLS 암호화를 구성해 전송 중 Secret 데이터를 보호하세요.
외부 Secrets 접근 구성
서드파티 Secrets 저장소 제공자를 사용해 기밀 데이터를 클러스터 밖에 두고, Pod가 그 정보에 접근하도록 구성할 수 있어요. Kubernetes Secrets Store CSI Driver는 kubelet이 외부 저장소에서 Secrets를 가져와 권한이 있는 특정 Pod에 볼륨으로 마운트하게 해주는 DaemonSet이에요.
개발자
Secret 접근을 특정 컨테이너로 제한
Pod에 여러 컨테이너를 정의하고 그중 하나만 Secret에 접근해야 한다면, 다른 컨테이너가 그 Secret에 접근하지 못하도록 볼륨 마운트나 환경 변수 구성을 정의하세요.
읽은 후 Secret 데이터 보호
애플리케이션은 환경 변수나 볼륨에서 읽은 후에도 기밀 정보 값을 보호해야 해요. 예를 들어 Secret 데이터를 평문으로 로깅하거나 신뢰할 수 없는 상대에게 전송하지 말아야 해요.
매니페스트를 통해 base64로 인코딩된 Secret 데이터를 구성했다면, 그 파일을 공유하거나 소스 저장소에 커밋하는 것은 매니페스트를 읽을 수 있는 모든 사람에게 Secret이 노출된다는 뜻이에요.
주의: base64 인코딩은 암호화가 아니에요. 평문에 비해 추가적인 기밀성을 제공하지 않아요.