Home
Blog
Milvus 액세스 제어 가이드: 프로덕션용 RBAC 구성 방법

Milvus 액세스 제어 가이드: 프로덕션용 RBAC 구성 방법

Tutorials

March 26, 2026

Jack Li and Juan Xu

QA 엔지니어가 스테이징 환경이라고 생각하는 것에 대해 정리 스크립트를 실행하는 경우입니다. 연결 문자열이 프로덕션을 가리키는 것만 빼고요. 몇 초 후, 핵심 벡터 컬렉션이 사라지고, 기능 데이터가 손실되고, 유사성 검색이 빈 결과를 반환하고, 서비스가 전반적으로 저하되는 등의 문제가 발생합니다. 사후 조사 결과 항상 그랬던 것처럼 모든 사람이 root 으로 연결했고, 액세스 경계가 없었으며, 테스트 계정이 프로덕션 데이터를 삭제하는 것을 막지 못했다는 동일한 근본 원인을 발견했습니다.

이것은 일회성이 아닙니다. Milvus와 일반적으로 벡터 데이터베이스를 기반으로 구축하는 팀은 인덱스 성능, 처리량, 데이터 규모에 초점을 맞추고 액세스 제어는 나중에 처리할 일로 치부하는 경향이 있습니다. 하지만 '나중에'라는 말은 보통 인시던트의 형태로 다가옵니다. Milvus가 프로토타입에서 프로덕션 RAG 파이프라인, 추천 엔진, 실시간 벡터 검색의 백본으로 이동함에 따라, 누가 Milvus 클러스터에 액세스할 수 있으며 정확히 무엇을 할 수 있는지에 대한 질문은 피할 수 없게 됩니다.

Milvus에는 이 질문에 답할 수 있는 RBAC 시스템이 내장되어 있습니다. 이 가이드에서는 RBAC의 정의, Milvus가 이를 구현하는 방법, 프로덕션을 안전하게 유지하는 액세스 제어 모델을 설계하는 방법을 코드 예제 및 전체 RAG 시스템 워크스루와 함께 다룹니다.

역할 기반 액세스 제어(RBAC)란 무엇인가요?

역할 기반 액세스 제어(RBAC) 는 개별 사용자에게 직접 권한을 할당하지 않는 보안 모델입니다. 대신, 권한이 역할로 그룹화되고 사용자에게 하나 이상의 역할이 할당됩니다. 사용자의 유효 액세스 권한은 할당된 역할의 모든 권한을 합한 것입니다. RBAC는 운영 데이터베이스 시스템의 표준 액세스 제어 모델로서 PostgreSQL, MySQL, MongoDB 및 대부분의 클라우드 서비스에서 사용합니다.

RBAC는 근본적인 확장 문제를 해결합니다. 수십 명의 사용자와 서비스가 있는 경우 사용자별 권한을 관리하는 것은 유지 관리가 불가능해집니다. RBAC를 사용하면 역할을 한 번 정의하고(예: "X 컬렉션에 대한 읽기 전용"), 10개의 서비스에 할당하고, 요구 사항이 변경되면 한 곳에서 업데이트할 수 있습니다.

Milvus는 RBAC를 어떻게 구현하나요?

Milvus RBAC는 네 가지 개념을 기반으로 구축됩니다:

개념	정의	예제
리소스	액세스 대상	Milvus 인스턴스, 데이터베이스 또는 특정 컬렉션
권한/권한 그룹	수행 중인 작업	`Search`, `Insert`, `DropCollection`, 또는 `COLL_RO` 와 같은 그룹(컬렉션 읽기 전용)
역할	리소스로 범위가 지정된 명명된 권한 집합입니다.	`role_read_only` `default` 데이터베이스의 모든 컬렉션을 검색하고 쿼리할 수 있습니다.
사용자	Milvus 계정(사람 또는 서비스)	`rag_writer`수집 파이프라인에서 사용하는 서비스 계정

액세스 권한은 사용자에게 직접 할당되지 않습니다. 사용자에게 역할이 부여되고, 역할에는 권한이 포함되며, 권한은 리소스로 범위가 지정됩니다. 이것은 대부분의 프로덕션 데이터베이스 시스템에서 사용되는 것과 동일한 RBAC 모델입니다. 10명의 사용자가 동일한 역할을 공유하는 경우 역할을 한 번만 업데이트하면 변경 사항이 모든 사용자에게 적용됩니다.

Milvus RBAC model showing how Users are assigned to Roles, and Roles contain Privileges and Privilege Groups that apply to Resources 사용자가 역할에 할당되는 방식과 역할에 리소스에 적용되는 권한 및 권한 그룹을 포함하는 Milvus RBAC 모델

요청이 Milvus에 도달하면 세 가지 검사를 거칩니다:

인증 - 이 사용자가 올바른 자격 증명을 가진 유효한 사용자인가?
역할 확인 - 이 사용자에게 하나 이상의 역할이 할당되어 있는가?
권한 확인 - 사용자의 역할 중 요청된 리소스에 대해 요청된 작업을 허용하는 역할이 있나요?

확인에 실패하면 요청이 거부됩니다.

