Ollama에 인증 기능이 없는 경우: 팀과 안전하게 공유하는 5가지 방법

Ollama는 API 키가 없습니다. 127.0.0.1:11434에서 리스닝하며 연결되는 누구에게나 응답합니다. 노트북에서는 괜찮습니다. 문제가 발생하는 것은 누군가가 OLLAMA_HOST=0.0.0.0을 설정하여 동료가 책상 아래의 GPU 박스를 사용할 수 있게 할 때이며, 그 순간부터 모든 엔드포인트는 접근 가능한 누구에게나 열립니다. 채팅뿐만 아니라 pull, delete, create, push 모두 해당됩니다.

올해 몇 가지 수치:

• 1월에 SentinelOne과 Censys는 130개국에서 인터넷에 공개된 약 175,000개의 Ollama 서버를 계산했습니다 [링크]. 이 중 48%가 도구 호출(tool calling) 기능이 있는 모델을 가지고 있었습니다.
• 5월에 Cyera는 Bleeding Llama (CVE-2026-7482)를 발표했습니다 [링크]. 인증되지 않은 두 개의 요청, 즉 조작된 GGUF 파일을 사용한 /api/create와 공격자의 레지스트리로의 /api/push가 서버 메모리(환경 변수, API 키, 다른 사람의 프롬프트 등)를 유출시켰습니다. 수정 사항은 2월에 0.17.1 버전으로 배포되었지만, 릴리스 노트에는 보안 패치라고 언급되지 않아 많은 서버가 업데이트되지 않았습니다.

Ollama 자체에서 키를 기다리지 마십시오. 2025년에 한 유지 관리자가 [PR을 통해 추가하는 과정에서] 다음과 같이 작성했습니다: "단기적으로는 Ollama 서버 자체에 API 키 시스템을 추가할 계획이 없습니다. 보통은 tailscale과 같은 VPN 사용을 권장합니다." 0.40.3 버전(2026년 10월 기준)까지도 여전히 서버 측 설정은 없습니다. OLLAMA_AUTH 변수는 있지만, 이는 ollama 클라이언트가 전송하는 요청에 서명만 하게 할 뿐입니다.

따라서 보호는 Ollama 앞에 위치해야 합니다. 가장 간단한 방법부터 가장 완벽한 방법까지 5가지 방법을 소개하며, 각각의 방법이 무엇을 열어두는지 설명합니다.

첫째, 자신의 서버가 공개되어 있지 않은지 확인하기

네트워크 외부의 기기에서:

curl -s --max-time 5 http://YOUR_PUBLIC_IP:11434/api/tags

만약 모델 목록이 출력된다면, 누구나 사용할 수 있습니다. 또한 ollama -v를 실행하여 0.17.1보다 오래된 버전은 무엇을 결정하든 업데이트가 필요합니다.

Ollama가 Docker에서 실행되는 경우, 포트가 어떻게 게시되었는지 확인하세요. -p 11434:11434는 모든 인터페이스에서 수신하며, Docker는 자체 iptables 규칙을 작성하기 때문에 11434를 거부하는 ufw 규칙은 이를 차단하지 못합니다. 대신 -p 127.0.0.1:11434:11434를 사용하거나, 다른 컨테이너만 필요하다면 포트를 아예 게시하지 마세요.

1. localhost에 두고 SSH 또는 Tailscale을 사용하기

가장 적은 노력으로 해결할 수 있습니다: Ollama는 비공개로 유지되고 사람들은 이미 인증 기능이 있는 채널을 통해 접속합니다.

한두 명의 사람에게는 SSH 터널만으로 충분합니다:

ssh -N -L 11434:localhost:11434 you@gpu-box

클라이언트는 마치 Ollama가 자체 장치에서 실행되는 것처럼 http://localhost:11434를 사용합니다.

팀의 경우, Tailscale이 일반적인 해결책이며, 이는 Ollama 유지 관리자가 제안한 방법입니다. Ollama가 모든 인터페이스에서 수신하도록 설정하세요 (sudo systemctl edit ollama):

[Service]
Environment="OLLAMA_HOST=0.0.0.0:11434"

그리고 방화벽이 tailnet으로부터 오는 트래픽만 포트를 허용하도록 설정하세요:

