Explicação do Milvus RBAC: Proteja a sua base de dados Vetorial com o Controlo de Acesso Baseado em Funções

Quando se constrói um sistema de base de dados, os engenheiros passam a maior parte do tempo no desempenho: tipos de índices, recuperação, latência, taxa de transferência e escalonamento. Mas quando um sistema vai além do laptop de um único desenvolvedor, outra questão torna-se igualmente crítica: quem pode fazer o quê dentro do seu cluster Milvus? Por outras palavras - controlo de acesso.

Em toda a indústria, muitos incidentes operacionais resultam de simples erros de permissão. Um script é executado no ambiente errado. Uma conta de serviço tem um acesso mais alargado do que o pretendido. Uma credencial de administrador partilhada acaba na CI. Esses problemas geralmente surgem como questões muito práticas:

• Os programadores têm permissão para eliminar colecções de produção?

• Porque é que uma conta de teste pode ler os dados do vetor de produção?

• Porque é que vários serviços estão a iniciar sessão com a mesma função de administrador?

• Os trabalhos de análise podem ter acesso apenas de leitura com zero privilégios de escrita?

O Milvus resolve estes desafios com o controlo de acesso baseado em funções (RBAC). Em vez de dar a cada utilizador direitos de superadministrador ou tentar impor restrições no código da aplicação, o RBAC permite-lhe definir permissões precisas na camada da base de dados. Cada utilizador ou serviço obtém exatamente as capacidades de que necessita - nada mais.

Este post explica como o RBAC funciona no Milvus, como configurá-lo e como aplicá-lo com segurança em ambientes de produção.

Porque é que o controlo de acesso é importante quando se usa Milvus

Quando as equipas são pequenas e as suas aplicações de IA servem apenas um número limitado de utilizadores, a infraestrutura é normalmente simples. Alguns engenheiros gerem o sistema; o Milvus é utilizado apenas para desenvolvimento ou testes; e os fluxos de trabalho operacionais são simples. Nesta fase inicial, o controlo de acesso raramente parece urgente - porque a superfície de risco é pequena e quaisquer erros podem ser facilmente revertidos.

À medida que o Milvus entra em produção e o número de utilizadores, serviços e operadores aumenta, o modelo de utilização muda rapidamente. Cenários comuns incluem:

• Múltiplos sistemas empresariais que partilham a mesma instância do Milvus

• Múltiplas equipas a aceder às mesmas colecções de vectores

• Dados de teste, preparação e produção coexistindo num único cluster

• Diferentes funções que necessitam de diferentes níveis de acesso, desde consultas apenas de leitura a gravações e controlo operacional

Sem limites de acesso bem definidos, essas configurações criam riscos previsíveis:

• Os fluxos de trabalho de teste podem eliminar acidentalmente colecções de produção

• Os programadores podem modificar involuntariamente os índices utilizados pelos serviços em funcionamento

• A utilização generalizada da conta root torna as acções impossíveis de rastrear ou auditar

• Uma aplicação comprometida pode obter acesso ilimitado a todos os dados do vetor

À medida que a utilização aumenta, confiar em convenções informais ou em contas de administrador partilhadas deixa de ser sustentável. Um modelo de acesso consistente e aplicável torna-se essencial - e é exatamente isso que o RBAC Milvus proporciona.

O que é o RBAC em Milvus

O RBAC (Role-Based Access Control) é um modelo de permissão que controla o acesso com base em funções e não em utilizadores individuais. Em Milvus, o RBAC permite-lhe definir exatamente quais as operações que um utilizador ou serviço está autorizado a realizar - e em que recursos específicos. Ele fornece uma maneira estruturada e escalável de gerenciar a segurança à medida que seu sistema cresce de um único desenvolvedor para um ambiente de produção completo.

O Milvus RBAC é construído em torno dos seguintes componentes principais:

Utilizadores Funções Privilégios

• Recurso: A entidade que está a ser acedida. No Milvus, os recursos incluem a instância, a base de dados e a coleção.

• Privilégio: Uma operação específica permitida em um recurso - por exemplo, criar uma coleção, inserir dados ou excluir entidades.

• Grupo de privilégios: Um conjunto predefinido de privilégios relacionados, como "somente leitura" ou "gravação".