Milvus authentication and authorization flow: Client Request goes through Authentication, Role Check, and Privilege Check — rejected at any failed step, executed only if all pass Milvus 인증 및 권한 부여 흐름: 클라이언트 요청은 인증, 역할 확인 및 권한 확인 단계를 거치게 되며, 실패한 단계에서는 거부되고 모두 통과한 경우에만 실행됩니다.

Milvus에서 인증을 활성화하는 방법

기본적으로 Milvus는 인증이 비활성화된 상태로 실행되며 모든 연결에 전체 액세스 권한이 있습니다. 첫 번째 단계는 인증을 켜는 것입니다.

도커 컴포즈

milvus.yaml 을 편집하고 authorizationEnabled 을 true 로 설정합니다:

common:
  security:
    authorizationEnabled: true

헬름 차트

values.yaml 을 편집하고 extraConfigFiles 아래에 설정을 추가합니다:

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

Kubernetes에 Milvus Operator를 배포하는 경우, 동일한 구성이 Milvus CR의 spec.config 섹션에 적용됩니다.

인증이 활성화되고 Milvus가 다시 시작되면 모든 연결은 자격 증명을 제공해야 합니다. Milvus는 기본 root 사용자와 Milvus 비밀번호를 생성하므로 즉시 변경하세요.

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

사용자, 역할 및 권한을 구성하는 방법

인증이 활성화된 상태에서 일반적인 설정 워크플로우는 다음과 같습니다.

1단계: 사용자 만들기

서비스 또는 팀원이 root 을 사용하지 못하게 하세요. 각 사용자 또는 서비스에 대한 전용 계정을 만듭니다.

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

2단계: 역할 만들기

Milvus에는 admin 역할이 기본 제공되지만, 실제로는 실제 액세스 패턴에 맞는 사용자 지정 역할이 필요할 것입니다.

client.create_role(role_name="role_a")

3단계: 권한 그룹 만들기

권한 그룹은 여러 권한을 하나의 이름으로 묶어 대규모 액세스를 더 쉽게 관리할 수 있도록 해줍니다. Milvus는 9개의 기본 제공 권한 그룹을 제공합니다:

