보안

보안 (Security)

멀티 노드 vLLM 배포에서 노드 간 모든 통신은 기본적으로 안전하지 않습니다 (insecure by default). 노드를 격리된 네트워크에 배치해 보호해야 합니다. 이 문서는 노드 간 통신 구성, 방화벽 지침, API 키 인증 한계, 미디어 URL SSRF 보호, 리소스 소진 방지 등 vLLM 서빙 시스템을 보호하는 방법을 다룹니다.

출처: 문서

본문

노드 간 통신 (Inter-Node Communication)

멀티 노드 vLLM 배포에서 노드 간 모든 통신은 기본적으로 안전하지 않으며, 노드를 격리된 네트워크에 배치해 보호해야 합니다. 여기에는 다음이 포함됩니다:

  1. PyTorch Distributed 통신
  2. KV cache 전송 통신
  3. Tensor, Pipeline, Data parallel 통신

노드 간 통신 구성 옵션

다음 옵션이 vLLM의 inter-node 통신을 제어합니다:

1. 환경 변수:

  • VLLM_HOST_IP: vLLM 프로세스가 통신할 IP 주소 설정

2. KV cache 전송 구성:

  • --kv-ip: KV cache 전송 통신용 IP 주소 (기본: 127.0.0.1)
  • --kv-port: KV cache 전송 통신용 포트 (기본: 14579)

3. 데이터 병렬 구성:

  • data_parallel_master_ip: 데이터 병렬 마스터의 IP (기본: 127.0.0.1)
  • data_parallel_master_port: 데이터 병렬 마스터의 포트 (기본: 29500)

PyTorch Distributed에 대한 참고

vLLM은 일부 inter-node 통신에 PyTorch의 distributed 기능을 사용합니다. PyTorch Distributed 보안 고려사항에 대한 자세한 정보는 PyTorch Security Guide를 참고하세요.

PyTorch 보안 가이드의 핵심 포인트:

  • PyTorch Distributed 기능은 내부 통신 전용입니다
  • 신뢰할 수 없는 환경이나 네트워크에서 사용하도록 만들어진 것이 아닙니다
  • 성능상 이유로 인증 프로토콜(Authorization)이 포함되지 않습니다
  • 메시지가 암호화되지 않은 채 전송됩니다
  • 연결이 검사 없이 어디서든 수락됩니다

보안 권장사항 (Security Recommendations)

1. 네트워크 격리 (Network Isolation):

  • vLLM 노드를 전용·격리된 네트워크에 배포
  • 무단 접근을 막기 위해 네트워크 세그먼테이션 사용
  • 적절한 방화벽 규칙 구현

2. 구성 모범 사례 (Configuration Best Practices):

  • 항상 VLLM_HOST_IP를 기본값이 아닌 특정 IP 주소로 설정
  • 노드 간 필요한 포트만 허용하도록 방화벽 구성

3. 접근 제어 (Access Control):

  • 배포 환경에 대한 물리·네트워크 접근 제한
  • 관리 인터페이스에 적절한 인증·권한 부여 구현
  • 모든 시스템 컴포넌트에 최소 권한 원칙 적용

4. 미디어 URL 도메인 제한 (Restrict Domains Access for Media URLs):

--allowed-media-domains를 설정해 vLLM이 미디어 URL로 접근할 수 있는 도메인을 제한하면 SSRF(Server-Side Request Forgery) 공격을 막을 수 있습니다. (예: --allowed-media-domains upload.wikimedia.org github.com www.bogotobogo.com)

이 보호는 온라인 서빙 API(멀티모달 입력)와 배치 러너(vllm run-batch) 모두에 적용됩니다. 여기서 배치 transcription/translation 요청의 file_url 값이 같은 allowlist로 검증됩니다.

도메인 제한이 없으면 악의적인 사용자가 다음을 유발하는 URL을 공급할 수 있습니다:

  • 내부 서비스 타겟팅: 내부 네트워크 엔드포인트, 클라우드 메타데이터 서비스(예: 169.254.169.254), 또는 공개 접근 대상이 아닌 다른 서비스에 접근(SSRF)
  • 과도한 리소스 소비: 극도로 큰 파일이나 느린 엔드포인트를 가리켜, 서버가 무제한 데이터를 다운로드하게 해 메모리·디스크·네트워크 대역폭을 고갈