• Função: Uma combinação de privilégios e os recursos aos quais eles se aplicam. Uma função determina quais as operações que podem ser efectuadas e onde.

• Utilizador: uma identidade no Milvus. Cada utilizador tem um ID único e é-lhe atribuída uma ou mais funções.

Estes componentes formam uma hierarquia clara:

1. Aos utilizadores são atribuídas funções

2. As funções definem os privilégios

3. Os privilégios aplicam-se a recursos específicos

Um princípio de conceção chave no Milvus é que as permissões nunca são atribuídas diretamente aos utilizadores. Todo o acesso passa por funções. Esta indirecção simplifica a administração, reduz os erros de configuração e torna as alterações de permissões previsíveis.

Este modelo é escalável em implementações reais. Quando vários utilizadores partilham uma função, a atualização dos privilégios da função actualiza instantaneamente as permissões para todos eles - sem modificar cada utilizador individualmente. É um ponto único de controlo alinhado com a forma como as infra-estruturas modernas gerem o acesso.

Como funciona o RBAC no Milvus

Quando um cliente envia um pedido ao Milvus, o sistema avalia-o através de uma série de passos de autorização. Cada etapa deve ser aprovada antes que a operação seja autorizada a prosseguir:

Como funciona o RBAC em Milvus

1. Autenticar o pedido: Milvus verifica primeiro a identidade do utilizador. Se a autenticação falhar, o pedido é rejeitado com um erro de autenticação.

2. Verificar a atribuição de funções: Após a autenticação, o Milvus verifica se o utilizador tem pelo menos uma função atribuída. Se não for encontrada nenhuma função, o pedido é rejeitado com um erro de permissão negada.

3. Verificar os privilégios necessários: O Milvus avalia se a função do utilizador concede o privilégio necessário no recurso alvo. Se a verificação de privilégios falhar, o pedido é rejeitado com um erro de permissão negada.

4. Executar a operação: Se todas as verificações forem aprovadas, o Milvus executa a operação solicitada e devolve o resultado.

Como configurar o controlo de acesso via RBAC no Milvus

1. Pré-requisitos

Antes que as regras do RBAC possam ser avaliadas e aplicadas, a autenticação do usuário deve ser ativada para que cada solicitação ao Milvus possa ser associada a uma identidade de usuário específica.

Aqui estão dois métodos de implantação padrão.

• Implantação com o Docker Compose

Se o Milvus for implantado usando o Docker Compose, edite o arquivo de configuração milvus.yaml e habilite a autorização definindo common.security.authorizationEnabled para true:

common:
  security:
    authorizationEnabled: true

• Implantação com Helm Charts

Se o Milvus for implementado com Helm Charts, edite o ficheiro values.yaml e adicione a seguinte configuração em extraConfigFiles.user.yaml:

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

2. Inicialização

Por defeito, o Milvus cria um utilizador root integrado quando o sistema é iniciado. A palavra-passe predefinida para este utilizador é Milvus.

Como passo inicial de segurança, utilize o utilizador root para se ligar ao Milvus e altere imediatamente a palavra-passe predefinida. Recomenda-se vivamente a utilização de uma palavra-passe complexa para evitar o acesso não autorizado.

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. Operações principais

Criar utilizadores

Para uma utilização diária, recomenda-se a criação de utilizadores dedicados em vez de utilizar a conta root.

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

Criar funções

O Milvus fornece uma função incorporada admin com todos os privilégios administrativos. No entanto, para a maior parte dos cenários de produção, recomenda-se a criação de funções personalizadas para obter um controlo de acesso mais rigoroso.

client.create_role(role_name="role_a")

Criar grupos de privilégios

Um grupo de privilégios é uma coleção de vários privilégios. Para simplificar a gestão de permissões, os privilégios relacionados podem ser agrupados e concedidos em conjunto.

O Milvus inclui os seguintes grupos de privilégios incorporados:

• COLL_RO, COLL_RW, COLL_ADMIN

• DB_RO, DB_RW, DB_ADMIN

• Cluster_RO, Cluster_RW, Cluster_ADMIN

A utilização destes grupos de privilégios integrados pode reduzir significativamente a complexidade da conceção de permissões e melhorar a consistência entre funções.

Pode utilizar diretamente os grupos de privilégios incorporados ou criar grupos de privilégios personalizados, conforme necessário.

