Milvus RBAC spiegato: Proteggete il vostro database di vettori con il controllo degli accessi basato sui ruoli

Quando si costruisce un sistema di database, gli ingegneri dedicano la maggior parte del loro tempo alle prestazioni: tipi di indici, richiamo, latenza, throughput e scalabilità. Ma quando un sistema va oltre il laptop di un singolo sviluppatore, un'altra questione diventa altrettanto critica: chi può fare cosa all'interno del cluster Milvus? In altre parole, il controllo degli accessi.

In tutto il settore, molti incidenti operativi derivano da semplici errori di autorizzazione. Uno script viene eseguito nell'ambiente sbagliato. Un account di servizio ha un accesso più ampio di quello previsto. Una credenziale di amministrazione condivisa finisce in CI. Questi problemi di solito si presentano come domande molto pratiche:

• Gli sviluppatori possono cancellare le collezioni di produzione?

• Perché un account di test può leggere i dati del vettore di produzione?

• Perché più servizi accedono con lo stesso ruolo di amministratore?

• I lavori di analisi possono avere accesso in sola lettura con zero privilegi di scrittura?

Milvus affronta queste sfide con il controllo degli accessi basato sui ruoli (RBAC). Invece di dare a ogni utente diritti di superamministratore o di cercare di imporre restrizioni nel codice dell'applicazione, RBAC consente di definire autorizzazioni precise a livello di database. Ogni utente o servizio ottiene esattamente le capacità di cui ha bisogno e niente di più.

Questo post spiega come funziona il RBAC in Milvus, come configurarlo e come applicarlo in modo sicuro negli ambienti di produzione.

Perché il controllo degli accessi è importante quando si usa Milvus

Quando i team sono piccoli e le loro applicazioni AI servono solo un numero limitato di utenti, l'infrastruttura è solitamente semplice. Pochi ingegneri gestiscono il sistema; Milvus viene utilizzato solo per lo sviluppo o i test e i flussi di lavoro operativi sono semplici. In questa fase iniziale, il controllo degli accessi è raramente sentito come urgente, perché la superficie di rischio è ridotta e qualsiasi errore può essere facilmente annullato.

Quando Milvus entra in produzione e il numero di utenti, servizi e operatori cresce, il modello di utilizzo cambia rapidamente. Gli scenari più comuni includono:

• più sistemi aziendali che condividono la stessa istanza di Milvus

• Più team che accedono alle stesse raccolte di vettori

• Dati di test, staging e produzione che coesistono in un unico cluster

• Ruoli diversi che necessitano di diversi livelli di accesso, dalle query di sola lettura alla scrittura e al controllo operativo.

Senza confini di accesso ben definiti, queste configurazioni creano rischi prevedibili:

• I flussi di lavoro di test potrebbero cancellare accidentalmente le collezioni di produzione.

• Gli sviluppatori potrebbero modificare involontariamente gli indici utilizzati dai servizi live.

• L'uso diffuso dell'account root rende le azioni impossibili da rintracciare o verificare.

• Un'applicazione compromessa potrebbe ottenere accesso illimitato a tutti i dati del vettore.

Con l'aumento dell'utilizzo, affidarsi a convenzioni informali o ad account di amministrazione condivisi non è più sostenibile. Un modello di accesso coerente e applicabile diventa essenziale, ed è esattamente quello che Milvus RBAC fornisce.

Cos'è il RBAC in Milvus

RBAC (Role-Based Access Control) è un modello di autorizzazione che controlla l'accesso in base ai ruoli piuttosto che ai singoli utenti. In Milvus, il RBAC consente di definire esattamente le operazioni che un utente o un servizio può eseguire e su quali risorse specifiche. Questo modello offre un modo strutturato e scalabile di gestire la sicurezza man mano che il sistema cresce, da un singolo sviluppatore a un ambiente di produzione completo.

Milvus RBAC si basa sui seguenti componenti principali:

Utenti Ruoli Privilegi

• Risorsa: L'entità a cui si accede. In Milvus, le risorse includono l'istanza, il database e la collezione.

• Privilegio: Un'operazione specifica consentita su una risorsa, ad esempio la creazione di una raccolta, l'inserimento di dati o la cancellazione di entità.

• Gruppo di privilegi: Un insieme predefinito di privilegi correlati, come "sola lettura" o "scrittura".

• Ruolo: Una combinazione di privilegi e risorse a cui si applicano. Un ruolo determina quali operazioni possono essere eseguite e dove.