미디어가 올 것으로 기대하는 도메인만 명시적으로 allowlist하면 이런 악용에 대한 공격 표면을 크게 줄입니다.

또한 VLLM_MEDIA_URL_ALLOW_REDIRECTS=0을 설정해 HTTP 리다이렉트가 따라가 도메인 제한을 우회하는 것을 막는 것도 고려하세요.

5. 미디어 다운로드·디코드 크기 제한 (Restrict Media Download and Decode Sizes):

원격 미디어 응답과 압축 미디어 파일은 기가바이트로 팽창할 수 있습니다. vLLM은 OOM 서비스 거부를 막기 위해 다운로드·디코드 크기 제한을 적용합니다:

환경 변수 기본값 설명
VLLM_MAX_MEDIA_DOWNLOAD_SIZE_MB 256 단일 원격 미디어 응답의 MB 단위 최대 크기. 과대 응답은 전체 본문이 메모리에 물질화되기 전에 스트리밍 중 거부됨
VLLM_MAX_IMAGE_PIXELS 178956970 (~179M 픽셀) 디코드된 이미지 최대 픽셀 크기. 초과 이미지는 raster 메모리 할당 전에 거부됨. 기본값은 PIL의 내장 2x 압축 해제 폭탄 임계값(~680 MB RGB)과 일치
VLLM_MAX_AUDIO_CLIP_FILESIZE_MB 25 단일 오디오 파일의 압축 파일 크기 MB 한도. 모든 오디오 입력(멀티모달 채팅 URL, speech-to-text 업로드, data: URL, 로컬 파일 경로)에 디코딩 시작 전 적용
VLLM_MAX_AUDIO_DECODE_DURATION_S 600 디코드된 오디오 최대 시간(초). 압축 오디오가 수 기가바이트 float32 PCM으로 팽창하는 것을 방지
VLLM_MAX_AUDIO_DECODE_BYTES 268435456 (256 MiB) 오디오 디코딩이 할당할 수 있는 최대 float32 PCM 바이트. 부풀린 헤더 샘플레이트가 시간 가드를 우회하고 실제 프레임 수가 멀티-GiB 할당을 일으키는 샘플레이트 위조 방지
VLLM_MAX_EMBED_DECODE_BYTES 2147483648 (2 GiB) 클라이언트 제공 임베딩 페이로드(prompt_embeds, image_embeds, audio_embeds, video_embeds)가 밀집화(densified)될 때 할당할 수 있는 최대 바이트. 희소 텐서는 자체 선언 형태를 가지므로 수백 바이트 페이로드가 수백 GiB로 팽창할 수 있음. to_dense() 전에 검사되어 메모리가 절대 할당되지 않음. 0으로 설정하면 비활성화

이 중 어느 하나를 0으로 설정하면 해당 제한이 비활성화됩니다. 신뢰할 수 없는 사용자에게 노출된 배포에서는 권장되지 않습니다. 리소스 소진 공격에 대한 보호를 제거하기 때문입니다.

노출된 vLLM 시스템 보호: 보안과 방화벽 (Security and Firewalls)

vLLM은 안전하지 않은 네트워크 서비스를 사설 네트워크로 격리하도록 설계되었지만, 의존성·하부 프레임워크와 같은 구성 요소가 모든 네트워크 인터페이스에서 수신 대기하는 안전하지 않은 서비스를 열 수 있으며, 때로는 vLLM의 직접 제어 밖입니다.

주요 우려는 vLLM이 분산 통신에 사용하는 torch.distributed입니다(단일 호스트에서 vLLM을 사용할 때도). vLLM이 TCP 초기화를 사용하면(PyTorch TCP Initialization 문서 참고), PyTorch가 기본적으로 모든 네트워크 인터페이스에서 수신 대기하는 TCPStore를 만듭니다. 즉 추가 보호를 하지 않으면, 어떤 네트워크 인터페이스로든 당신의 머신에 닿을 수 있는 모든 호스트가 이 서비스에 접근할 수 있습니다.

