Guía de control de acceso de Milvus: Cómo configurar RBAC para producción

He aquí una historia que es más común de lo que debería ser: un ingeniero de control de calidad ejecuta un script de limpieza contra lo que cree que es el entorno de ensayo. Excepto que la cadena de conexión apunta a producción. Unos segundos más tarde, las colecciones de vectores principales han desaparecido: se han perdido datos de características, la búsqueda de similitudes devuelve resultados vacíos y los servicios se degradan en general. El postmortem encuentra la misma causa raíz de siempre: todo el mundo se conectaba como root, no había límites de acceso y nada impedía que una cuenta de prueba dejara caer datos de producción.

Esto no es un caso aislado. Los equipos que construyen sobre Milvus - y bases de datos vectoriales en general - tienden a centrarse en el rendimiento del índice, el rendimiento y la escala de datos, mientras que tratan el control de acceso como algo de lo que ocuparse más tarde. Pero "más tarde" suele llegar en forma de incidente. A medida que Milvus pasa del prototipo a la columna vertebral de los conductos RAG de producción, los motores de recomendación y la búsqueda vectorial en tiempo real, la pregunta se vuelve inevitable: ¿quién puede acceder a su clúster Milvus y qué es exactamente lo que se les permite hacer?

Milvus incluye un sistema RBAC integrado para responder a esa pregunta. Esta guía cubre qué es RBAC, cómo lo implementa Milvus y cómo diseñar un modelo de control de acceso que mantenga segura la producción - completo con ejemplos de código y un recorrido completo del sistema RAG.

¿Qué es RBAC (Control de Acceso Basado en Roles)?

Elcontrol de acceso basado en roles (RBAC) es un modelo de seguridad en el que los permisos no se asignan directamente a usuarios individuales. En su lugar, los permisos se agrupan en roles, y a los usuarios se les asigna uno o más roles. El acceso efectivo de un usuario es la unión de todos los permisos de sus roles asignados. RBAC es el modelo de control de acceso estándar en los sistemas de bases de datos de producción - PostgreSQL, MySQL, MongoDB, y la mayoría de los servicios en la nube lo utilizan.

RBAC resuelve un problema fundamental de escalabilidad: cuando se tienen docenas de usuarios y servicios, la gestión de permisos por usuario se vuelve imposible de mantener. Con RBAC, usted define una función una vez (por ejemplo, "sólo lectura en la colección X"), la asigna a diez servicios y la actualiza en un solo lugar cuando cambian los requisitos.

¿Cómo implementa Milvus RBAC?

Milvus RBAC se basa en cuatro conceptos:

Concepto	Qué es	Ejemplo
Recurso	La cosa a la que se accede	Una instancia de Milvus, una base de datos o una colección específica
Privilegio / Grupo de privilegios	La acción que se realiza	Search Insert, , o un grupo como (colección de sólo lectura) DropCollection COLL_RO
Rol	Conjunto de privilegios asignados a recursos.	role_read_onlyPuede buscar y consultar todas las colecciones de la base de datos default
Usuario	Una cuenta Milvus (humana o de servicio)	rag_writercuenta de servicio utilizada por el proceso de ingestión

El acceso nunca se asigna directamente a los usuarios. Los usuarios obtienen roles, los roles contienen privilegios y los privilegios se asignan a los recursos. Este es el mismo modelo RBAC que se utiliza en la mayoría de los sistemas de bases de datos de producción. Si diez usuarios comparten el mismo rol, usted actualiza el rol una vez y el cambio se aplica a todos ellos.

El modelo RBAC de Milvus muestra cómo los Usuarios son asignados a Roles, y los Roles contienen Privilegios y Grupos de Privilegios que se aplican a los Recursos .

Cuando una solicitud llega a Milvus, pasa por tres comprobaciones:

