Milvus RBAC Explicado: Proteja su base de datos vectorial con el control de acceso basado en funciones

Al crear un sistema de base de datos, los ingenieros dedican la mayor parte de su tiempo al rendimiento: tipos de índice, recuperación, latencia, rendimiento y escalado. Pero una vez que un sistema va más allá del portátil de un único desarrollador, otra cuestión se vuelve igual de crítica: ¿quién puede hacer qué dentro de su clúster Milvus? En otras palabras: control de acceso.

En todo el sector, muchos incidentes operativos tienen su origen en simples errores de permisos. Un script se ejecuta en el entorno equivocado. Una cuenta de servicio tiene un acceso más amplio de lo previsto. Una credencial de administrador compartida acaba en CI. Estos problemas suelen surgir como cuestiones muy prácticas:

• ¿Pueden los desarrolladores eliminar colecciones de producción?

• ¿Por qué una cuenta de prueba puede leer datos vectoriales de producción?

• ¿Por qué varios servicios inician sesión con el mismo rol de administrador?

• ¿Pueden los trabajos de análisis tener acceso de sólo lectura con cero privilegios de escritura?

Milvus aborda estos retos con el control de acceso basado en roles (RBAC). En lugar de otorgar a cada usuario derechos de superadministrador o intentar imponer restricciones en el código de la aplicación, RBAC le permite definir permisos precisos en la capa de la base de datos. Cada usuario o servicio obtiene exactamente las capacidades que necesita, nada más.

Este artículo explica cómo funciona RBAC en Milvus, cómo configurarlo y cómo aplicarlo con seguridad en entornos de producción.

Por qué es importante el control de acceso cuando se utiliza Milvus

Cuando los equipos son pequeños y sus aplicaciones de IA sólo sirven a un número limitado de usuarios, la infraestructura suele ser sencilla. Unos pocos ingenieros gestionan el sistema; Milvus se utiliza sólo para desarrollo o pruebas; y los flujos de trabajo operativos son sencillos. En esta fase inicial, el control de acceso rara vez parece urgente, porque la superficie de riesgo es pequeña y cualquier error puede revertirse fácilmente.

A medida que Milvus pasa a producción y crece el número de usuarios, servicios y operadores, el modelo de uso cambia rápidamente. Los escenarios comunes incluyen:

• Múltiples sistemas empresariales que comparten la misma instancia de Milvus

• Múltiples equipos que acceden a las mismas colecciones de vectores

• Datos de prueba, de puesta en escena y de producción que coexisten en un solo clúster

• Diferentes roles que necesitan diferentes niveles de acceso, desde consultas de sólo lectura hasta escrituras y control operativo

Sin límites de acceso bien definidos, estas configuraciones crean riesgos predecibles:

• Los flujos de trabajo de prueba pueden borrar accidentalmente las colecciones de producción.

• Los desarrolladores podrían modificar involuntariamente los índices utilizados por los servicios activos.

• El uso generalizado de la cuenta root hace que las acciones sean imposibles de rastrear o auditar.

• Una aplicación comprometida podría obtener acceso ilimitado a todos los datos del vector.

A medida que crece el uso, confiar en convenciones informales o cuentas de administrador compartidas ya no es sostenible. Un modelo de acceso coherente y aplicable se convierte en esencial, y esto es exactamente lo que proporciona Milvus RBAC.

Qué es RBAC en Milvus

RBAC (Role-Based Access Control) es un modelo de permiso que controla el acceso basado en roles en lugar de usuarios individuales. En Milvus, RBAC le permite definir exactamente qué operaciones puede realizar un usuario o servicio, y en qué recursos específicos. Proporciona una forma estructurada y escalable de gestionar la seguridad a medida que su sistema crece desde un único desarrollador hasta un entorno de producción completo.

Milvus RBAC se basa en los siguientes componentes principales:

Usuarios Roles Privilegios

• Recurso: La entidad a la que se accede. En Milvus, los recursos incluyen la instancia, la base de datos y la colección.

• Privilegio: Una operación específica permitida en un recurso, por ejemplo, crear una colección, insertar datos o eliminar entidades.

• Grupo de privilegios: Un conjunto predefinido de privilegios relacionados, como "sólo lectura" o "escritura".