PyTorch 관점에서 torch.distributed의 어떤 사용이든 기본적으로 안전하지 않다고 간주해야 합니다. 이것은 PyTorch 팀의 알려지고 의도적인 동작입니다.

방화벽 구성 지침

vLLM 시스템을 보호하는 가장 좋은 방법은 필요한 최소 네트워크 표면만 노출하도록 방화벽을 신중히 구성하는 것입니다. 대부분의 경우:

  • API 서버가 수신 대기하는 TCP 포트를 제외한 모든 인바운드 연결을 차단하세요.
  • 내부 통신(torch.distributed, KV cache 전송용 포트)용 포트가 신뢰할 수 있는 호스트·네트워크에서만 접근 가능하도록 하세요.
  • 이 내부 포트를 공개 인터넷이나 신뢰할 수 없는 네트워크에 절대 노출하지 마세요.

특정 방화벽 구성 지침은 운영 체제 또는 애플리케이션 플랫폼 문서를 참고하세요.

API 키 인증 한계 (API Key Authentication Limitations)

개요

--api-key 플래그(또는 VLLM_API_KEY 환경 변수)는 vLLM HTTP 서버에 인증을 제공하지만, /v1, /v2, /inference, /cohere 경로 접두어 아래의 엔드포인트에만 적용됩니다. 다른 많은 민감한 엔드포인트는 인증 강제 없이 같은 HTTP 서버에 노출됩니다.

중요: vLLM 접근 보안에 --api-key만 의존하지 마세요. 프로덕션 배포에는 추가 보안 조치가 필요합니다.

보호되는 엔드포인트 (API 키 필요)

--api-key가 구성되면 다음 엔드포인트가 Bearer 토큰 인증을 요구합니다:

  • /v1/models — 사용 가능한 모델 목록
  • /v1/chat/completions — 채팅 완성
  • /v1/chat/completions/batch — 배치 채팅 완성
  • /v1/chat/completions/render — 채팅 완성 요청 렌더링 (--enable-scale-out 설정 시 vllm serve에서, 또는 vllm launch render에서)
  • /v1/chat/completions/derender — 채팅 완성 요청 derender
  • /v1/completions — 텍스트 완성
  • /v1/completions/render — 완성 요청 렌더링
  • /v1/completions/derender — 완성 요청 derender
  • /v1/embeddings — 임베딩 생성
  • /v1/audio/transcriptions — 오디오 전사
  • /v1/audio/translations — 오디오 번역
  • /v1/messages — Anthropic 호환 messages API
  • /v1/messages/render — Anthropic 호환 messages 렌더링
  • /v1/messages/count_tokens — Anthropic messages 토큰 카운트
  • /v1/responses — 응답 생성
  • /v1/responses/render — 자급자족형 응답 요청 렌더링
  • /v1/responses/{response_id} — 응답 조회
  • /v1/responses/{response_id}/cancel — 응답 취소
  • /v1/score — 스코어링 API
  • /v1/rerank — 리랭킹 API
  • /v1/load_lora_adapter — LoRA 어댑터 로드 (모델 동작 변경 가능; --enable-loraVLLM_ALLOW_RUNTIME_LORA_UPDATING=True일 때만)
  • /v1/unload_lora_adapter — LoRA 어댑터 언로드
  • /inference/v1/generate — 완성 생성 (--enable-scale-out 또는 --tokens-only일 때)
  • /cohere/v2/chat/render — Cohere Chat v2 렌더링 (VLLM_ENABLE_COHERE_API=1 필요)
  • /v2/embed — Cohere Embed API
  • /v2/rerank — Cohere Rerank API

보호되지 않는 엔드포인트 (API 키 불필요)

--api-key가 구성되어도 다음 엔드포인트는 인증을 요구하지 않습니다:

추론 엔드포인트:

  • /invocations — SageMaker 호환 엔드포인트(/v1 엔드포인트와 같은 추론 함수로 라우팅)
  • /generative_scoring — 생성적 스코어링 API
  • /pooling — 풀링 API
  • /classify — 분류 API
  • /score — 스코어링 API(/v1 변형 아님)
  • /rerank — 리랭킹 API(/v1 변형 아님)