1. Autenticación: ¿se trata de un usuario válido con las credenciales correctas?
2. Comprobación de funciones: ¿tiene este usuario asignada al menos una función?
3. Comprobación de privilegios: ¿alguna de las funciones del usuario permite la acción solicitada en el recurso solicitado?

Si falla alguna comprobación, se rechaza la solicitud.

Flujo de autenticación y autorización de Milvus: La solicitud del cliente pasa por la autenticación, la comprobación de funciones y la comprobación de privilegios: se rechaza en cualquier paso que falle, sólo se ejecuta si se superan todos.

Cómo habilitar la autenticación en Milvus

Por defecto, Milvus funciona con la autenticación desactivada - todas las conexiones tienen acceso total. El primer paso es activarla.

Componer Docker

Edite milvus.yaml y establezca authorizationEnabled en true:

common:
  security:
    authorizationEnabled: true

Cartas Helm

Edite values.yaml y añada la configuración en extraConfigFiles:

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

Para despliegues de Milvus Operator en Kubernetes, la misma configuración va en la sección spec.config de Milvus CR.

Una vez que se habilita la autenticación y Milvus se reinicia, cada conexión debe proporcionar credenciales. Milvus crea un usuario por defecto root con la contraseña Milvus - cámbiela inmediatamente.

from pymilvus import MilvusClient
# Connect with the default root account
client = MilvusClient(
uri=‘http://localhost:19530’,
token=“root:Milvus”
)
# Change the password
client.update_password(
user_name=“root”,
old_password=“Milvus”,
new_password=“xgOoLudt3Kc#Pq68”
)

Cómo configurar usuarios, roles y privilegios

Con la autenticación habilitada, este es el flujo de trabajo típico de configuración.

Paso 1: Crear usuarios

No permita que los servicios o miembros del equipo utilicen root. Cree cuentas dedicadas para cada usuario o servicio.

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

Paso 2: Crear Roles

Milvus tiene un rol incorporado admin, pero en la práctica usted querrá roles personalizados que coincidan con sus patrones de acceso reales.

client.create_role(role_name="role_a")

Paso 3: Crear grupos de privilegios

Un grupo de privilegios agrupa múltiples privilegios bajo un mismo nombre, facilitando la gestión del acceso a escala. Milvus proporciona 9 grupos de privilegios integrados:

Grupo incorporado	Alcance	Qué permite
COLL_RO	Colección	Operaciones de sólo lectura (consulta, búsqueda, etc.)
COLL_RW	Colección	Operaciones de lectura y escritura
COLL_Admin	Colección	Gestión completa de colecciones
DB_RO	Base de datos	Operaciones de base de datos de sólo lectura
DB_RW	Base de datos	Operaciones de base de datos de lectura y escritura
DB_Admin	Base de datos	Gestión completa de bases de datos
Cluster_RO	Clúster	Operaciones de clúster de sólo lectura
Cluster_RW	Clúster	Operaciones de clúster de lectura y escritura
Cluster_Admin	Clúster	Gestión completa del clúster

También puede crear grupos de privilegios personalizados cuando los incorporados no sean adecuados:

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

Paso 4: Conceder privilegios a una función

Conceda privilegios individuales o grupos de privilegios a un rol, con alcance a recursos específicos. Los parámetros collection_name y db_name controlan el alcance - utilice * para todos.

# Grant a single privilege
client.grant_privilege_v2(
    role_name="role_a",
    privilege="Search",
    collection_name='collection_01',
    db_name='default',
)
# Grant a privilege group
client.grant_privilege_v2(
role_name=“role_a”,
privilege=“privilege_group_1”,
collection_name=‘collection_01’,
db_name=‘default’,
)
# Grant a cluster-level privilege (* means all resources)
client.grant_privilege_v2(
role_name=“role_a”,
privilege=“ClusterReadOnly”,
collection_name='',
db_name='',
)

Paso 5: Asignar funciones a los usuarios

Un usuario puede tener varios roles. Sus permisos efectivos son la unión de todos los roles asignados.

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

