설명
env.value_from.secret_key_ref 또는 env_from.secret_ref로 Secret을 환경 변수에 주입하면 애플리케이션의 로그, 디버깅 출력이나 프로세스 덤프에 값이 노출될 수 있습니다. Secret 참조는 구성에 값을 직접 적는 것을 피하지만 실행 중 노출 위험까지 없애지는 않습니다.
애플리케이션이 지원하면 필요한 Secret을 파일로 마운트하는 방식을 검토하세요. 파일도 허용된 프로세스가 읽을 수 있으므로 마운트 전환만으로 침해된 애플리케이션에서 비밀값을 보호할 수는 없습니다.
잠재적 영향
- 로그나 장애 분석 자료에 비밀값이 남을 수 있습니다.
- 유출된 키나 비밀번호의 권한에 따라 다른 시스템에 접근할 수 있습니다.
해결 방법
- 가능하면 Secret을 필요한 컨테이너에만 읽기 전용 파일로 마운트하고 파일 권한을 제한하세요. 애플리케이션이 해당 파일을 읽도록 구성하세요.
- 환경 변수가 꼭 필요하면 출력과 진단 자료에서 값을 숨기고 Secret·파드 디버깅 접근 권한을 최소화하세요. 환경 변수는 Secret 변경을 자동 반영하지 않으므로 비밀정보 교체 시 재시작을 계획하세요.
예시
db-secret은 같은 네임스페이스에 미리 준비해야 합니다. 기존 nginx 이미지는 전달 방식만 보여 주며 DB_PASSWORD나 마운트 파일을 자동으로 사용하지 않습니다. 실제 애플리케이션의 읽기 방식과 유지보수되는 이미지를 사용하세요.
변경 전
hcl
resource "kubernetes_pod" "example" {
metadata {
name = "app"
}
spec {
container {
name = "web"
image = "nginx:1.7.9"
env {
name = "DB_PASSWORD"
value_from {
secret_key_ref {
name = "db-secret"
key = "password"
}
}
}
}
}
}
변경 후
hcl
resource "kubernetes_pod" "example" {
metadata {
name = "app"
}
spec {
container {
name = "web"
image = "nginx:1.7.9"
volume_mount {
name = "db-secret"
mount_path = "/var/run/secrets/db"
read_only = true
}
}
volume {
name = "db-secret"
secret {
secret_name = "db-secret"
}
}
}
}
설명:
- 변경 전: password 키를 DB_PASSWORD 환경 변수로 전달합니다. 로그와 진단 출력에 주의해야 합니다.
- 변경 후: Secret을 읽기 전용 파일로 마운트합니다. 파일 권한과 애플리케이션의 실제 읽기 경로를 함께 구성해야 합니다.