sudo ufw allow in on tailscale0 to any port 11434 proto tcp

ufw가 활성화되어 있고 기본적으로 수신 트래픽을 거부하므로, 다른 것은 통과하지 못합니다. Tailscale ACL은 어떤 사람이나 장치가 해당 박스에 아예 도달할 수 있는지 여부를 결정합니다.

남겨지는 취약점: 접속하는 사람은 모델 삭제를 포함하여 전체 API를 사용할 수 있습니다. 모든 요청이 Ollama에게 동일하게 보이므로, 누가 GPU를 사용하고 얼마나 많이 사용하는지 알 수 없으며, 실행한 사람으로부터 접근을 차단할 때 다른 사용자로부터도 차단할 수 없습니다. 또한 모든 사용자는 Tailscale을 설치하고 로그인해야 하며, 호스팅된 n8n과 같은 클라우드에서 실행되는 도구는 쉽게 참여할 수 없습니다.

2. 토큰을 확인하는 리버스 프록시

클라이언트가 일반적인 HTTPS 주소가 필요하다면, 토큰이 없는 요청을 거부하는 프록시를 앞에 배치하세요. Caddy를 사용하면 자체적으로 인증서를 가져옵니다:

ollama.example.com {
@no_token not header Authorization "Bearer {$OLLAMA_TOKEN}"
respond @no_token 401
...

환경 변수에 길고 무작위한 OLLAMA_TOKEN을 설정하여 Caddy를 시작합니다. Ollama 자체는 127.0.0.1에 머무릅니다. Host 라인이 중요합니다: localhost에서 리스닝하는 Ollama는 다른 호스트 이름으로 주소 지정된 요청은 거부하며, 이것이 Ollama FAQ가 nginx 예제에 Host localhost:11434를 설정하는 이유입니다. 이 라인이 없으면 Ollama는 실제 도메인 이름으로 들어오는 모든 요청에 대해 403을 반환합니다. 스트리밍은 그대로 작동합니다.

OpenAI 호환 클라이언트(Continue, Cursor, n8n, OpenAI SDK)는 https://ollama.example.com/v1을 기본 URL로 사용하여 토큰을 API 키로 사용합니다.

모델 관리 엔드포인트를 닫는 것은 토큰이 있더라도 할 가치가 있습니다: 이들은 Bleeding Llama가 필요했던 부분입니다.

여전히 열려 있는 것: 모두를 위한 하나의 토큰. 누군가가 떠날 때마다 모든 장치에서 이를 변경해야 합니다. 여전히 누가 무엇을 보냈는지 알 수 없습니다. nginx의 map이나 Caddy의 여러 매처(matchers)를 사용하여 각 사용자에게 고유한 토큰을 부여할 수는 있지만, 그러면 설정 파일 내에 자신만의 작은 게이트웨이를 작성하는 것입니다.

3. Open WebUI를 프런트 도어로 사용하기

팀이 이미 Open WebUI를 통해 채팅하고 있다면, 이것이 유일한 진입 경로가 될 수 있습니다. Ollama는 비공개로 유지되고, 모든 사람이 Open WebUI 계정을 갖거나(또는 SSO를 통해 로그인) API가 필요한 사람들은 개인 키를 생성합니다.

관리자가 Admin Settings → Authentication → API Keys에서 키를 활성화하고, 비관리자도 API Keys 권한이 필요하며, 그런 다음 각 사용자는 Settings → Account에서 키를 생성합니다. 문서에 따르면, 이 키는 웹 인터페이스와 동일한 엔드포인트(OpenAI 스타일의 /api/chat/completions, 그리고 Ollama로 전달되는 /ollama/api/*)에서 작동합니다.

남겨진 문제점: 키는 생성한 사람의 모든 권한을 갖게 됩니다. 엔드포인트 제한은 존재하지만, 이는 개별 키가 아닌 인스턴스의 모든 키에 적용됩니다. 문서에는 키당 지출량이나 속도 제한(rate limits)이 언급되어 있지 않아, 루프에 빠진 에이전트가 하루 종일 GPU를 점유할 수 있습니다.

4. 이를 위해 구축된 프록시: LoLLMs Hub 또는 LiteLLM

두 가지 기존 프로젝트는 수동으로 작성한 설정(config) 없이 각 사용자에게 키를 제공합니다.

LoLLMs Hub (ParisNeo 제작, 원래 ollama_proxy_server였으며 Ollama README에서는 "Ollama Fortress"로 명시됨)는 여러 개의 Ollama 서버 앞에 키, 속도 제한(rate limits), 사용자별 사용 통계(per-user usage stats)를 배치하고, 여러 GPU 머신에 부하를 분산하며, 관리자 페이지에서 모델을 가져오고 삭제할 수 있게 해줍니다. Apache-2.0 라이선스입니다. 박스(서버)가 하나 이상 있는 경우 이 프로젝트를 선택하세요.

LiteLLM proxy는 예산과 속도 제한이 포함된 가상 키를 각 사용자에게 제공하며, Ollama와 약 백 개의 클라우드 공급자(cloud providers)와 통신합니다. 가상 키는 옆에 Postgres 데이터베이스가 필요하며 설정이 많습니다. 팀원 중 누군가가 관리할 수 있는 경우 이 프로젝트를 선택하세요.

남겨진 문제점: 실행하고 업데이트해야 할 서비스가 하나 더 생깁니다. 이는 옵션 2와 3에도 해당하지만, 이들은 규모가 더 큽니다.

5. Spillway (제가 직접 구축한 것)

솔직히 말씀드리자면, 제가 Spillway를 작성했으니 이 부분을 염두에 두시기 바랍니다.

저는 Ollama가 하나의 GPU 박스에 있고, Claude나 OpenAI 비용을 지불하며, 인프라 운영 업무를 전담하는 사람이 없는 10~50인 규모의 회사를 위해 이것을 구축했습니다. 무료 오픈 소스이며 싱글 사인온(Single Sign-On) 기능이 포함되어 있고, 유료 플랜을 위해 제한되는 부분이 전혀 없습니다. SQLite와 관리자 페이지가 있는 하나의 컨테이너입니다:

mkdir spillway && cd spillway
curl -fsSLO https://raw.githubusercontent.com/Artemy-And/spillway/main/docker-compose.yml
echo "OLLAMA_URL=http://ollama:11434" >> .env
...

해당 compose 파일의 Ollama 컨테이너는 포트를 공개하지 않으므로 Spillway만이 접근할 수 있습니다. Spillway는 Ollama 자체 형식(/api/chat, /api/generate, /api/embed, /api/tags)뿐만 아니라 OpenAI와 Anthropic의 형식으로 응답하므로, Open WebUI, Claude Code, Codex 및 n8n은 측면 변경 없이 키를 통해 연결됩니다. 이는 /api/create, /api/push 또는 /api/delete는 전혀 포워딩하지 않습니다.

모든 사용자, 노트북 또는 n8n 워크플로우에는 일일 및 월별 달러 한도가 적용된 자체 키가 부여되며, 이 제한은 클라우드 모델이 동일한 키 뒤에 놓일 때 중요해집니다. GPU 자체에는 에이전트 키의 초당 요청 수를 제한하는 규칙이 있습니다. 요청 로그는 카드 번호와 같은 개인 데이터를 마스킹하여 누가 무엇을 보냈는지 보여주며, 또 다른 규칙은 클라우드 모델에서 이러한 데이터가 포함된 프롬프트를 차단하지만 로컬 모델은 여전히 응답합니다. 팀의 클라우드 예산이 소진되거나 제공업체가 다운될 경우, 요청은 실패하는 대신 로컬 모델로 전달됩니다.

남겨진 점: 아직 초기 단계(버전 0.4)이며 제가 유일한 유지 관리자입니다. AGPL-3.0 라이선스라 일부 회사에서 허용하지 않습니다. 여러 GPU 머신에 걸쳐 부하를 분산시키지 못합니다. 그리고 두 사람이 하나의 GPU만 공유하는 경우, 필요 이상으로 많습니다. 옵션 1을 사용하세요.

어떤 것을 선택할까요

어떤 것을 선택하든, Ollama 0.17.1 이상 버전을 실행하고 포트 11434가 인터넷에서 응답하지 않도록 하십시오. 만약 다른 방식으로 잘 작동하는 공유 Ollama 방식을 가지고 있다면 댓글로 알려주시면 감사하겠습니다.