Cómo auditar y revocar accesos

Saber qué accesos existen es tan importante como concederlos. Los permisos obsoletos -de antiguos miembros del equipo, servicios retirados o sesiones de depuración puntuales- se acumulan silenciosamente y amplían la superficie de ataque.

Compruebe los permisos actuales

Ver los roles asignados a un usuario:

client.describe_user(user_name="user_1")

Ver los privilegios concedidos a un rol:

client.describe_role(role_name="role_a")

Revocar privilegios de un rol

# Remove a single privilege
client.revoke_privilege_v2(
    role_name="role_a",
    privilege="Search",
    collection_name='collection_01',
    db_name='default',
)
# Remove a privilege group
client.revoke_privilege_v2(
role_name=“role_a”,
privilege=“privilege_group_1”,
collection_name=‘collection_01’,
db_name=‘default’,
)

Anular la asignación de una función a un usuario

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

Eliminar usuarios o funciones

Elimine todas las asignaciones de funciones antes de eliminar un usuario, y revoque todos los privilegios antes de eliminar una función:

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

Ejemplo: Cómo diseñar RBAC para un sistema RAG de producción

Los conceptos abstractos se entienden más rápido con un ejemplo concreto. Considere un sistema RAG construido sobre Milvus con tres servicios distintos:

Servicio	Responsabilidad	Acceso requerido
Administrador de la plataforma	Gestiona el clúster Milvus - crea colecciones, supervisa la salud, gestiona las actualizaciones	Administrador completo del clúster
Servicio de ingestión	Genera incrustaciones vectoriales a partir de documentos y las escribe en las colecciones	Lectura y escritura en colecciones
Servicio de búsqueda	Gestiona las consultas de búsqueda vectorial de los usuarios finales	Sólo lectura en colecciones

Esta es una configuración completa usando PyMilvus:

from pymilvus import MilvusClient
client = MilvusClient(
uri=‘http://localhost:19530’,
token=“root:xxx”  # Replace with your updated root password
)
# 1. Create users
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 access to roles
# Admin role: cluster-level admin access
client.grant_privilege_v2(
role_name=“role_admin”,
privilege=“Cluster_Admin”,
collection_name='',
db_name='',
)
# Read-only role: collection-level read-only access
client.grant_privilege_v2(
role_name=“role_read_only”,
privilege=“COLL_RO”,
collection_name=‘*’,
db_name=‘default’,
)
# Read-write role: collection-level read and write access
client.grant_privilege_v2(
role_name=“role_read_write”,
privilege=“COLL_RW”,
collection_name=‘*’,
db_name=‘default’,
)
# 4. Assign roles to users
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”)

Cada servicio obtiene exactamente el acceso que necesita. El servicio de búsqueda no puede borrar datos accidentalmente. El servicio de ingestión no puede modificar la configuración del clúster. Y si las credenciales del servicio de búsqueda se filtran, el atacante puede leer los vectores de incrustación, pero no puede escribir, eliminar o escalar a administrador.

Para los equipos que gestionan el acceso a través de múltiples despliegues de Milvus, Zilliz Cloud (Milvus gestionado) proporciona RBAC integrado con una consola web para gestionar usuarios, roles y permisos, sin necesidad de scripts. Es útil cuando prefiere gestionar el acceso a través de una interfaz de usuario en lugar de mantener secuencias de comandos de configuración en todos los entornos.

Mejores prácticas de control de acceso para producción

Los pasos de configuración anteriores son la mecánica. Estos son los principios de diseño que mantienen el control de acceso efectivo a lo largo del tiempo.

Bloquee la cuenta raíz

Cambie la contraseña por defecto root antes que cualquier otra cosa. En producción, la cuenta raíz sólo debe utilizarse para operaciones de emergencia y almacenarse en un gestor de secretos, no codificarse en la configuración de la aplicación ni compartirse a través de Slack.

