Guia de Controlo de Acesso Milvus: Como configurar o RBAC para produção

Eis uma história que é mais comum do que deveria ser: um engenheiro de controlo de qualidade executa um script de limpeza no que pensa ser o ambiente de teste. Exceto que a cadeia de ligação aponta para a produção. Poucos segundos depois, as colecções de vectores principais desapareceram - dados de caraterísticas perdidos, pesquisa de semelhanças com resultados vazios, degradação dos serviços em geral. O postmortem encontra a mesma causa raiz de sempre: todos estavam a ligar-se como root, não havia limites de acesso e nada impedia que uma conta de teste deixasse cair dados de produção.

Isto não é um caso isolado. As equipas que constroem em Milvus - e as bases de dados vectoriais em geral - tendem a concentrar-se no desempenho do índice, na taxa de transferência e na escala de dados, tratando o controlo de acesso como algo a tratar mais tarde. Mas "mais tarde" geralmente chega na forma de um incidente. À medida que o Milvus passa de protótipo a espinha dorsal dos pipelines RAG de produção, dos motores de recomendação e da pesquisa vetorial em tempo real, a questão torna-se inevitável: quem pode aceder ao seu cluster Milvus e o que é que pode fazer exatamente?

O Milvus inclui um sistema RBAC incorporado para responder a essa pergunta. Este guia cobre o que é o RBAC, como o Milvus o implementa e como conceber um modelo de controlo de acesso que mantenha a produção segura - completo com exemplos de código e um passo-a-passo completo do sistema RAG.

O que é o RBAC (Controlo de Acesso Baseado em Funções)?

O Controlo de Acesso Baseado em Funções (RBAC) é um modelo de segurança em que as permissões não são atribuídas diretamente a utilizadores individuais. Em vez disso, as permissões são agrupadas em funções e aos utilizadores são atribuídas uma ou mais funções. O acesso efetivo de um utilizador é a união de todas as permissões das suas funções atribuídas. O RBAC é o modelo de controlo de acesso padrão nos sistemas de bases de dados de produção - PostgreSQL, MySQL, MongoDB e a maioria dos serviços em nuvem utilizam-no.

O RBAC resolve um problema de escala fundamental: quando se tem dezenas de utilizadores e serviços, a gestão de permissões por utilizador torna-se impossível de manter. Com o RBAC, define-se uma função uma vez (por exemplo, "apenas leitura na coleção X"), atribui-se a dez serviços e actualiza-se num único local quando os requisitos mudam.

Como é que o Milvus implementa o RBAC?

Milvus RBAC baseia-se em quatro conceitos:

Conceito	O que é	Exemplo
Recurso	O que está a ser acedido	Uma instância Milvus, uma base de dados ou uma coleção específica
Privilégio / Grupo de privilégios	A ação que está a ser executada	Search, Insert, DropCollection, ou um grupo como COLL_RO (coleção só de leitura)
Função	Um conjunto nomeado de privilégios com escopo para recursos	role_read_onlyUtilizador: pode pesquisar e consultar todas as colecções na base de dados default
Utilizador	Uma conta Milvus (humana ou de serviço)	rag_writerConta de serviço utilizada pelo pipeline de ingestão

O acesso nunca é atribuído diretamente aos utilizadores. Os utilizadores obtêm papéis, os papéis contêm privilégios e os privilégios são atribuídos a recursos. Este é o mesmo modelo RBAC utilizado na maioria dos sistemas de bases de dados de produção. Se dez utilizadores partilham o mesmo papel, actualiza-se o papel uma vez e a alteração aplica-se a todos eles.

O modelo RBAC do Milvus mostra como os utilizadores são atribuídos a funções, e as funções contêm privilégios e grupos de privilégios que se aplicam aos recursos

Quando um pedido chega ao Milvus, passa por três verificações:

1. Autenticação - este é um utilizador válido com as credenciais corretas?
2. Verificaçãoda função - este utilizador tem pelo menos uma função atribuída?
3. Verificaçãode privilégios - alguma das funções do utilizador concede a ação solicitada no recurso solicitado?

Se alguma das verificações falhar, o pedido é rejeitado.

Fluxo de autenticação e autorização do Milvus: O pedido do cliente passa pela autenticação, verificação de função e verificação de privilégios - rejeitado em qualquer passo que falhe, executado apenas se todos forem aprovados

Como habilitar a autenticação no Milvus

