Home
Blog
Milvus RBAC 解說：以角色為基礎的存取控制保護您的向量資料庫

Milvus RBAC 解說：以角色為基礎的存取控制保護您的向量資料庫

Tutorials

December 31, 2025

Juan Xu

在建立資料庫系統時，工程師會把大部分時間花在效能上：索引類型、召回、延遲、吞吐量和擴充。但是，一旦系統超越了單一開發人員的筆記型電腦，另一個問題就變得同樣重要：誰可以在您的 Milvus 集群中做什麼？換句話說，就是存取控制。

在整個產業中，許多作業事故都源自於簡單的權限錯誤。腳本在錯誤的環境中執行。服務帳戶擁有比預期更廣泛的存取權限。共用的管理員憑證最終出現在 CI 中。這些問題通常以非常實際的問題浮現：

是否允許開發人員刪除生產集合？
為什麼測試帳戶可以讀取生產向量資料？
為什麼多個服務使用相同的管理員角色登入？
分析工作是否可以擁有唯讀存取權限，而寫入權限為零？

Milvus 以基於角色的存取控制 (RBAC) 來解決這些挑戰。RBAC 讓您可以在資料庫層定義精確的權限，而不是賦予每個使用者超級管理員的權限或試圖在應用程式碼中強制執行限制。每個使用者或服務都能獲得所需的功能，僅此而已。

這篇文章將解釋 RBAC 在 Milvus 中的工作原理、如何配置它，以及如何在生產環境中安全地應用它。

為什麼使用 Milvus 時存取控制很重要？

當團隊規模較小，而且他們的 AI 應用程式只服務有限數量的使用者時，基礎架構通常很簡單。由幾位工程師管理系統；Milvus 僅用於開發或測試；操作工作流程簡單直接。在這個早期階段，存取控制很少會讓人感到緊迫，因為風險面很小，而且任何錯誤都很容易逆轉。

隨著 Milvus 進入生產階段，使用者、服務和操作員的數量不斷增加，使用模式也迅速改變。常見的情況包括

多個業務系統共享同一個 Milvus 實例
多個團隊存取相同的向量集合
測試、暫存與生產資料共存於單一叢集
不同角色需要不同層級的存取權限，從唯讀查詢到寫入與作業控制。

如果沒有明確界定的存取邊界，這些設定就會產生可預見的風險：

測試工作流程可能會意外刪除生產資料集
開發人員可能會無意中修改即時服務所使用的索引
root 帳戶的廣泛使用，使得無法追蹤或稽核動作
受到攻擊的應用程式可能會不受限制地存取所有向量資料

隨著使用量的增加，依賴非正式的慣例或共用的管理帳戶已無法持續下去。一個一致的、可強制執行的存取模型變得非常重要，而這正是 Milvus RBAC 所提供的。

什麼是 Milvus 的 RBAC

RBAC (基於角色的存取控制)是一種權限模型，根據角色而非個別使用者來控制存取。在 Milvus 中，RBAC 可讓您精確定義允許使用者或服務執行哪些作業，以及哪些特定資源。當您的系統從單一開發者成長為完整的生產環境時，它提供了一種結構化、可擴展的安全管理方式。

Milvus RBAC 圍繞以下核心元件建立：

Users Roles Privileges 使用者角色特權

資源：被存取的實體。在 Milvus 中，資源包括實例、資料庫和集合。
權限：資源上允許的特定操作 - 例如，建立資料集、插入資料或刪除實體。
特權群組：一組預先定義的相關權限，例如「唯讀」或「寫入」。
角色：特權及其適用資源的組合。角色決定哪些操作可以執行，以及在何處執行。
使用者：Milvus 中的一個身份。每個使用者都有一個唯一的 ID，並被指派一個或多個角色。

這些元件形成一個明確的層級結構：

使用者被指派角色
角色定義權限
權限適用於特定資源

Milvus 的一個關鍵設計原則是，權限從不直接分配給用戶。所有的存取都是透過角色進行。這種間接方式簡化了管理，減少了設定錯誤，並使權限變更具有可預測性。