Separe completamente los entornos

Utilice diferentes instancias de Milvus para desarrollo, puesta en escena y producción. La separación de entornos únicamente mediante RBAC es frágil: una cadena de conexión mal configurada y un servicio de desarrollo está escribiendo en datos de producción. La separación física (diferentes clusters, diferentes credenciales) elimina esta clase de incidentes por completo.

Aplicar el mínimo privilegio

Dé a cada usuario y servicio el acceso mínimo necesario para hacer su trabajo. Empiece con un acceso reducido y amplíelo sólo cuando exista una necesidad específica y documentada. En entornos de desarrollo se puede ser más relajado, pero el acceso en producción debe ser estricto y revisarse periódicamente.

Limpiar el acceso obsoleto

Cuando alguien abandona el equipo o se da de baja un servicio, revoca sus funciones y elimina sus cuentas inmediatamente. Las cuentas no utilizadas con permisos activos son el vector más común de acceso no autorizado: son credenciales válidas que nadie está supervisando.

Privilegios de alcance a colecciones específicas

Evite conceder permisos a collection_name='*' a menos que la función realmente necesite acceder a todas las colecciones. En configuraciones de varios inquilinos o sistemas con varias canalizaciones de datos, limite cada función únicamente a las colecciones en las que opera. Esto limita el radio de explosión si las credenciales se ven comprometidas.

---

Si está desplegando Milvus en producción y trabajando en el control de acceso, la seguridad o el diseño multiusuario, nos encantaría ayudarle:

• Únase a la comunidad Milvus Slack para discutir prácticas reales de despliegue con otros ingenieros que ejecutan Milvus a escala.
• Reserve una sesión gratuita de 20 minutos de Milvus Office Hours para revisar su diseño RBAC, ya sea la estructura de roles, el alcance a nivel de colección o la seguridad multientorno.
• Si prefiere omitir la configuración de la infraestructura y gestionar el control de acceso a través de una interfaz de usuario, Zilliz Cloud (Milvus gestionado) incluye RBAC integrado con una consola web, además de cifrado, aislamiento de red y cumplimiento de SOC 2 desde el primer momento.

---

Algunas preguntas que surgen cuando los equipos comienzan a configurar el control de acceso en Milvus:

P: ¿Puedo restringir el acceso de un usuario a determinadas colecciones y no a todas?

Sí. Cuando llame a grant_privilege_v2collection_name a la colección específica en lugar de *. La función del usuario sólo tendrá acceso a esa colección. Puede conceder privilegios a la misma función en varias colecciones llamando a la función una vez por colección.

P: ¿Cuál es la diferencia entre un privilegio y un grupo de privilegios en Milvus?

Un privilegio es una sola acción como Search, Insert, o DropCollection. Un grupo de privilegios agrupa múltiples privilegios bajo un nombre - por ejemplo, COLL_RO incluye todas las operaciones de lectura de colecciones. Conceder un grupo de privilegios es funcionalmente lo mismo que conceder individualmente cada uno de los privilegios que lo componen, pero es más fácil de gestionar.

P: ¿Afecta la autenticación al rendimiento de las consultas de Milvus?

La sobrecarga es insignificante. Milvus valida las credenciales y comprueba los permisos de rol en cada solicitud, pero se trata de una búsqueda en memoria - añade microsegundos, no milisegundos. No hay un impacto medible en la latencia de búsqueda o inserción.

P: ¿Puedo utilizar Milvus RBAC en una configuración multi-tenant?

Sí. Cree funciones separadas por inquilino, limite los privilegios de cada función a las colecciones de ese inquilino y asigne la función correspondiente a la cuenta de servicio de cada inquilino. Esto le proporciona un aislamiento a nivel de colección sin necesidad de instancias Milvus separadas. Para un multi-arrendamiento a mayor escala, consulte la guía de multi-arrendamiento de Milvus.