운영 제어 엔드포인트 ("generate" task 지원 시):

  • /pause — 생성 일시정지(서비스 거부 유발)
  • /resume — 생성 재개
  • /is_paused — 생성 일시정지 여부 확인
  • /abort_requests — in-flight 요청 중단(in-flight 작업 손실 유발)
  • /scale_elastic_ep — 스케일링 연산 트리거
  • /is_scaling_elastic_ep — 스케일링 진행 여부 확인
  • /init_weight_transfer_engine — RLHF용 가중치 전송 엔진 초기화
  • /update_weights — 모델 가중치 업데이트(모델 동작 변경 가능)
  • /get_world_size — 분산 world size 조회
  • /abort_requests — in-flight 요청 중단(--tokens-only에서 사용 가능)

유틸리티 엔드포인트:

  • /tokenize — 텍스트 토큰화 (--enable-scale-out으로 게이트되지 않음)
  • /detokenize — 토큰 디토큰화
  • /health — 헬스 체크
  • /ping — SageMaker 헬스 체크
  • /version — 버전 정보
  • /load — 서버 부하 메트릭

토크나이저 정보 엔드포인트 (--enable-tokenizer-info-endpoint 설정 시):

이 엔드포인트는 --enable-tokenizer-info-endpoint 플래그가 설정된 경우에만 제공됩니다. 채팅 템플릿·토크나이저 구성 같은 민감한 정보를 노출할 수 있습니다:

  • /tokenizer_info — 채팅 템플릿·구성을 포함한 종합 토크나이저 정보 조회

개발 엔드포인트 (VLLM_SERVER_DEV_MODE=1일 때):

이 엔드포인트들은 환경 변수 VLLM_SERVER_DEV_MODE1로 설정된 경우에만 제공됩니다. 개발·디버깅용이며 프로덕션에서 절대 활성화해서는 안 됩니다:

  • /server_info — 상세 서버 구성 조회
  • /reset_prefix_cache — prefix cache 리셋(서비스 중단 가능)
  • /reset_mm_cache — 멀티모달 캐시 리셋
  • /reset_encoder_cache — 인코더 캐시 리셋
  • /sleep — 엔진 슬립(서비스 거부 유발)
  • /wake_up — 엔진 깨우기
  • /is_sleeping — 엔진 슬립 여부 확인
  • /collective_rpc — 엔진에서 임의 RPC 메서드 실행(매우 위험)

프로파일러 엔드포인트 (--profiler-config로 프로파일링 활성화 시):

이 엔드포인트들은 프로파일링이 활성화될 때만 제공되며 로컬 개발에만 사용해야 합니다:

  • /start_profile — PyTorch profiler 시작
  • /stop_profile — PyTorch profiler 중지

참고: /invocations 엔드포인트는 특히 우려됩니다. 보호되는 /v1 엔드포인트와 같은 추론 기능에 무인증 접근을 제공하기 때문입니다.

보안 영향

vLLM HTTP 서버에 닿을 수 있는 공격자는:

  1. /invocations, /generative_scoring, /pooling, /classify, /score, /rerank 같은 보호된 경로 접두어 밖의 엔드포인트를 사용해 자격 증명 없이 임의 추론을 실행하며 인증을 우회
  2. 토큰 없이 /pause, /scale_elastic_ep, /abort_requests를 호출해 서비스 거부 유발
  3. 서버 상태를 조작하려고 운영 제어에 접근(예: 생성 일시정지, /update_weights로 모델 가중치 업데이트)
  4. --enable-tokenizer-info-endpoint가 설정되면: 프롬프트 엔지니어링 전략이나 기타 구현 세부를 드러낼 수 있는 채팅 템플릿을 포함한 민감한 토크나이저 구성에 접근
  5. VLLM_SERVER_DEV_MODE=1이 설정되면: /collective_rpc로 임의 RPC 명령 실행, 캐시 리셋, 엔진 슬립, 상세 서버 구성 접근

권장 보안 관행

1. 노출 엔드포인트 최소화

