Home
Blog
Milvus RBAC Explained: Защита базы данных Vector с помощью управления доступом на основе ролей

Milvus RBAC Explained: Защита базы данных Vector с помощью управления доступом на основе ролей

Tutorials

December 31, 2025

Juan Xu

При создании системы баз данных инженеры тратят большую часть своего времени на производительность: типы индексов, отзыв, задержка, пропускная способность и масштабирование. Но как только система выходит за пределы ноутбука одного разработчика, не менее важным становится другой вопрос: кто и что может делать в вашем кластере Milvus? Другими словами - контроль доступа.

Во всей отрасли многие инциденты, связанные с эксплуатацией, происходят из-за простых ошибок в разрешении. Скрипт запускается в неправильном окружении. Учетная запись службы имеет более широкий доступ, чем предполагалось. Общие учетные данные администратора попадают в CI. Обычно эти проблемы возникают в виде вполне практических вопросов:

Разрешено ли разработчикам удалять производственные коллекции?
Почему тестовая учетная запись может читать данные производственного вектора?
Почему несколько служб входят в систему с одной и той же ролью администратора?
Могут ли задания аналитики иметь доступ только для чтения с нулевыми правами на запись?

Milvus решает эти проблемы с помощью управления доступом на основе ролей (RBAC). Вместо того чтобы наделять каждого пользователя правами суперадмина или пытаться внедрить ограничения в код приложения, RBAC позволяет определить точные разрешения на уровне базы данных. Каждый пользователь или служба получает именно те возможности, которые ему нужны, и ничего больше.

В этом посте рассказывается о том, как работает RBAC в Milvus, как его настроить и как безопасно применять в производственных средах.

Почему контроль доступа имеет значение при использовании Milvus

Когда команды небольшие, а их приложения искусственного интеллекта обслуживают лишь ограниченное число пользователей, инфраструктура обычно проста. Системой управляют несколько инженеров, Milvus используется только для разработки или тестирования, а рабочие процессы просты. На этом раннем этапе контроль доступа редко кажется срочным, потому что поверхность риска невелика, а любые ошибки можно легко исправить.

По мере того как Milvus переходит на производственный уровень и растет число пользователей, сервисов и операторов, модель использования быстро меняется. К распространенным сценариям относятся:

Несколько бизнес-систем, совместно использующих один экземпляр Milvus
Доступ нескольких команд к одним и тем же коллекциям векторов
Тестовые, этапные и производственные данные, сосуществующие в одном кластере
Различные роли, нуждающиеся в различных уровнях доступа, от запросов только на чтение до записи и оперативного управления.

Без четко определенных границ доступа такие системы создают предсказуемые риски:

Тестовые рабочие процессы могут случайно удалить производственные коллекции
Разработчики могут непреднамеренно изменить индексы, используемые живыми сервисами.
Широко распространенное использование учетной записи root делает невозможным отслеживание или аудит действий.
Скомпрометированное приложение может получить неограниченный доступ ко всем векторным данным.

По мере роста использования, полагаться на неформальные соглашения или общие учетные записи администраторов становится все труднее. Становится необходимой последовательная, принудительная модель доступа - и именно это обеспечивает Milvus RBAC.

Что такое RBAC в Milvus

RBAC (Role-Based Access Control) - это модель разрешений, которая контролирует доступ на основе ролей, а не отдельных пользователей. В Milvus RBAC позволяет точно определить, какие операции разрешено выполнять пользователю или службе - и на каких конкретных ресурсах. Она обеспечивает структурированный, масштабируемый способ управления безопасностью по мере роста вашей системы от одного разработчика до полноценной производственной среды.

Milvus RBAC построен на основе следующих основных компонентов:

Users Roles Privileges Пользователи Роли Привилегии

Ресурс: Объект, к которому осуществляется доступ. В Milvus ресурсы включают экземпляр, базу данных и коллекцию.
Привилегия: Определенная разрешенная операция над ресурсом - например, создание коллекции, вставка данных или удаление сущностей.
Группа привилегий: Предопределенный набор связанных привилегий, например "только чтение" или "запись".
Роль: Сочетание привилегий и ресурсов, к которым они применяются. Роль определяет , какие операции можно выполнять и где.
Пользователь: личность в Milvus. Каждый пользователь имеет уникальный идентификатор и назначает одну или несколько ролей.

Эти компоненты образуют четкую иерархию:

Пользователям назначаются роли.
Роли определяют привилегии
Привилегии применяются к определенным ресурсам.

Ключевой принцип разработки Milvus заключается в том, что разрешения никогда не назначаются непосредственно пользователям. Весь доступ осуществляется через роли. Такая непрямая связь упрощает администрирование, уменьшает количество ошибок конфигурации и делает изменения прав предсказуемыми.

Эта модель хорошо масштабируется в реальных развертываниях. Когда несколько пользователей используют одну роль, обновление привилегий роли мгновенно обновляет разрешения для всех них, не изменяя их для каждого пользователя в отдельности. Это единая точка контроля, соответствующая тому, как современная инфраструктура управляет доступом.

