Milvus RBAC expliqué : Sécurisez votre base de données Vector avec le contrôle d'accès basé sur les rôles

Lors de la construction d'un système de base de données, les ingénieurs consacrent la majeure partie de leur temps aux performances : types d'index, rappel, latence, débit et mise à l'échelle. Mais dès qu'un système dépasse l'ordinateur portable d'un seul développeur, une autre question devient tout aussi cruciale : qui peut faire quoi dans votre cluster Milvus? En d'autres termes, le contrôle d'accès.

Dans l'ensemble du secteur, de nombreux incidents opérationnels découlent de simples erreurs d'autorisation. Un script s'exécute dans le mauvais environnement. Un compte de service dispose d'un accès plus large que prévu. Un identifiant d'administrateur partagé se retrouve dans l'interface utilisateur. Ces problèmes apparaissent généralement sous la forme de questions très pratiques :

• Les développeurs sont-ils autorisés à supprimer des collections de production ?

• Pourquoi un compte de test peut-il lire les données vectorielles de production ?

• Pourquoi plusieurs services se connectent-ils avec le même rôle d'administrateur ?

• Les tâches d'analyse peuvent-elles avoir un accès en lecture seule avec des privilèges d'écriture nuls ?

Milvus relève ces défis grâce au contrôle d'accès basé sur les rôles (RBAC). Au lieu de donner à chaque utilisateur des droits de superadministrateur ou d'essayer d'appliquer des restrictions dans le code de l'application, le RBAC vous permet de définir des autorisations précises au niveau de la base de données. Chaque utilisateur ou service obtient exactement les capacités dont il a besoin, rien de plus.

Ce billet explique comment fonctionne le RBAC dans Milvus, comment le configurer et comment l'appliquer en toute sécurité dans les environnements de production.

Pourquoi le contrôle d'accès est important lors de l'utilisation de Milvus

Lorsque les équipes sont petites et que leurs applications d'IA ne servent qu'un nombre limité d'utilisateurs, l'infrastructure est généralement simple. Quelques ingénieurs gèrent le système, Milvus n'est utilisé que pour le développement ou les tests et les flux de travail opérationnels sont simples. Dans cette phase initiale, le contrôle d'accès semble rarement urgent, car la surface de risque est faible et toute erreur peut être facilement corrigée.

Lorsque Milvus passe en production et que le nombre d'utilisateurs, de services et d'opérateurs augmente, le modèle d'utilisation change rapidement. Les scénarios les plus courants sont les suivants

• Plusieurs systèmes commerciaux partageant la même instance de Milvus

• Plusieurs équipes accédant aux mêmes collections de vecteurs

• Des données de test, de mise en scène et de production coexistant dans un seul cluster

• Différents rôles nécessitant différents niveaux d'accès, depuis les requêtes en lecture seule jusqu'aux écritures et au contrôle opérationnel.

Sans limites d'accès bien définies, ces configurations créent des risques prévisibles :

• les flux de travail de test peuvent accidentellement supprimer des collections de production

• Les développeurs peuvent modifier involontairement les index utilisés par les services en direct.

• L'utilisation généralisée du compte root rend les actions impossibles à tracer ou à auditer.

• Une application compromise peut obtenir un accès illimité à toutes les données vectorielles.

Au fur et à mesure que l'utilisation augmente, il n'est plus possible de s'appuyer sur des conventions informelles ou sur des comptes d'administration partagés. Un modèle d'accès cohérent et applicable devient essentiel, et c'est exactement ce que fournit le système RBAC de Milvus.

Qu'est-ce que le RBAC dans Milvus ?

LeRBAC (Role-Based Access Control) est un modèle de permission qui contrôle l'accès en fonction des rôles plutôt que des utilisateurs individuels. Dans Milvus, le RBAC vous permet de définir exactement les opérations qu'un utilisateur ou un service est autorisé à effectuer et sur quelles ressources spécifiques. Il s'agit d'un moyen structuré et évolutif de gérer la sécurité au fur et à mesure que votre système passe d'un simple développeur à un environnement de production complet.

Milvus RBAC s'articule autour des composants de base suivants :

Utilisateurs Rôles Privilèges

• Ressource: L'entité à laquelle on accède. Dans Milvus, les ressources comprennent l'instance, la base de données et la collection.

• Privilège: Une opération spécifique autorisée sur une ressource, par exemple la création d'une collection, l'insertion de données ou la suppression d'entités.

• Groupe de privilèges: Un ensemble prédéfini de privilèges connexes, tels que "lecture seule" ou "écriture".