Por defeito, o Milvus funciona com a autenticação desactivada - todas as ligações têm acesso total. O primeiro passo é ativá-la.

Docker Compose

Edite milvus.yaml e defina authorizationEnabled como true:

common:
  security:
    authorizationEnabled: true

Gráficos do Helm

Editar values.yaml e adicionar a definição em extraConfigFiles:

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

Para implantações do Milvus Operator no Kubernetes, a mesma configuração vai para a seção spec.config do Milvus CR.

Depois que a autenticação é ativada e o Milvus é reiniciado, todas as conexões devem fornecer credenciais. O Milvus cria um usuário padrão root com a senha Milvus - altere isso imediatamente.

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

Como configurar utilizadores, funções e privilégios

Com a autenticação activada, eis o fluxo de trabalho de configuração típico.

Etapa 1: criar usuários

Não deixe que os serviços ou membros da equipa utilizem root. Crie contas dedicadas para cada utilizador ou serviço.

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

Passo 2: Criar funções

O Milvus tem uma função incorporada admin, mas na prática vai querer funções personalizadas que correspondam aos seus padrões de acesso reais.

client.create_role(role_name="role_a")

Passo 3: Criar grupos de privilégios

Um grupo de privilégios agrupa vários privilégios sob um nome, facilitando a gestão do acesso em escala. Milvus fornece 9 grupos de privilégios embutidos:

Grupo incorporado	Escopo	O que ele permite
COLL_RO	Coleção	Operações só de leitura (consulta, pesquisa, etc.)
COLL_RW	Coleção	Operações de leitura e escrita
COLL_Admin	Coleção	Gestão completa da coleção
DB_RO	Base de dados	Operações de base de dados só de leitura
DB_RW	Base de dados	Operações de leitura e escrita na base de dados
DB_Admin	Base de dados	Gestão completa da base de dados
Cluster_RO	Cluster	Operações de cluster só de leitura
Cluster_RW	Cluster	Operações de cluster de leitura e escrita
Cluster_Admin	Cluster	Gerenciamento completo do cluster

Também pode criar grupos de privilégios personalizados quando os grupos incorporados não se adequarem:

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

Etapa 4: conceder privilégios a uma função

Conceda privilégios individuais ou grupos de privilégios a uma função, com escopo para recursos específicos. Os parâmetros collection_name e db_name controlam o âmbito - utilize * 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='',
)

Passo 5: Atribuir funções aos utilizadores

Um utilizador pode ter várias funções. As suas permissões efectivas são a união de todas as funções atribuídas.

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

Como auditar e revogar o acesso

Saber que tipo de acesso existe é tão importante como concedê-lo. As permissões obsoletas - de antigos membros da equipa, serviços retirados ou sessões de depuração pontuais - acumulam-se silenciosamente e alargam a superfície de ataque.

Verificar as permissões actuais

Ver as funções atribuídas a um utilizador:

client.describe_user(user_name="user_1")

Ver os privilégios concedidos a uma função:

client.describe_role(role_name="role_a")

Revogar privilégios de uma função

# 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 a atribuição de uma função a um utilizador

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

Eliminar utilizadores ou funções

Remova todas as atribuições de funções antes de eliminar um utilizador e revogue todos os privilégios antes de eliminar uma função:

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

Exemplo: Como conceber RBAC para um sistema RAG de produção

Os conceitos abstractos tornam-se mais fáceis de entender com um exemplo concreto. Considere um sistema RAG construído em Milvus com três serviços distintos:

Serviço	Responsabilidade	Acesso necessário
Administrador da plataforma	Gere o cluster Milvus - cria colecções, monitoriza a saúde, trata das actualizações	Administrador completo do cluster
Serviço de ingestão	Gera embeddings vectoriais a partir de documentos e escreve-os em colecções	Leitura + escrita nas colecções
Serviço de pesquisa	Trata as consultas de pesquisa vetorial dos utilizadores finais	Só de leitura nas colecções

Aqui está uma configuração 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 serviço obtém exatamente o acesso de que necessita. O serviço de pesquisa não pode apagar dados acidentalmente. O serviço de ingestão não pode modificar as configurações do cluster. E se as credenciais do serviço de pesquisa vazarem, o invasor poderá ler os vetores de incorporação, mas não poderá escrever, excluir ou passar para administrador.