• Rol: Una combinación de privilegios y los recursos a los que se aplican. Un rol determina qué operaciones pueden realizarse y dónde.

• Usuario: Una identidad en Milvus. Cada usuario tiene un ID único y se le asignan uno o más roles.

Estos componentes forman una jerarquía clara:

1. A los usuarios se les asignan roles

2. Los roles definen privilegios

3. Los privilegios se aplican a recursos específicos

Un principio de diseño clave en Milvus es que los permisos nunca se asignan directamente a los usuarios. Todos los accesos pasan por los roles. Esta indirección simplifica la administración, reduce los errores de configuración y hace que los cambios de permisos sean predecibles.

Este modelo se escala limpiamente en despliegues reales. Cuando varios usuarios comparten una función, la actualización de los privilegios de la función actualiza instantáneamente los permisos para todos ellos, sin modificar cada usuario individualmente. Es un único punto de control alineado con la forma en que la infraestructura moderna gestiona el acceso.

Cómo funciona RBAC en Milvus

Cuando un cliente envía una solicitud a Milvus, el sistema la evalúa a través de una serie de pasos de autorización. Cada paso debe ser superado antes de que la operación pueda continuar:

Cómo funciona RBAC en Milvus

1. Autenticar la solicitud: Milvus verifica primero la identidad del usuario. Si la autenticación falla, la solicitud se rechaza con un error de autenticación.

2. Comprobar la asignación de funciones: Tras la autenticación, Milvus comprueba si el usuario tiene asignado al menos un rol. Si no se encuentra ningún rol, la solicitud se rechaza con un error de permiso denegado.

3. Verificar los privilegios requeridos: A continuación, Milvus evalúa si el rol del usuario concede el privilegio requerido sobre el recurso de destino. Si la comprobación de privilegios falla, la solicitud se rechaza con un error de permiso denegado.

4. Ejecutar la operación: Si todas las comprobaciones son correctas, Milvus ejecuta la operación solicitada y devuelve el resultado.

Cómo configurar el control de acceso mediante RBAC en Milvus

1. Requisitos previos

Antes de que las reglas RBAC puedan ser evaluadas y aplicadas, la autenticación de usuario debe estar habilitada para que cada petición a Milvus pueda ser asociada con una identidad de usuario específica.

Aquí hay dos métodos de despliegue estándar.

• Despliegue con Docker Compose

Si Milvus se despliega utilizando Docker Compose, edite el archivo de configuración milvus.yaml y habilite la autorización estableciendo common.security.authorizationEnabled a true:

common:
  security:
    authorizationEnabled: true

• Desplegando con Helm Charts

Si Milvus se despliega utilizando Helm Charts, edite el archivo values.yaml y añada la siguiente configuración en extraConfigFiles.user.yaml:

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

2. Inicialización

Por defecto, Milvus crea un usuario root incorporado cuando se inicia el sistema. La contraseña por defecto para este usuario es Milvus.

Como paso inicial de seguridad, utilice el usuario root para conectarse a Milvus y cambie inmediatamente la contraseña por defecto. Se recomienda encarecidamente utilizar una contraseña compleja para evitar accesos no autorizados.

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. Operaciones básicas

Creación de usuarios

Para el uso diario, se recomienda crear usuarios dedicados en lugar de utilizar la cuenta root.

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

Crear roles

Milvus proporciona un rol incorporado admin con privilegios administrativos completos. Sin embargo, para la mayoría de los escenarios de producción, se recomienda crear roles personalizados para lograr un control de acceso más detallado.

client.create_role(role_name="role_a")

Crear grupos de privilegios

Un grupo de privilegios es una colección de múltiples privilegios. Para simplificar la gestión de permisos, los privilegios relacionados pueden agruparse y concederse juntos.

Milvus incluye los siguientes grupos de privilegios incorporados:

• COLL_RO, COLL_RW, COLL_ADMIN

• DB_RO, DB_RW, DB_ADMIN

• Cluster_RO, Cluster_RW, Cluster_ADMIN

El uso de estos grupos de privilegios incorporados puede reducir significativamente la complejidad del diseño de permisos y mejorar la consistencia entre roles.

Puede utilizar directamente los grupos de privilegios incorporados o crear grupos de privilegios personalizados según sea necesario.

# 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'])

Conceder privilegios o grupos de privilegios a roles