• Rôle: Combinaison de privilèges et des ressources auxquelles ils s'appliquent. Un rôle détermine quelles opérations peuvent être effectuées et où.

• Utilisateur: Identité dans Milvus. Chaque utilisateur a un identifiant unique et se voit attribuer un ou plusieurs rôles.

Ces éléments forment une hiérarchie claire :

1. Les utilisateurs se voient attribuer des rôles

2. Les rôles définissent les privilèges

3. Les privilèges s'appliquent à des ressources spécifiques.

L'un des principes clés de la conception de Milvus est que les autorisations ne sont jamais attribuées directement aux utilisateurs. Tous les accès passent par des rôles. Cette indirection simplifie l'administration, réduit les erreurs de configuration et rend les changements de permissions prévisibles.

Ce modèle s'adapte parfaitement aux déploiements réels. Lorsque plusieurs utilisateurs partagent un rôle, la mise à jour des privilèges du rôle met instantanément à jour les autorisations pour chacun d'entre eux, sans modifier chaque utilisateur individuellement. Il s'agit d'un point de contrôle unique aligné sur la manière dont l'infrastructure moderne gère l'accès.

Fonctionnement de RBAC dans Milvus

Lorsqu'un client envoie une demande à Milvus, le système l'évalue par le biais d'une série d'étapes d'autorisation. Chaque étape doit être réussie avant que l'opération ne soit autorisée :

Fonctionnement du système RBAC dans Milvus

1. Authentifier la demande : Milvus vérifie d'abord l'identité de l'utilisateur. Si l'authentification échoue, la demande est rejetée avec une erreur d'authentification.

2. Vérifier l'attribution des rôles : Après l'authentification, Milvus vérifie si l'utilisateur a au moins un rôle attribué. Si aucun rôle n'est trouvé, la demande est rejetée avec une erreur d'autorisation refusée.

3. Vérifier les privilèges requis : Milvus évalue ensuite si le rôle de l'utilisateur accorde le privilège requis sur la ressource cible. Si la vérification des privilèges échoue, la demande est rejetée avec une erreur de refus de permission.

4. Exécuter l'opération : Si tous les contrôles sont réussis, Milvus exécute l'opération demandée et renvoie le résultat.

Comment configurer le contrôle d'accès via RBAC dans Milvus ?

1. Conditions préalables

Avant que les règles RBAC puissent être évaluées et appliquées, l'authentification utilisateur doit être activée afin que chaque demande adressée à Milvus puisse être associée à une identité utilisateur spécifique.

Voici deux méthodes de déploiement standard.

• Déploiement avec Docker Compose

Si Milvus est déployé à l'aide de Docker Compose, modifiez le fichier de configuration milvus.yaml et activez l'autorisation en définissant common.security.authorizationEnabled sur true:

common:
  security:
    authorizationEnabled: true

• Déploiement avec Helm Charts

Si Milvus est déployé à l'aide de Helm Charts, modifier le fichier values.yaml et ajouter la configuration suivante sous extraConfigFiles.user.yaml:

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

2. Initialisation

Par défaut, Milvus crée un utilisateur root au démarrage du système. Le mot de passe par défaut de cet utilisateur est Milvus.

Comme première mesure de sécurité, utiliser l'utilisateur root pour se connecter à Milvus et changer immédiatement le mot de passe par défaut. Il est fortement recommandé d'utiliser un mot de passe complexe pour empêcher tout accès non autorisé.

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. Opérations principales

Création d'utilisateurs

Pour une utilisation quotidienne, il est recommandé de créer des utilisateurs dédiés au lieu d'utiliser le compte root.

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

Créer des rôles

Milvus fournit un rôle admin intégré avec des privilèges administratifs complets. Cependant, pour la plupart des scénarios de production, il est recommandé de créer des rôles personnalisés afin d'obtenir un contrôle d'accès plus fin.

client.create_role(role_name="role_a")

Créer des groupes de privilèges

Un groupe de privilèges est un ensemble de privilèges multiples. Pour simplifier la gestion des autorisations, des privilèges connexes peuvent être regroupés et accordés ensemble.

Milvus comprend les groupes de privilèges intégrés suivants :

• COLL_RO, COLL_RW, COLL_ADMIN

• DB_RO, DB_RW, DB_ADMIN

• Cluster_RO, Cluster_RW, Cluster_ADMIN

L'utilisation de ces groupes de privilèges intégrés peut réduire considérablement la complexité de la conception des autorisations et améliorer la cohérence entre les rôles.

Vous pouvez utiliser directement les groupes de privilèges intégrés ou créer des groupes de privilèges personnalisés selon vos besoins.

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

Octroi de privilèges ou de groupes de privilèges aux rôles