• Utente: un'identità in Milvus. Ogni utente ha un ID unico e gli vengono assegnati uno o più ruoli.

Questi componenti formano una chiara gerarchia:

1. Agli utenti vengono assegnati dei ruoli

2. I ruoli definiscono i privilegi

3. I privilegi si applicano a risorse specifiche

Un principio chiave della progettazione di Milvus è che i permessi non vengono mai assegnati direttamente agli utenti. Tutti gli accessi passano attraverso i ruoli. Questa indirezione semplifica l'amministrazione, riduce gli errori di configurazione e rende prevedibili le modifiche ai permessi.

Questo modello è perfettamente scalabile nelle implementazioni reali. Quando più utenti condividono un ruolo, l'aggiornamento dei privilegi del ruolo aggiorna istantaneamente le autorizzazioni per tutti gli utenti, senza modificare ogni singolo utente. Si tratta di un unico punto di controllo, in linea con le modalità di gestione degli accessi delle infrastrutture moderne.

Come funziona RBAC in Milvus

Quando un cliente invia una richiesta a Milvus, il sistema la valuta attraverso una serie di passaggi di autorizzazione. Ogni fase deve essere superata prima di poter procedere con l'operazione:

Come funziona RBAC in Milvus

1. Autenticare la richiesta: Milvus verifica innanzitutto l'identità dell'utente. Se l'autenticazione fallisce, la richiesta viene rifiutata con un errore di autenticazione.

2. Verifica dell'assegnazione dei ruoli: Dopo l'autenticazione, Milvus controlla se l'utente ha almeno un ruolo assegnato. Se non viene trovato alcun ruolo, la richiesta viene rifiutata con un errore di autorizzazione negata.

3. Verifica dei privilegi richiesti: Milvus valuta quindi se il ruolo dell'utente concede i privilegi richiesti sulla risorsa di destinazione. Se la verifica dei privilegi fallisce, la richiesta viene rifiutata con un errore di autorizzazione negata.

4. Esecuzione dell'operazione: Se tutti i controlli sono superati, Milvus esegue l'operazione richiesta e restituisce il risultato.

Come configurare il controllo degli accessi tramite RBAC in Milvus

1. Prerequisiti

Prima di poter valutare e applicare le regole RBAC, è necessario abilitare l'autenticazione degli utenti, in modo che ogni richiesta a Milvus possa essere associata a un'identità utente specifica.

Ecco due metodi di distribuzione standard.

• Distribuzione con Docker Compose

Se Milvus viene distribuito con Docker Compose, modificare il file di configurazione milvus.yaml e abilitare l'autorizzazione impostando common.security.authorizationEnabled su true:

common:
  security:
    authorizationEnabled: true

• Distribuzione con Helm Charts

Se Milvus viene distribuito utilizzando Helm Charts, modificare il file values.yaml e aggiungere la seguente configurazione sotto extraConfigFiles.user.yaml:

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

2. Inizializzazione

Per impostazione predefinita, Milvus crea un utente integrato root all'avvio del sistema. La password predefinita per questo utente è Milvus.

Come misura di sicurezza iniziale, utilizzare l'utente root per connettersi a Milvus e cambiare immediatamente la password predefinita. Si raccomanda vivamente di utilizzare una password complessa per evitare accessi non autorizzati.

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. Operazioni principali

Creare gli utenti

Per l'uso quotidiano, si consiglia di creare utenti dedicati invece di usare l'account root.

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

Creare ruoli

Milvus fornisce un ruolo integrato admin con tutti i privilegi amministrativi. Per la maggior parte degli scenari di produzione, tuttavia, si consiglia di creare ruoli personalizzati per ottenere un controllo degli accessi a grana più fine.

client.create_role(role_name="role_a")

Creare gruppi di privilegi

Un gruppo di privilegi è un insieme di privilegi multipli. Per semplificare la gestione dei permessi, i privilegi correlati possono essere raggruppati e concessi insieme.

Milvus include i seguenti gruppi di privilegi incorporati:

• COLL_RO, COLL_RW, COLL_ADMIN

• DB_RO, DB_RW, DB_ADMIN

• Cluster_RO, Cluster_RW, Cluster_ADMIN

L'uso di questi gruppi di privilegi integrati può ridurre significativamente la complessità della progettazione dei permessi e migliorare la coerenza tra i ruoli.

È possibile utilizzare direttamente i gruppi di privilegi integrati o creare gruppi di privilegi personalizzati in base alle esigenze.

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

Assegnazione di privilegi o gruppi di privilegi ai ruoli