중요: 프로덕션 환경에서 VLLM_SERVER_DEV_MODE=1을 절대 설정하지 마세요. 개발 엔드포인트는 다음을 포함한 극도로 위험한 기능을 노출합니다:

  • /collective_rpc를 통한 임의 RPC 실행
  • 서비스를 중단시킬 수 있는 캐시 조작
  • 상세 서버 구성 노출

마찬가지로 프로덕션에서 프로파일러 엔드포인트를 절대 활성화하지 마세요.

--enable-tokenizer-info-endpoint에 주의하세요: 토크나이저 구성 정보를 노출해야 할 때만 /tokenizer_info 엔드포인트를 활성화하세요. 이 엔드포인트는 민감한 구현 세부나 프롬프트 엔지니어링 전략을 담을 수 있는 채팅 템플릿과 토크나이저 설정을 드러냅니다.

2. 리버스 프록시 뒤에 배포

가장 효과적인 방법은 vLLM을 리버스 프록시(nginx, Envoy, 또는 Kubernetes Gateway) 뒤에 배포하는 것입니다. 리버스 프록시가:

  • 최종 사용자에게 노출하려는 엔드포인트만 명시적으로 allowlist
  • 무인증 추론·운영 제어 엔드포인트를 포함한 다른 모든 엔드포인트 차단
  • 프록시 레이어에서 추가 인증·속도 제한·로깅 구현

요청 파라미터 리소스 제한 (Request Parameter Resource Limits)

일부 API 요청 파라미터는 리소스 소비에 큰 영향을 미치며 서버 리소스 소진에 악용될 수 있습니다. /v1/completions/v1/chat/completionsn 파라미터는 요청당 생성되는 독립 출력 시퀀스 수를 제어합니다. 매우 큰 값은 엔진이 n에 비례하여 메모리·CPU·GPU 시간을 할당하게 해, 호스트의 OOM과 서버가 다른 요청 처리를 차단하는 결과를 낼 수 있습니다.

이를 완화하기 위해 vLLM은 VLLM_MAX_N_SEQUENCES 환경 변수(기본: 16384)를 통해 n 파라미터에 구성 가능한 상한을 강제합니다. 이 한도를 초과하는 요청은 엔진에 도달하기 전에 거부됩니다.

권장사항

  • 공개 노출 배포: 단일 요청의 폭발 반경(blast radius)을 제한하기 위해 VLLM_MAX_N_SEQUENCES를 워크로드에 적절한 값(예: 64 또는 128)으로 설정
  • 리버스 프록시 레이어: vLLM 내장 한도 외에도 리버스 프록시에서 요청 본문 검증과 속도 제한을 적용해 악성 페이로드를 더 제한
  • 모니터링: 요청별 리소스 소비를 모니터링해 악용을 나타낼 수 있는 비정상 패턴 감지

툴 서버와 MCP 보안 (Tool Server and MCP Security)

vLLM은 --tool-server 인자로 외부 툴 서버 연결을 지원합니다. 이로써 모델이 Responses API(/v1/responses)를 통해 툴을 호출할 수 있습니다. 툴 서버 지원은 모든 모델에서 동작합니다 — 특정 모델 아키텍처로 제한되지 않습니다.

중요: 기본적으로 어떤 툴 서버도 활성화되지 않습니다. 구성으로 명시적으로 옵트인해야 합니다.

내장 데모 도구 (GPT-OSS)

--tool-server demo를 전달하면 툴 호출을 지원하는 모든 모델에서 동작하는 내장 데모 도구가 활성화됩니다. 이 도구 구현은 vLLM의 일부가 아니라 별도로 설치된 gpt-oss 패키지가 제공합니다. vLLM은 gpt-oss에 위임하는 얇은 래퍼를 제공합니다.

  • 코드 인터프리터 (python): Docker를 통한 Python 실행(gpt_oss.tools.python_docker 경유)
  • 웹 브라우저 (browser): Exa API 검색, EXA_API_KEY 필요(gpt_oss.tools.simple_browser 경유)

코드 인터프리터(Python 도구) 보안 위험