# 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 privilégios ou grupos de privilégios a funções

Depois que uma função é criada, os privilégios ou grupos de privilégios podem ser concedidos à função. Os recursos de destino para esses privilégios podem ser especificados em diferentes níveis, incluindo a instância, o banco de dados ou as Coleções individuais.

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

Conceder funções aos utilizadores

Assim que as funções são atribuídas a um utilizador, este pode aceder a recursos e executar as operações definidas por essas funções. A um único utilizador podem ser atribuídas uma ou várias funções, dependendo do âmbito de acesso necessário.

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

4. Inspecionar e revogar o acesso

Inspecionar funções atribuídas a um utilizador

client.describe_user(user_name="user_1")

Inspecionar os privilégios atribuídos a uma função

client.describe_role(role_name="role_a")

Revogar privilégios de uma função

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

Revogar funções de um utilizador

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

Eliminar utilizadores e funções

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

Exemplo: Conceção do controlo de acesso para um sistema RAG alimentado por Milvus

Considere um sistema RAG (Retrieval-Augmented Generation) construído sobre o Milvus.

Neste sistema, diferentes componentes e utilizadores têm responsabilidades claramente separadas, e cada um requer um nível de acesso diferente.

Agente	Responsabilidade	Acesso necessário
Administrador da plataforma	Operações e configuração do sistema	Administração ao nível da instância
Serviço de ingestão de vectores	Ingestão e atualização de dados vectoriais	Acesso de leitura e escrita
Serviço de pesquisa	Pesquisa e recuperação de vectores	Acesso apenas de leitura

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

Dicas rápidas: Como operar o controlo de acesso de forma segura na produção

Para garantir que o controlo de acesso se mantém eficaz e gerível em sistemas de produção de longa duração, siga estas orientações práticas.

1. Altere a palavra-passepredefinida root e limite a utilização da conta root

Actualize a palavra-passe predefinida root imediatamente após a inicialização e restrinja a sua utilização apenas a tarefas administrativas. Evite usar ou compartilhar a conta root para operações de rotina. Em vez disso, crie utilizadores e funções dedicados para o acesso diário para reduzir o risco e melhorar a responsabilidade.

2. Isolar fisicamente as instâncias do Milvus entre ambientes

Implemente instâncias separadas do Milvus para desenvolvimento, preparação e produção. O isolamento físico proporciona um limite de segurança mais forte do que o controlo de acesso lógico por si só e reduz significativamente o risco de erros entre ambientes.

3. Siga o princípio do menor privilégio

Conceda apenas as permissões necessárias para cada função:

• Ambientes de desenvolvimento: as permissões podem ser mais permissivas para apoiar a iteração e os testes

• Ambientes de produção: as permissões devem ser estritamente limitadas ao que é necessário

• Auditorias regulares: rever periodicamente as permissões existentes para garantir que ainda são necessárias

4. Revogar ativamente as permissões quando já não são necessárias

O controlo de acesso não é uma configuração única - requer uma manutenção contínua. Revogue funções e privilégios prontamente quando os utilizadores, serviços ou responsabilidades mudam. Isto evita que as permissões não utilizadas se acumulem ao longo do tempo e se tornem riscos de segurança ocultos.

Conclusão

A configuração do controlo de acesso no Milvus não é intrinsecamente complexa, mas é essencial para operar o sistema de forma segura e fiável em produção. Com um modelo RBAC bem concebido, é possível:

• Reduzir o risco ao evitar operações acidentais ou destrutivas

• Melhorar a segurança, impondo o acesso de menor privilégio aos dados do vetor

• Padronizar as operações através de uma separação clara de responsabilidades

• Escalar com confiança, estabelecendo as bases para implantações multilocatário e em grande escala

O controlo de acesso não é uma funcionalidade opcional ou uma tarefa pontual. É uma parte fundamental do funcionamento seguro do Milvus a longo prazo.

Comece a criar uma base de segurança sólida com o RBAC para a sua implementação do Milvus.

Tem perguntas ou quer um mergulho profundo em qualquer caraterística do último Milvus? Junte-se ao nosso canal Discord ou arquive problemas no GitHub. Também pode reservar uma sessão individual de 20 minutos para obter informações, orientações e respostas às suas perguntas através do Milvus Office Hours.