Как работает RBAC в Milvus

Когда клиент отправляет запрос в Milvus, система оценивает его, проходя ряд этапов авторизации. Каждый шаг должен быть пройден, прежде чем операция будет разрешена:

How RBAC Works in Milvus Как работает RBAC в Milvus

Проверка подлинности запроса: Сначала Milvus проверяет личность пользователя. Если аутентификация не проходит, запрос отклоняется с ошибкой аутентификации.
Проверка назначения роли: После аутентификации Milvus проверяет, назначена ли пользователю хотя бы одна роль. Если роль не найдена, запрос отклоняется с ошибкой "Разрешение запрещено".
Проверка необходимых привилегий: Затем Milvus проверяет, предоставляет ли роль пользователя требуемые привилегии на целевом ресурсе. Если проверка привилегий не удается, запрос отклоняется с ошибкой "Разрешение отклонено".
Выполнить операцию: Если все проверки пройдены, Milvus выполняет запрошенную операцию и возвращает результат.

Как настроить контроль доступа с помощью RBAC в Milvus

1. Предварительные условия

Прежде чем правила RBAC будут оценены и применены, необходимо включить аутентификацию пользователей, чтобы каждый запрос к Milvus мог быть связан с конкретной личностью пользователя.

Вот два стандартных метода развертывания.

Развертывание с помощью Docker Compose

Если Milvus развертывается с помощью Docker Compose, отредактируйте конфигурационный файл milvus.yaml и включите авторизацию, установив common.security.authorizationEnabled на true:

common:
  security:
    authorizationEnabled: true

Развертывание с помощью Helm Charts

Если Milvus развертывается с помощью Helm Charts, отредактируйте файл values.yaml и добавьте следующую конфигурацию под extraConfigFiles.user.yaml:

extraConfigFiles:
  user.yaml: |+
    common:
      security:
        authorizationEnabled: true

2. Инициализация

По умолчанию Milvus создает встроенного пользователя root при запуске системы. Пароль по умолчанию для этого пользователя - Milvus.

В качестве начального шага безопасности используйте пользователя root для подключения к Milvus и немедленно измените пароль по умолчанию. Настоятельно рекомендуется использовать сложный пароль для предотвращения несанкционированного доступа.

from pymilvus import MilvusClient
# Connect to Milvus using the default root user
client = MilvusClient(
    uri='http://localhost:19530', 
    token="root:Milvus"
)
# Update the root password
client.update_password(
    user_name="root",
    old_password="Milvus", 
    new_password="xgOoLudt3Kc#Pq68"
)

3. Основные операции

Создание пользователей

Для ежедневного использования рекомендуется создавать специальных пользователей, а не использовать учетную запись root.

client.create_user(user_name="user_1", password="P@ssw0rd")

Создание ролей

Milvus предоставляет встроенную роль admin с полными административными привилегиями. Однако для большинства производственных сценариев рекомендуется создавать собственные роли для более тонкого контроля доступа.

client.create_role(role_name="role_a")

Создание групп привилегий

Группа привилегий - это набор из нескольких привилегий. Чтобы упростить управление разрешениями, связанные привилегии можно сгруппировать и предоставлять вместе.

Milvus включает следующие встроенные группы привилегий:

COLL_RO, COLL_RW, COLL_ADMIN
DB_RO, DB_RW, DB_ADMIN
Cluster_RO, Cluster_RW, Cluster_ADMIN

Использование этих встроенных групп привилегий позволяет значительно снизить сложность разработки разрешений и улучшить согласованность между ролями.

Вы можете либо использовать встроенные группы привилегий напрямую, либо создавать собственные группы привилегий по мере необходимости.