Dopo la creazione di un ruolo, è possibile assegnargli privilegi o gruppi di privilegi. Le risorse di destinazione per questi privilegi possono essere specificate a diversi livelli, tra cui l'istanza, il database o le singole Collezioni.

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

Assegnare i ruoli agli utenti

Una volta assegnati i ruoli a un utente, quest'ultimo può accedere alle risorse ed eseguire le operazioni definite da tali ruoli. A un singolo utente possono essere assegnati uno o più ruoli, a seconda dell'ambito di accesso richiesto.

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

4. Ispezione e revoca dell'accesso

Ispezione dei ruoli assegnati a un utente

client.describe_user(user_name="user_1")

Ispezione dei privilegi assegnati a un ruolo

client.describe_role(role_name="role_a")

Revoca dei privilegi di un ruolo

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

Revocare i ruoli a un utente

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

Eliminare utenti e ruoli

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

Esempio: Progettazione del controllo degli accessi per un sistema RAG alimentato da Milvus

Consideriamo un sistema RAG (Retrieval-Augmented Generation) costruito su Milvus.

In questo sistema, i diversi componenti e utenti hanno responsabilità chiaramente separate e ciascuno richiede un diverso livello di accesso.

Attore	Responsabilità	Accesso richiesto
Amministratore della piattaforma	Operazioni e configurazione del sistema	Amministrazione a livello di istanza
Servizio di ingestione vettoriale	Ingestione e aggiornamento dei dati vettoriali	Accesso in lettura e scrittura
Servizio di ricerca	Ricerca e recupero di vettori	Accesso in sola lettura

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

Suggerimenti rapidi: Come gestire il controllo degli accessi in modo sicuro in produzione

Per garantire che il controllo degli accessi rimanga efficace e gestibile nei sistemi di produzione a lungo termine, seguite queste linee guida pratiche.

1. Modificare la passwordpredefinita di root e limitare l'uso dell' account root.

Aggiornate la password predefinita di root subito dopo l'inizializzazione e limitatene l'uso alle sole attività amministrative. Evitate di usare o condividere l'account root per le operazioni di routine. Create invece utenti e ruoli dedicati per l'accesso quotidiano per ridurre i rischi e migliorare la responsabilità.

2. Isolare fisicamente le istanze Milvus da un ambiente all'altro

Distribuite istanze Milvus separate per lo sviluppo, lo staging e la produzione. L'isolamento fisico fornisce un confine di sicurezza più forte del solo controllo logico degli accessi e riduce significativamente il rischio di errori tra ambienti.

3. Seguire il principio del minimo privilegio

Concedete solo i permessi necessari per ogni ruolo:

• Ambienti di sviluppo: le autorizzazioni possono essere più permissive per supportare l'iterazione e i test.

• Ambienti di produzione: le autorizzazioni devono essere strettamente limitate allo stretto necessario.

• Verifiche regolari: riesaminare periodicamente i permessi esistenti per verificare che siano ancora necessari.

4. Revocare attivamente i permessi quando non sono più necessari.

Il controllo degli accessi non è un'impostazione una tantum, ma richiede una manutenzione continua. Revocate tempestivamente ruoli e privilegi quando cambiano gli utenti, i servizi o le responsabilità. In questo modo si evita che i permessi inutilizzati si accumulino nel tempo e diventino rischi nascosti per la sicurezza.

Conclusione

La configurazione del controllo degli accessi in Milvus non è intrinsecamente complessa, ma è essenziale per far funzionare il sistema in modo sicuro e affidabile in produzione. Con un modello RBAC ben progettato, è possibile:

• ridurre i rischi impedendo operazioni accidentali o distruttive

• Migliorare la sicurezza imponendo l'accesso con il minor numero di privilegi ai dati del vettore.

• standardizzare le operazioni attraverso una chiara separazione delle responsabilità

• Scalare con sicurezza, gettando le basi per implementazioni multi-tenant e su larga scala.

Il controllo degli accessi non è una funzione opzionale o un'attività una tantum. È una parte fondamentale del funzionamento sicuro di Milvus a lungo termine.

Iniziate a costruire una solida base di sicurezza con RBAC per la vostra implementazione Milvus.

Avete domande o volete un approfondimento su una qualsiasi funzione dell'ultimo Milvus? Unitevi al nostro canale Discord o inviate problemi su GitHub. È anche possibile prenotare una sessione individuale di 20 minuti per ottenere approfondimenti, indicazioni e risposte alle vostre domande tramite Milvus Office Hours.