코드 인터프리터는 모델이 생성한 코드를 Docker 컨테이너 안에서 실행합니다. 그러나 컨테이너는 기본적으로 네트워크 격리가 구성되어 있지 않습니다. 호스트의 Docker 네트워킹 구성을 상속하므로(예: 기본 bridge 네트워크 또는 --network=host):

  • 컨테이너가 호스트 네트워크와 LAN에 접근할 수 있음
  • 컨테이너에서 도달 가능한 내부 서비스가 SSRF로 악용될 수 있음
  • 클라우드 메타데이터 서비스(예: 169.254.169.254)에 접근 가능
  • 컨테이너에서 취약한 내부 서비스(예: torch.distributed 엔드포인트)가 도달 가능하면 이를 공격하는 데 사용될 수 있음

실행되는 코드가 모델이 생성한 것이며 적대적 입력(프롬프트 주입)에 영향을 받을 수 있으므로 특히 우려됩니다.

내장 도구 가용성 제어

내장 데모 도구는 두 설정으로 제어됩니다:

  1. --tool-server demo: 내장 데모 도구(브라우저와 Python 코드 인터프리터) 활성화
  2. VLLM_GPT_OSS_SYSTEM_TOOL_MCP_LABELS: Responses API의 mcp 툴 타입으로 내장 도구가 요청될 때, 이 쉼표로 구분된 allowlist가 허용되는 툴 라벨을 제어. 유효한 값:
  3. container — 컨테이너 도구
  4. code_interpreter — Python 코드 실행 도구
  5. web_search_preview — 웹 검색/브라우저 도구

이 변수가 설정되지 않았거나 비어 있으면 MCP 툴 타입으로 요청된 내장 도구는 활성화되지 않습니다.

Python 코드 인터프리터를 비활성화하려면 VLLM_GPT_OSS_SYSTEM_TOOL_MCP_LABELS에서 code_interpreter를 생략하세요.

커스텀 구현을 고려하세요: GPT-OSS Python 도구는 참조 구현입니다. 프로덕션 배포의 경우 더 엄격한 격리 보장을 가진 커스텀 코드 실행 샌드박스를 구현하는 것을 고려하세요. GPT-OSS 문서에서 지침을 참고하세요.

동적 LoRA 로딩 (Dynamic LoRA Loading)

vLLM은 /v1/load_lora_adapter/v1/unload_lora_adapter API 엔드포인트를 통해 실행 중에 LoRA 어댑터를 동적으로 로드·언로드하는 것을 지원합니다. 이 기능은 기본적으로 활성화되지 않으며, --enable-lora와 환경 변수 VLLM_ALLOW_RUNTIME_LORA_UPDATING=True 둘 다 필요합니다.

경고: 동적 LoRA 로딩은 안전한 연산이 아니며 신뢰할 수 없는 클라이언트에 노출된 배포에서 활성화해서는 안 됩니다. 동적 LoRA 로딩을 활성화해야 한다면 /v1/load_lora_adapter/v1/unload_lora_adapter 엔드포인트 접근을 리버스 프록시 또는 네트워크 레벨 접근 제어로 신뢰할 수 있는 관리자에게만 제한하세요. 이 엔드포인트를 최종 사용자에게 노출하지 마세요. LoRA 어댑터 구성에 대한 자세한 내용은 LoRA Adapters 문서를 참고하세요.

엔드포인트 플러그인 (Endpoint Plugins)

vLLM은 vllm.endpoint_plugins 진입점 그룹을 통해 out-of-tree HTTP 라우트 로드를 지원합니다(작성 방법은 Endpoint Plugins 참고). 엔드포인트 플러그인은 EngineClient.collective_rpc로 엔진에 닿는 라우트를 포함해 임의 FastAPI 라우트를 등록할 수 있으므로, 서버의 신뢰된 코드베이스의 일부로 취급해야 하며 샌드박싱되거나 검토된 입력으로 취급해서는 안 됩니다.