在實際部署中，此模型可順利擴充。當多個使用者共用一個角色時，更新角色的權限會立即更新所有使用者的權限，而無需個別修改每個使用者。這是符合現代基礎架構管理存取方式的單點控制。

RBAC 如何在 Milvus 中運作

當用戶端向 Milvus 發送請求時，系統會通過一系列授權步驟進行評估。每個步驟都必須通過，才允許繼續操作：

How RBAC Works in Milvus RBAC 如何在 Milvus 工作

驗證請求：Milvus 首先驗證使用者身份。如果驗證失敗，請求會以驗證錯誤被拒絕。
檢查角色分配：驗證之後，Milvus 檢查使用者是否至少有一個角色分配。如果找不到角色，請求會以權限被拒絕的錯誤被拒絕。
驗證所需權限：Milvus 會評估使用者的角色是否賦予目標資源所需的權限。如果權限檢查失敗，請求會以權限被拒絕的錯誤被拒絕。
執行操作：如果所有檢查都通過，Milvus 執行請求的操作並傳回結果。

如何在 Milvus 中通過 RBAC 配置存取控制

1.先決條件

在評估和執行 RBAC 規則之前，必須啟用使用者驗證，以便 Milvus 的每個請求都能與特定使用者身分相關聯。

以下是兩種標準的部署方法。

使用 Docker Compose 部署

如果使用 Docker Compose 部署 Milvus，請編輯milvus.yaml 配置檔案，並透過設定common.security.authorizationEnabled 至true 來啟用授權：

common:
  security:
    authorizationEnabled: true

使用 Helm Charts 部署

如果 Milvus 是使用 Helm Charts 部署的，請編輯values.yaml 檔案，並在extraConfigFiles.user.yaml 下新增下列設定： 1：

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

2.初始化

預設情況下，Milvus 會在系統啟動時建立一個內建的root 使用者。這個使用者的預設密碼是Milvus 。

作為初始安全步驟，使用root 用戶連接 Milvus，並立即更改預設密碼。強烈建議使用複雜的密碼，以防止未經授權的存取。

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.核心操作

建立使用者

對於日常使用，建議創建專用用戶，而不是使用root 帳戶。

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

建立角色

Milvus 提供內建的admin 角色，具有完整的管理權限。然而，對於大多數生產方案，建議建立自訂角色，以達到更精細的存取控制。

client.create_role(role_name="role_a")

建立特權群組

權限群組是多個權限的集合。為了簡化權限管理，可以將相關的權限分組並一起授予。

Milvus 包括以下內建的特權群組：

COLL_RO,COLL_RW 、COLL_ADMIN
DB_RO,DB_RW 、DB_ADMIN
Cluster_RO,Cluster_RW 、Cluster_ADMIN

使用這些內建的權限群組可大幅降低權限設計的複雜性，並改善不同角色間的一致性。

您可以直接使用內建的權限群組，或依需要建立自訂的權限群組。

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

授予角色權限或權限群組

建立角色後，就可以將權限或權限群組授予角色。這些特權的目標資源可以在不同層級指定，包括實例、資料庫或個別集合。

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

授予使用者角色

一旦將角色指派給使用者，使用者就可以存取資源，並執行這些角色所定義的操作。根據所需的存取範圍，單一使用者可被授予一個或多個角色。

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

4.檢查和撤銷存取權限

檢查指定給使用者的角色

client.describe_user(user_name="user_1")

檢查指定給角色的權限

client.describe_role(role_name="role_a")

從角色撤銷權限

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

從使用者撤銷角色

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

刪除使用者和角色

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

範例：Milvus驅動的RAG系統的存取控制設計

考慮一個建立在 Milvus 上的 Retrieval-Augmented Generation (RAG) 系統。

在這個系統中，不同的元件和使用者有清楚區分的責任，而且每個元件和使用者都需要不同等級的存取權限。

角色	責任	所需存取權限
平台管理員	系統作業與組態	實體層級管理
向量擷取服務	向量資料擷取與更新	讀寫存取
搜尋服務	向量搜尋與檢索	唯讀存取

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