Secret 환경 변수 노출 위험 점검

Secret 전달 방식과 로그·진단 도구의 비밀값 노출을 함께 관리하세요.

설명

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을 읽기 전용 파일로 마운트합니다. 파일 권한과 애플리케이션의 실제 읽기 경로를 함께 구성해야 합니다.

참조