Qdrant self-hosted: API-ключ и проверка доступа без публикации сервера

Что нужно до настройки ключей?

Нужны Linux-хост с установленным Docker, локальный терминал, возможность сохранить два разных длинных случайных ключа в защищённом файле и свободные ресурсы под пустую тестовую коллекцию. Документация Qdrant не устанавливает универсальный минимум RAM/VRAM для этой проверки: здесь не загружается модель, а объём данных в будущем определяется вашей коллекцией. Скачивание образа и установка Docker требуют сети; запросы теста на 127.0.0.1 остаются на этой машине при отсутствии прокси и других сетевых компонентов. Это не доказывает офлайн-режим любого будущего приложения. s1 s2 s3

Не переносите команду быстрого старта с публикацией 6333:6333 на сервер в интернете. Для примера ниже Docker публикует только HTTP-порт 6333 на адресе хоста 127.0.0.1; порты 6334 и 6335 наружу не открываются. Qdrant внутри контейнера может слушать шире: проверяйте именно доступный адрес хоста и правила своей сети. Docker Engine старше? В версиях до 28.0.0 Docker предупреждает о возможном доступе к опубликованному localhost-порту с соседнего узла той же сети; при особой прямой маршрутизации к контейнеру также нужен отдельный сетевой контроль. Проверьте версию Docker и недоступность порта извне, не доверяя одному флагу -p. Если к базе обращаются с другой машины, этот рецепт не подходит: потребуется частный сетевой контур и TLS — шифрование соединения, иначе ключ и данные передаются без защиты. s1 s3 s5

Как включить два ключа на закрытом стенде?

1. В отдельной папке на Linux создайте файл qdrant-auth.env с правами чтения только для своего пользователя (chmod 600 qdrant-auth.env). В нём должны быть ровно две строки вида QDRANT__SERVICE__API_KEY=<АДМИН_КЛЮЧ> и QDRANT__SERVICE__READ_ONLY_API_KEY=<ДРУГОЙ_КЛЮЧ>; вместо угловых скобок впишите два разных случайных длинных значения из вашего менеджера секретов. Не копируйте примерные ключи из документации, не публикуйте файл в Git и не оставляйте значение пустым. Это файл Docker --env-file, не URL и не заголовок запроса. s1 s2 s3
2. Из этой папки запустите новый одноразовый контейнер: docker run -d --name qdrant-auth -p 127.0.0.1:6333:6333 -v qdrant_auth_storage:/qdrant/storage --env-file ./qdrant-auth.env qdrant/qdrant:v1.19.2. Docker должен вернуть ID контейнера; если контейнер не запустился, смотрите docker logs qdrant-auth не публикуя их вместе с секретами. Это не команда для обновления уже существующей базы; у новой демонстрации отдельный именованный том. s2 s4 s5 s6
3. Для проверки с ключами заведите локально, отдельно от env-файла, два файла конфигурации curl с правами chmod 600: в admin.curl строка header = "api-key: <АДМИН_КЛЮЧ>", в reader.curl — такая же строка с ключом чтения. Замените шаблоны реальными значениями только в личных файлах; в историю команд, URL, логи и общие скриншоты их не вставляйте. Для доступа с другой машины используйте TLS и доверенный сертификат, а не HTTP из этого локального примера. s1 s2

Как увидеть отказ без ключа и запрет записи?

На том же Linux-хосте отправьте curl -i http://127.0.0.1:6333/collections без заголовка. Ожидается 401 Unauthorized. Если вернулся 200, не подключайте рабочее приложение: проверьте, что запрос попал именно в новый контейнер, обе переменные непустые, а процесс запущен с новым env-файлом. Не проверяйте авторизацию по одному только главному URL: используйте маршрут коллекций. Это ожидаемое поведение по официальному руководству, не результат запуска редакции. s1 s2 s3

Теперь создайте только на пустом демонстрационном стенде коллекцию auth_probe полным ключом: curl -i --config ./admin.curl -X PUT http://127.0.0.1:6333/collections/auth_probe -H 'Content-Type: application/json' -d '{"vectors":{"size":3,"distance":"Cosine"}}'. Проверьте успешный ответ, затем curl -i --config ./reader.curl http://127.0.0.1:6333/collections/auth_probe: ключ чтения должен получить сведения о коллекции. Трёхмерный вектор здесь лишь синтетическая настройка пустой коллекции; это не размерность готовой embedding-модели и не тест поиска. s1 s2

Отправьте с ключом чтения запрос только к auth_probe: curl -i --config ./reader.curl -X POST http://127.0.0.1:6333/collections/auth_probe/points/delete -H 'Content-Type: application/json' -d '{"points":[999999]}'. В свежей пустой коллекции такой точки нет; ожидается 403 Forbidden до изменения данных. Если операция вернула успех, прекратите тест и пересмотрите права: ключ чтения не должен удалять точки. На реальной коллекции удаление не испытывайте. После проверки можно выполнить docker stop qdrant-auth и docker rm qdrant-auth; отдельный том qdrant_auth_storage и локальные файлы ключей удаляйте только после проверки, что они больше не нужны. s1 s2

Что этот тест не защищает?

Оба обычных ключа действуют на все коллекции: read-only запрещает запись, но не скрывает чужие данные от чтения. Для прав на отдельные коллекции у Qdrant есть токены с ограниченной областью доступа (JWT) при отдельной настройке jwt_rbac; для документов внутри одной коллекции нужна авторизация вашего приложения. Фильтр tenant_id сам по себе не право доступа, если пользователь может убрать или изменить его в запросе. Откройте проверку доступа к корпоративным документам после теста 401/403; для исходного локального поиска есть гайд Qdrant, а метаданные и фильтры разобраны отдельно. s1 s2

При переходе от одноразового стенда к работе не выдавайте admin-ключ клиентам, не открывайте 6333/6334/6335 в интернет, включите TLS и журналирование в зависимости от модели угроз. Если контейнер запущен, но получены неожиданные 401/403, сначала сверьте заголовок api-key, адрес, ключи и конфигурацию запуска, не раскрывая их в сообщении об ошибке. Ни 401/403, ни наличие ключа не доказывают сетевую изоляцию, защищённость документов или фактическую работу локальной модели. s1 s2 s3