엔드포인트 플러그인은 기본적으로 로드되지 않습니다. 다른 vLLM 플러그인 그룹(vllm.general_plugins, vllm.platform_plugins 등)은 VLLM_PLUGINS가 집합을 좁히지 않으면 발견된 모든 플러그인을 로드하지만, 엔드포인트 플러그인은 VLLM_PLUGINS가 설정되고 명시적으로 이름을 지정하지 않는 한 아무것도 로드하지 않습니다. 이는 VLLM_SERVER_DEV_MODE 뒤에 게이트된 개발 엔드포인트에서 쓰이는 "프로덕션에서 기본 꺼짐" 자세를 반영합니다. 두 표면 모두 운영자가 명시적으로 옵트인했을 때만 존재합니다.

권장 보안 관행

  1. 신뢰하는 플러그인만 allowlist. VLLM_PLUGINS를 실행하려는 정확한 플러그인 이름으로 설정하고, 배포 간 와일드카드나 allowlist 복사를 이름 있는 각 플러그인이 무엇을 하는지 검토 없이 하지 마세요.
  2. 배포 전에 라우트 감사. 플러그인의 attach_router는 기존 /v1/* 경로를 중복하는 것을 포함해 어떤 경로 아래에든 라우트를 추가할 수 있습니다. 현재 라우트 충돌 강제는 없으므로(RFC #46565 후속으로 추적), 악성·버그 있는 플러그인이 핵심 라우트를 가리고 그 동작을 조용히 대체할 수 있습니다. /v1/... 재사용 대신 구별되는 접두어(예: /plugins/<plugin-name>/...) 아래에 라우트를 네임스페이스하는 플러그인을 선호하고, 실제로 서빙되는 것에 대한 확신이 필요하면 시작 후 app.routes를 검토하세요.
  3. 플러그인 라우트를 다른 기본 무인증 표면처럼 취급. --api-key/v1, /v2, /inference, /cohere 경로 접두어만 보호합니다(API Key Authentication Limitations 참고). 그 접두어 밖의 플러그인 라우트는 플러그인이 자체 인증을 구현하지 않는 한 무인증입니다. 외부에 노출하려는 플러그인 라우트만 allowlist하는 리버스 프록시 뒤에 배포하세요.
  4. vllm.general_plugins 페어링을 기억하세요. 새 엔진 측 동작도 필요로 하는 플러그인은 그 절반을 vllm.general_plugins로 별도 제공하며, 이는 기본(제한되지 않으면 모두 로드) 자세로 모든 워커 프로세스에서 로드됩니다. 엔드포인트 플러그인을 allowlist하는 것만으로 페어링된 엔진 측 플러그인을 제한하지 않습니다. 둘 다 검토해야 합니다.

gRPC 인터페이스 (gRPC Interface)

vLLM은 --grpc-port 플래그로 활성화되는 별도 TCP 포트에서 선택적 gRPC Inference·Control 서비스를 제공합니다. 지정하지 않으면 gRPC 서버가 시작되지 않습니다. gRPC 리스너는 HTTP 서버와 같은 호스트 주소에 바인딩됩니다.

경고: gRPC 인터페이스는 기본적으로 안전하지 않습니다 — 인증·권한 부여·암호화를 구현하지 않습니다. 신뢰된 네트워크 안의 같은 위치(co-located) 서비스 간에만 사용하기 위한 사설·내부 인터페이스로 간주해야 합니다. gRPC 포트를 공개 인터넷이나 신뢰할 수 없는 클라이언트에 노출하지 마세요. gRPC 인터페이스를 활성화하면 방화벽 규칙, 네트워크 세그먼테이션, 또는 격리된 사설 네트워크 배포 같은 네트워크 레벨 접근 제어로 보호하세요.

보안 영향

gRPC 포트에 닿을 수 있는 공격자는:

  1. 자격 증명 없이 Generate·GenerateStream RPC로 임의 추론 실행
  2. Control 서비스를 통해 생성 일시정지, 엔진 슬립, 구성된 RL 가중치 업데이트 시작으로 엔진 상태 변이
  3. 무제한 생성 요청 제출로 GPU·컴퓨트 리소스 소비
  4. vLLM을 크래시시킬 수 있는 gRPC 인터페이스의 버그를 악용해 서비스 거부 유발

권장사항

  • gRPC 기반 추론에 특정 필요가 있을 때만 --grpc-port 활성화

더 알아보기 (Learn more)