# Create a privilege group
client.create_privilege_group(group_name='privilege_group_1'）
# Add privileges to the privilege group
client.add_privileges_to_group(group_name='privilege_group_1', privileges=['Query', 'Search'])

Предоставление привилегий или групп привилегий ролям

После создания роли ей могут быть предоставлены привилегии или группы привилегий. Целевые ресурсы для этих привилегий могут быть указаны на разных уровнях, включая экземпляр, базу данных или отдельные коллекции.

client.grant_privilege_v2(
    role_name="role_a",
    privilege="Search",
    collection_name='collection_01',
    db_name='default',
)
client.grant_privilege_v2(
    role_name="role_a",
    privilege="privilege_group_1",
    collection_name='collection_01',
    db_name='default',
)
client.grant_privilege_v2(
    role_name="role_a",
    privilege="ClusterReadOnly",
    collection_name='*',
    db_name='*',
)

Предоставление ролей пользователям

После того как роли назначены пользователю, он может получать доступ к ресурсам и выполнять операции, определенные этими ролями. Одному пользователю может быть предоставлена одна или несколько ролей, в зависимости от требуемого объема доступа.

client.grant_role(user_name="user_1", role_name="role_a")

4. Проверка и отмена доступа

Проверка ролей, назначенных пользователю

client.describe_user(user_name="user_1")

Проверка привилегий, назначенных роли

client.describe_role(role_name="role_a")

Отмена привилегий у роли

client.revoke_privilege_v2(
    role_name="role_a",
    privilege="Search",
    collection_name='collection_01',
    db_name='default',
)
client.revoke_privilege_v2(
    role_name="role_a",
    privilege="privilege_group_1",
    collection_name='collection_01',
    db_name='default',
)

Отмена ролей у пользователя

client.revoke_role(
    user_name='user_1',
    role_name='role_a'
)

Удаление пользователей и ролей

client.drop_user(user_name="user_1")
client.drop_role(role_name="role_a")

Пример: Проектирование контроля доступа для системы RAG на базе Milvus

Рассмотрим систему Retrieval-Augmented Generation (RAG), построенную на базе Milvus.

В этой системе различные компоненты и пользователи имеют четко разграниченные обязанности, и для каждого из них требуется свой уровень доступа.

Актор	Ответственность	Требуемый доступ
Администратор платформы	Системные операции и конфигурация	Администрирование на уровне экземпляра
Служба сбора векторных данных	Получение и обновление векторных данных	Доступ для чтения и записи
Служба поиска	Поиск и извлечение векторных данных	Доступ только для чтения

from pymilvus import MilvusClient
client = MilvusClient(
    uri='http://localhost:19530',
    token="root:xxx"  # Replace with the updated root password
)
# 1. Create a user (use a strong password)
client.create_user(user_name="rag_admin", password="xxx")
client.create_user(user_name="rag_reader", password="xxx")
client.create_user(user_name="rag_writer", password="xxx")
# 2. Create roles
client.create_role(role_name="role_admin")
client.create_role(role_name="role_read_only")
client.create_role(role_name="role_read_write")
# 3. Grant privileges to the role
## Using built-in Milvus privilege groups
client.grant_privilege_v2(
    role_name="role_admin",
    privilege="Cluster_Admin",
    collection_name='*',
    db_name='*',
)
client.grant_privilege_v2(
    role_name="role_read_only",
    privilege="COLL_RO",
    collection_name='*',
    db_name='default',
)
client.grant_privilege_v2(
    role_name="role_read_write",
    privilege="COLL_RW",
    collection_name='*',
    db_name='default',
)
# 4. Assign the role to the user
client.grant_role(user_name="rag_admin", role_name="role_admin")
client.grant_role(user_name="rag_reader", role_name="role_read_only")
client.grant_role(user_name="rag_writer", role_name="role_read_write")

Быстрые советы: Как безопасно управлять контролем доступа в производстве

Чтобы контроль доступа оставался эффективным и управляемым в длительных производственных системах, следуйте этим практическим рекомендациям.

1. Измените парольпо умолчанию root и ограничьте использование учетной записи root.

Обновите пароль по умолчанию root сразу после инициализации и ограничьте его использование только административными задачами. Избегайте использования или совместного использования учетной записи root для рутинных операций. Вместо этого создайте специальных пользователей и роли для повседневного доступа, чтобы снизить риск и улучшить подотчетность.

2. Физически изолируйте экземпляры Milvus в разных средах

Разверните отдельные экземпляры Milvus для разработки, постановки и производства. Физическая изоляция обеспечивает более надежную границу безопасности, чем логический контроль доступа, и значительно снижает риск ошибок в разных средах.

3. Следуйте принципу наименьших привилегий

Предоставляйте только те разрешения, которые необходимы для каждой роли:

Среды разработки: разрешения могут быть более свободными для поддержки итераций и тестирования.
Производственные среды: разрешения должны быть строго ограничены тем, что необходимо.
Регулярный аудит: периодически проверяйте существующие разрешения, чтобы убедиться, что они по-прежнему необходимы.

4. Активно отменяйте разрешения, когда они больше не нужны

Контроль доступа - это не одноразовая настройка, он требует постоянного обслуживания. Оперативно отменяйте роли и привилегии, когда меняются пользователи, службы или обязанности. Это предотвратит накопление неиспользуемых разрешений со временем и превращение их в скрытые риски безопасности.

Заключение

Настройка управления доступом в Milvus не является сложной по своей сути, но она необходима для безопасной и надежной работы системы в производстве. С помощью хорошо продуманной модели RBAC вы сможете:

Снизить риск, предотвращая случайные или разрушительные операции
Повысить уровень безопасности, обеспечив доступ к векторным данным с наименьшими привилегиями
Стандартизировать операции за счет четкого разделения обязанностей
Уверенно масштабировать систему, закладывая основу для многопользовательских и масштабных развертываний.

Контроль доступа - это не дополнительная функция или одноразовая задача. Это основополагающая часть безопасной эксплуатации Milvus в долгосрочной перспективе.

👉 Начните создавать надежную основу безопасности с помощью RBAC для своего развертывания Milvus.

У вас есть вопросы или вы хотите получить подробную информацию о любой функции последней версии Milvus? Присоединяйтесь к нашему каналу Discord или создавайте проблемы на GitHub. Вы также можете заказать 20-минутную индивидуальную сессию, чтобы получить знания, рекомендации и ответы на свои вопросы в Milvus Office Hours.