Para as equipas que gerem o acesso em várias implementações Milvus, o Zilliz Cloud (Milvus gerido) fornece RBAC integrado com uma consola Web para gerir utilizadores, funções e permissões - sem necessidade de scripts. Útil quando se prefere gerir o acesso através de uma interface de utilizador em vez de manter scripts de configuração em todos os ambientes.

Melhores práticas de controlo de acesso para produção

As etapas de configuração acima são a mecânica. Aqui estão os princípios de design que mantêm o controlo de acesso eficaz ao longo do tempo.

Bloquear a conta raiz

Altere a senha padrão root antes de qualquer outra coisa. Na produção, a conta raiz deve ser usada apenas para operações de emergência e armazenada em um gerenciador de segredos - não codificada em configurações de aplicativos ou compartilhada pelo Slack.

Separe completamente os ambientes

Use diferentes instâncias Milvus para desenvolvimento, preparação e produção. A separação de ambientes apenas por RBAC é frágil - uma string de conexão mal configurada e um serviço de desenvolvimento está escrevendo em dados de produção. A separação física (clusters diferentes, credenciais diferentes) elimina completamente esta classe de incidentes.

Aplique o privilégio mínimo

Dê a cada utilizador e serviço o acesso mínimo necessário para fazer o seu trabalho. Comece com um acesso restrito e alargue-o apenas quando houver uma necessidade específica e documentada. Em ambientes de desenvolvimento, pode ser mais relaxado, mas o acesso à produção deve ser rigoroso e revisto regularmente.

Limpar o acesso obsoleto

Quando alguém deixa a equipa ou um serviço é desativado, revogue as suas funções e elimine as suas contas imediatamente. As contas não utilizadas com permissões activas são o vetor mais comum de acesso não autorizado - são credenciais válidas que ninguém está a monitorizar.

Atribuir privilégios a colecções específicas

Evite conceder collection_name='*' a menos que a função necessite realmente de acesso a todas as colecções. Em configurações de vários inquilinos ou sistemas com vários pipelines de dados, defina o escopo de cada função apenas para as coleções em que ela opera. Isto limita o raio de ação se as credenciais forem comprometidas.

---

Se estiver a implementar o Milvus em produção e a trabalhar no controlo de acesso, segurança ou design multi-tenant, gostaríamos de ajudar:

• Junte-se à comunidade Milvus Slack para discutir práticas reais de implantação com outros engenheiros que executam Milvus em escala.
• Reserve uma sessão gratuita de 20 minutos do Milvus Office Hours para percorrer o seu design RBAC - quer se trate de estrutura de funções, escopo de nível de coleção ou segurança multi-ambiente.
• Se preferir ignorar a configuração da infraestrutura e gerir o controlo de acesso através de uma interface de utilizador, o Zilliz Cloud (Milvus gerido) inclui RBAC incorporado com uma consola Web - além de encriptação, isolamento de rede e conformidade SOC 2 imediata.

---

Algumas questões que surgem quando as equipas começam a configurar o controlo de acesso no Milvus:

P: Posso restringir o acesso de um utilizador apenas a colecções específicas e não a todas?

Sim. Quando chama grant_privilege_v2defina collection_name para a coleção específica em vez de *. A função do utilizador só terá acesso a essa coleção. Pode conceder privilégios à mesma função em várias colecções chamando a função uma vez por coleção.

P: Qual é a diferença entre um privilégio e um grupo de privilégios no Milvus?

Um privilégio é uma ação única como Search, Insert, ou DropCollection. Um grupo de privilégios agrupa vários privilégios sob um nome - por exemplo, COLL_RO inclui todas as operações de coleção só de leitura. Conceder um grupo de privilégios é funcionalmente o mesmo que conceder cada um dos seus privilégios constituintes individualmente, mas é mais fácil de gerir.

P: A ativação da autenticação afecta o desempenho das consultas Milvus?

A sobrecarga é insignificante. O Milvus valida as credenciais e verifica as permissões de função em cada pedido, mas trata-se de uma pesquisa na memória - acrescenta microssegundos, não milissegundos. Não há impacto mensurável na latência de pesquisa ou inserção.

P: Posso usar o Milvus RBAC numa configuração multi-tenant?

Sim. Crie funções separadas por inquilino, defina o âmbito dos privilégios de cada função para as colecções desse inquilino e atribua a função correspondente à conta de serviço de cada inquilino. Isto dá-lhe um isolamento ao nível da coleção sem necessitar de instâncias Milvus separadas. Para multi-tenancy em larga escala, veja o guia multi-tenancy do Milvus.