기본 제공 그룹	범위	허용하는 권한
`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 group
client.add_privileges_to_group(
group_name=‘privilege_group_1’,
privileges=[‘Query’, ‘Search’]
)

4단계: 역할에 권한 부여하기

특정 리소스로 범위가 지정된 역할에 개별 권한 또는 권한 그룹을 부여합니다. collection_name 및 db_name 매개 변수로 범위를 제어하며, 모두 * 을 사용합니다.

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

5단계: 사용자에게 역할 할당

사용자는 여러 역할을 보유할 수 있습니다. 사용자의 유효 권한은 할당된 모든 역할의 합입니다.

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

액세스 권한 감사 및 취소 방법

어떤 액세스 권한이 있는지 파악하는 것은 권한을 부여하는 것만큼이나 중요합니다. 이전 팀원, 퇴사한 서비스 또는 일회성 디버깅 세션에서 얻은 오래된 권한은 소리 없이 누적되어 공격 표면을 넓힙니다.

현재 권한 확인

사용자에게 할당된 역할을 확인하세요:

client.describe_user(user_name="user_1")

역할에 부여된 권한을 확인하세요:

client.describe_role(role_name="role_a")

역할에서 권한 취소

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

사용자로부터 역할 할당 해제

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

예시 프로덕션 RAG 시스템을 위한 RBAC 설계 방법

구체적인 예시를 통해 추상적인 개념을 더 빨리 이해할 수 있습니다. Milvus를 기반으로 구축된 세 가지 서비스가 있는 RAG 시스템을 생각해 보세요:

서비스	책임	필수 액세스
플랫폼 관리자	Milvus 클러스터를 관리합니다 - 컬렉션 생성, 상태 모니터링, 업그레이드 처리	전체 클러스터 관리자
수집 서비스	문서에서 벡터 임베딩을 생성하고 컬렉션에 기록합니다.	컬렉션에 읽기 + 쓰기
검색 서비스	최종 사용자의 벡터 검색 쿼리 처리	컬렉션에서 읽기 전용

다음은 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”)

각 서비스는 필요한 액세스 권한을 정확히 얻습니다. 검색 서비스는 실수로 데이터를 삭제할 수 없습니다. 수집 서비스는 클러스터 설정을 수정할 수 없습니다. 그리고 검색 서비스의 자격 증명이 유출되면 공격자는 임베딩 벡터를 읽을 수는 있지만 쓰기, 삭제 또는 관리자에게 에스컬레이션할 수 없습니다.

여러 Milvus 배포에서 액세스를 관리하는 팀의 경우, Zilliz Cloud (관리형 Milvus)는 사용자, 역할, 권한을 관리할 수 있는 웹 콘솔이 포함된 기본 제공 RBAC를 제공하며 스크립팅이 필요하지 않습니다. 여러 환경에서 설정 스크립트를 유지 관리하기보다 UI를 통해 액세스를 관리하려는 경우에 유용합니다.

프로덕션을 위한 액세스 제어 모범 사례

위의 설정 단계는 기본적인 메커니즘입니다. 다음은 시간이 지나도 액세스 제어를 효과적으로 유지하는 설계 원칙입니다.

루트 계정 잠금

무엇보다 먼저 기본 root 비밀번호를 변경하세요. 프로덕션 환경에서는 루트 계정을 긴급 작업에만 사용하고 애플리케이션 구성에 하드코딩하거나 Slack을 통해 공유하지 말고 비밀 관리자에 저장해야 합니다.

환경을 완전히 분리

개발, 스테이징 및 프로덕션에 서로 다른 Milvus 인스턴스를 사용하세요. 연결 문자열 하나만 잘못 구성해도 개발 서비스가 프로덕션 데이터에 쓰게 되는 등 RBAC만으로는 환경 분리가 취약합니다. 물리적 분리(다른 클러스터, 다른 자격 증명)는 이러한 종류의 사고를 완전히 제거합니다.

최소 권한 적용

각 사용자와 서비스에 작업을 수행하는 데 필요한 최소한의 액세스 권한을 부여하세요. 좁게 시작하여 문서화된 특정 요구가 있을 때만 넓히세요. 개발 환경에서는 좀 더 느슨하게 적용할 수 있지만 프로덕션 액세스 권한은 엄격하게 관리하고 정기적으로 검토해야 합니다.

오래된 액세스 정리

누군가가 팀을 떠나거나 서비스가 중단되면 즉시 역할을 취소하고 계정을 삭제하세요. 활성 권한이 있는 사용하지 않는 계정은 아무도 모니터링하지 않는 유효한 자격 증명으로, 무단 액세스의 가장 흔한 경로입니다.

특정 컬렉션에 대한 권한 범위 지정

해당 역할이 진정으로 모든 컬렉션에 대한 액세스 권한이 필요한 경우가 아니라면 collection_name='*' 권한을 부여하지 마세요. 멀티테넌트 설정이나 여러 데이터 파이프라인이 있는 시스템에서는 각 역할의 범위를 해당 역할이 작업하는 컬렉션으로만 한정하세요. 이렇게 하면 자격 증명이 손상된 경우 폭발 반경이 제한됩니다.

프로덕션에 Milvus를 배포하고 액세스 제어, 보안 또는 멀티테넌트 설계를 통해 작업하고 계신다면 저희가 도와드리겠습니다:

Milvus Slack 커뮤니티에 참여하여 Milvus를 대규모로 실행하는 다른 엔지니어들과 실제 배포 사례에 대해 논의하세요.
역할 구조, 컬렉션 수준 범위 지정 또는 다중 환경 보안 등 RBAC 설계를 살펴볼 수 있는20분짜리 무료 Milvus 오피스 아워 세션을 예약하세요.
인프라 설정을 건너뛰고 UI를 통해 액세스 제어를 관리하고 싶다면 웹 콘솔이 포함된 기본 제공 RBAC와 함께 암호화, 네트워크 격리, SOC 2 규정 준수가 기본적으로 제공되는 Zilliz Cloud (관리형 Milvus)를 선택하세요.

팀이 Milvus에서 액세스 제어를 구성하기 시작할 때 자주 발생하는 몇 가지 질문입니다:

질문: 사용자를 모든 컬렉션이 아닌 특정 컬렉션으로만 제한할 수 있나요?

예. 전화할 때 grant_privilege_v2*대신 collection_name 를 특정 컬렉션으로 설정하면 해당 사용자의 역할은 해당 컬렉션에만 액세스할 수 있습니다. 컬렉션당 한 번씩 함수를 호출하여 여러 컬렉션에 대해 동일한 역할 권한을 부여할 수 있습니다.

질문: Milvus에서 권한과 권한 그룹의 차이점은 무엇인가요?

권한은 Search, Insert, DropCollection 과 같은 단일 작업입니다. 권한 그룹은 여러 권한을 하나의 이름으로 묶은 것입니다(예: COLL_RO 에는 모든 읽기 전용 컬렉션 작업이 포함됩니다). 권한 그룹을 부여하는 것은 기능적으로 각 구성 권한을 개별적으로 부여하는 것과 동일하지만 관리하기가 더 쉽습니다.

질문: 인증을 활성화하면 Milvus 쿼리 성능에 영향을 주나요?

오버헤드는 무시할 수 있는 수준입니다. Milvus는 각 요청에 대해 자격 증명을 검증하고 역할 권한을 확인하지만, 이는 인메모리 조회이므로 밀리초가 아닌 마이크로초가 추가됩니다. 검색 또는 삽입 대기 시간에는 측정 가능한 영향이 없습니다.

질문: 멀티테넌트 설정에서 Milvus RBAC를 사용할 수 있나요?

예. 테넌트별로 별도의 역할을 만들고, 각 역할의 권한을 해당 테넌트의 컬렉션에 한정하고, 각 테넌트의 서비스 계정에 해당 역할을 할당하세요. 이렇게 하면 별도의 Milvus 인스턴스 없이도 컬렉션 수준의 격리가 가능합니다. 대규모 멀티테넌시에 대해서는 Milvus 멀티테넌시 가이드를 참조하세요.