Una vez creado un rol, se le pueden conceder privilegios o grupos de privilegios. Los recursos de destino para estos privilegios pueden especificarse a diferentes niveles, incluyendo la instancia, la base de datos o las colecciones individuales.

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='*',
)

Asignación de funciones a usuarios

Una vez asignados los roles a un usuario, éste puede acceder a los recursos y realizar las operaciones definidas por dichos roles. A un mismo usuario se le puede conceder uno o varios roles, dependiendo del ámbito de acceso requerido.

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

4. Inspeccionar y revocar el acceso

Inspeccionar los roles asignados a un usuario

client.describe_user(user_name="user_1")

Inspeccionar Privilegios Asignados a un Rol

client.describe_role(role_name="role_a")

Revocar privilegios de una función

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',
)

Revocar Funciones de un Usuario

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

Borrar Usuarios y Roles

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

Ejemplo: Diseño de control de acceso para un sistema RAG impulsado por Milvus

Considere un sistema de Generación de Recuperación-Aumentada (RAG) construido sobre Milvus.

En este sistema, los diferentes componentes y usuarios tienen responsabilidades claramente separadas, y cada uno requiere un nivel de acceso diferente.

Actor	Responsabilidad	Acceso requerido
Administrador de la plataforma	Operaciones y configuración del sistema	Administración a nivel de instancia
Servicio de ingestión de vectores	Ingesta y actualización de datos vectoriales	Acceso de lectura y escritura
Servicio de búsqueda	Búsqueda y recuperación de vectores	Acceso de sólo lectura

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")

Consejos rápidos: Cómo operar con seguridad el control de acceso en producción

Para garantizar que el control de acceso siga siendo eficaz y manejable en sistemas de producción de larga duración, siga estas directrices prácticas.

1. Cambie la contraseñapredeterminada root y limite el uso de la cuenta root.

Actualice la contraseña por defecto root inmediatamente después de la inicialización y restrinja su uso únicamente a tareas administrativas. Evite utilizar o compartir la cuenta root para operaciones rutinarias. En su lugar, cree usuarios y roles dedicados para el acceso diario con el fin de reducir el riesgo y mejorar la responsabilidad.

2. Aísle físicamente las instancias de Milvus entre entornos

Despliegue instancias Milvus separadas para desarrollo, puesta en escena y producción. El aislamiento físico proporciona un límite de seguridad más fuerte que el control de acceso lógico por sí solo y reduce significativamente el riesgo de errores entre entornos.

3. Siga el principio de mínimo privilegio

Conceda únicamente los permisos necesarios para cada función:

• Entornos de desarrollo: los permisos pueden ser más permisivos para apoyar la iteración y las pruebas.

• Entornos de producción: los permisos deben limitarse estrictamente a lo necesario.

• Auditorías regulares: revisar periódicamente los permisos existentes para asegurarse de que siguen siendo necesarios

4. 4. Revocar activamente los permisos cuando ya no sean necesarios.

El control de acceso no se configura una sola vez, sino que requiere un mantenimiento continuo. Revoca las funciones y los privilegios rápidamente cuando cambien los usuarios, los servicios o las responsabilidades. Esto evita que los permisos no utilizados se acumulen con el tiempo y se conviertan en riesgos de seguridad ocultos.

Conclusión

Configurar el control de acceso en Milvus no es inherentemente complejo, pero es esencial para operar el sistema de manera segura y confiable en producción. Con un modelo RBAC bien diseñado, usted puede:

• Reducir el riesgo evitando operaciones accidentales o destructivas

• Mejorar la seguridad imponiendo el acceso con menos privilegios a los datos vectoriales.

• Estandarizar las operaciones mediante una clara separación de responsabilidades

• Escalar con confianza, sentando las bases para despliegues multi-tenant y a gran escala.

El control de acceso no es una función opcional ni una tarea puntual. Es una parte fundamental para operar Milvus de forma segura a largo plazo.

👉 Empieza a construir una sólida base de seguridad con RBAC para tu despliegue de Milvus.

Tiene preguntas o desea una inmersión profunda en cualquier característica del último Milvus? Únete a nuestro canal de Discord o presenta incidencias en GitHub. También puede reservar una sesión individual de 20 minutos para obtener información, orientación y respuestas a sus preguntas a través de Milvus Office Hours.