Après la création d'un rôle, des privilèges ou des groupes de privilèges peuvent lui être accordés. Les ressources cibles pour ces privilèges peuvent être spécifiées à différents niveaux, y compris l'instance, la base de données ou les collections individuelles.

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

Attribution de rôles aux utilisateurs

Une fois que des rôles sont attribués à un utilisateur, celui-ci peut accéder aux ressources et effectuer les opérations définies par ces rôles. Un même utilisateur peut se voir attribuer un ou plusieurs rôles, en fonction de l'étendue de l'accès requis.

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

4. Contrôler et révoquer l'accès

Contrôler les rôles attribués à un utilisateur

client.describe_user(user_name="user_1")

Inspecter les privilèges attribués à un rôle

client.describe_role(role_name="role_a")

Révoquer les privilèges d'un rôle

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

Révoquer les rôles d'un utilisateur

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

Supprimer des utilisateurs et des rôles

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

Exemple : Conception du contrôle d'accès pour un système RAG alimenté par Milvus

Considérons un système RAG (Retrieval-Augmented Generation) construit au-dessus de Milvus.

Dans ce système, les différents composants et utilisateurs ont des responsabilités clairement séparées et chacun nécessite un niveau d'accès différent.

Acteur	Responsabilité	Accès requis
Administrateur de la plate-forme	Opérations et configuration du système	Administration au niveau de l'instance
Service d'ingestion de vecteurs	Ingestion et mise à jour des données vectorielles	Accès en lecture et en écriture
Service de recherche	Recherche et récupération de données vectorielles	Accès en lecture seule

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

Conseils rapides : Comment utiliser le contrôle d'accès en toute sécurité dans la production

Pour s'assurer que le contrôle d'accès reste efficace et gérable dans les systèmes de production à long terme, il convient de suivre les conseils pratiques suivants.

1. Modifier le mot de passepar défaut root et limiter l'utilisation du compte root.

Mettez à jour le mot de passe par défaut root immédiatement après l'initialisation et limitez son utilisation aux seules tâches administratives. Évitez d'utiliser ou de partager le compte root pour les opérations de routine. Au lieu de cela, créez des utilisateurs et des rôles dédiés pour l'accès quotidien afin de réduire les risques et d'améliorer la responsabilité.

2. Isoler physiquement les instances Milvus dans les différents environnements

Déployer des instances Milvus distinctes pour le développement, la mise en scène et la production. L'isolation physique fournit une limite de sécurité plus forte que le contrôle d'accès logique seul et réduit considérablement le risque d'erreurs entre les environnements.

3. Suivre le principe du moindre privilège

N'accordez que les autorisations nécessaires à chaque rôle :

• Environnements de développement : les autorisations peuvent être plus permissives pour favoriser l'itération et les tests.

• Environnements de production : les autorisations doivent être strictement limitées à ce qui est nécessaire.

• Audits réguliers : revoir périodiquement les autorisations existantes pour s'assurer qu'elles sont toujours nécessaires.

4. Révoquer activement les autorisations lorsqu'elles ne sont plus nécessaires

Le contrôle d'accès n'est pas une opération ponctuelle, il nécessite une maintenance permanente. Révoquez rapidement les rôles et les privilèges lorsque les utilisateurs, les services ou les responsabilités changent. Cela permet d'éviter que les autorisations inutilisées ne s'accumulent au fil du temps et ne deviennent des risques de sécurité cachés.

Conclusion

La configuration du contrôle d'accès dans Milvus n'est pas complexe en soi, mais elle est essentielle pour que le système fonctionne de manière sûre et fiable en production. Avec un modèle RBAC bien conçu, vous pouvez :

• réduire les risques en empêchant les opérations accidentelles ou destructrices

• Améliorer la sécurité en imposant un accès aux données vectorielles avec le moins de privilèges possible.

• normaliser les opérations en séparant clairement les responsabilités

• Évoluer en toute confiance, en jetant les bases de déploiements multi-locataires et à grande échelle.

Le contrôle d'accès n'est pas une fonction optionnelle ou une tâche ponctuelle. Il s'agit d'un élément fondamental pour exploiter Milvus en toute sécurité sur le long terme.

👉 Commencez à construire une base de sécurité solide avec RBAC pour votre déploiement Milvus.

Vous avez des questions ou souhaitez approfondir l'une des fonctionnalités de la dernière version de Milvus ? Rejoignez notre canal Discord ou déposez des problèmes sur GitHub. Vous pouvez également réserver une session individuelle de 20 minutes pour obtenir des informations, des conseils et des réponses à vos questions dans le cadre des Milvus Office Hours.