Home
Blog
Milvus RBACの説明：役割ベースのアクセス制御でベクターデータベースを保護する

Milvus RBACの説明：役割ベースのアクセス制御でベクターデータベースを保護する

Tutorials

December 31, 2025

Juan Xu

データベースシステムを構築する際、エンジニアはインデックスタイプ、リコール、レイテンシ、スループット、スケーリングなどのパフォーマンスにほとんどの時間を費やします。しかし、システムが一人の開発者のラップトップの域を超えると、もう一つの問題が重要になってきます。つまり、アクセス制御である。

業界全体において、運用上のインシデントの多くは単純なパーミッションのミスに起因している。スクリプトが間違った環境に対して実行される。サービスアカウントが意図した以上のアクセス権を持っている。共有された管理者クレデンシャルがCIに入ってしまう。これらの問題は通常、非常に現実的な問題として表面化する：

開発者が本番環境のコレクションを削除することは許されるのか？
なぜテストアカウントが本番環境のベクターデータを読めるのか？
なぜ複数のサービスが同じadminロールでログインしているのか？
分析ジョブは書き込み権限ゼロで読み取り専用アクセスできるのか？

Milvusはロールベースのアクセスコントロール(RBAC)でこれらの課題に対処します。すべてのユーザにスーパーアドミニストレータの権限を与えたり、アプリケーションコードで制限を強制したりする代わりに、RBAC ではデータベースレイヤで正確な権限を定義できます。各ユーザーやサービスは、必要な機能だけを得ることができます。

この投稿では、MilvusにおけるRBACの仕組み、設定方法、本番環境で安全に適用する方法について説明します。

Milvusを使用する際にアクセス制御が重要な理由

チームが小規模で、AIアプリケーションが限られたユーザー数しか対応していない場合、インフラストラクチャは通常シンプルになります。少数のエンジニアがシステムを管理し、Milvusは開発またはテストにのみ使用され、運用ワークフローは単純です。このような初期段階では、アクセス・コントロールに緊急性を感じることはほとんどない。なぜなら、リスク面が小さく、どんなミスも簡単に取り返せるからだ。

Milvusが本番稼動に移行し、ユーザー数、サービス数、オペレータ数が増加するにつれ、利用モデルは急速に変化する。よくあるシナリオは以下の通りである：

複数の業務システムが同じMilvusインスタンスを共有する。
複数のチームが同じベクターコレクションにアクセス
テストデータ、ステージングデータ、本番データが単一のクラスタに共存する場合
読み取り専用クエリから書き込み、運用管理まで、異なるレベルのアクセスを必要とする役割の違い

アクセス境界が明確に定義されていないと、このようなセットアップでは予測可能なリスクが生じます：

テストワークフローが誤って本番環境のコレクションを削除する可能性がある
開発者が本番サービスで使用されるインデックスを意図せずに変更する可能性がある。
root アカウントの広範な使用により、アクションの追跡や監査が不可能になる。
侵害されたアプリケーションがすべてのベクターデータに無制限にアクセスする可能性がある

利用が拡大するにつれ、非公式な慣習や共有管理者アカウントに依存することはもはや持続不可能になる。一貫性のある、強制可能なアクセスモデルが不可欠となり、これこそがMilvus RBACが提供するものです。

MilvusのRBACとは？

RBAC(Role-Based Access Control)とは、個々のユーザではなくロールに基づいてアクセスを制御する権限モデルです。MilvusのRBACでは、ユーザやサービスがどのリソースに対してどのような操作を行うことができるかを正確に定義することができます。これは、システムが一人の開発者から完全な本番環境へと成長するにつれて、セキュリティを管理するための構造化されたスケーラブルな方法を提供します。

Milvus RBACは以下のコアコンポーネントを中心に構築されています：

Users Roles Privileges ユーザーロール特権

リソース：アクセスされるエンティティ。Milvusでは、リソースにはインスタンス、データベース、コレクションが含まれます。
特権：例えば、コレクションの作成、データの挿入、エンティティの削除など。
特権グループ：例えば、コレクションの作成、データの挿入、エンティティの削除など。
役割：権限とそれが適用されるリソースの組み合わせ。ロールにより、どのような操作をどこで実行できるかが決定される。
ユーザ(User): MilvusにおけるID。各ユーザは一意のIDを持ち、1つ以上のロールが割り当てられる。

これらの構成要素は明確な階層を形成しています：

ユーザにはロールが割り当てられます。
ロールは権限を定義する。
権限は特定のリソースに適用される

Milvusの重要な設計原則は、権限をユーザーに直接割り当てないことです。すべてのアクセスはロールを経由します。この間接性により、管理が簡素化され、設定ミスが減り、権限の変更が予測可能になります。

このモデルは、実際のデプロイメントにおいてきれいにスケールします。複数のユーザがロールを共有する場合、ロールの権限を更新すると、各ユーザを個別に変更することなく、すべてのユーザの権限が即座に更新されます。これは、最新のインフラストラクチャがアクセスを管理する方法に沿った単一制御ポイントです。

MilvusにおけるRBACの仕組み

クライアントがMilvusにリクエストを送信すると、システムは一連の権限付与ステップを通じてそのリクエストを評価します。各ステップは、操作の続行が許可される前に通過する必要があります：

How RBAC Works in Milvus MilvusにおけるRBACの仕組み

リクエストの認証：Milvusはまずユーザーの身元を確認します。認証に失敗した場合、リクエストは認証エラーとして拒否されます。
役割の割り当てを確認します：認証後、Milvusはユーザに少なくとも1つのロールが割り当てられているかどうかをチェックします。ロールが見つからない場合、リクエストは permission denied エラーで拒否されます。
必要な権限を確認します：Milvusは次に、ユーザのロールがターゲットリソース上で必要な権限を付与しているかどうかを評価します。権限のチェックに失敗した場合、リクエストはpermission deniedエラーで拒否されます。
操作を実行します：すべてのチェックに合格した場合、Milvusは要求された操作を実行し、結果を返します。

MilvusにおけるRBACによるアクセス制御の設定方法

1.前提条件

RBACルールの評価と適用を行う前に、Milvusへのすべてのリクエストを特定のユーザIDに関連付けることができるように、ユーザ認証を有効にする必要があります。

ここでは2つの標準的なデプロイ方法を紹介します。

Docker Composeによるデプロイ

Docker Composeを使用してMilvusをデプロイする場合、milvus.yaml 設定ファイルを編集し、common.security.authorizationEnabled をtrue に設定することで認証を有効にします：

common:
  security:
    authorizationEnabled: true

Helm Chartsを用いたデプロイ

Helm Chartsを使用してMilvusをデプロイする場合、values.yaml ファイルを編集し、extraConfigFiles.user.yaml の下に以下の設定を追加します：

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

ユーザへのロールの付与

ユーザにロールが割り当てられると、そのユーザはリソースにアクセスし、それらのロールによって定義された操作を実行できます。必要なアクセス・スコープに応じて、1 人のユーザに 1 つまたは複数のロールを付与できます。

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上に構築されたRAG（Retrieval-Augmented Generation）システムを考える。

このシステムでは、異なるコンポーネントとユーザが明確に責任を分担し、それぞれが異なるレベルのアクセスを必要とします。

アクター	責任	必要なアクセス
プラットフォーム管理者	システムの運用と設定	インスタンスレベルの管理
ベクター取り込みサービス	ベクターデータの取り込みと更新	読み書きアクセス
検索サービス	ベクター検索	読み取り専用アクセス

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