VAST Fundementals(101) - Security & User Management

VAST에서는 크게 3개의 역할이 있다

 

1. Active Directory, LDAP, NIS

▼

2. Identity Provider

▼

3. Vast Cluster : Administrator(관리자), VMS(GUI), Users(일반 사용자), NFS/SMB/S3로 데이터 접근

 

 

• Provider → 사용자 정보를 제공
• Administrator → VAST를 관리
• User → 데이터를 사용

1. Security & User Management

"multi-layered access control"

즉, 권한을 한 가지만 보는 것이 아니라 여러 단계에서 검사한다.

예) 사용자 로그인 -> AD 인증 -> Group 확인 -> View Policy 확인 -> Security Flavor 확인 -> 파일 권한 확인 -> 접근 허용

 

외부 Identity Provider 사용

VAST는 사용자를 직접 많이 관리하지 않고 기존 회사의 AD, LDAP를 그대로 사용한다.

 

2. VMS(VAST Management System)

VMS는 VAST를 관리하는 GUI와 관리 Plane이다.

즉 VAST GUI, CLI, REST API 모두 VMS를 통해 동작한다.

관리자는 여기에서

• View 생성
• View Policy 생성
• Tenant 생성
• Quota 설정
• User 권한 설정

등을 한다.

 

3. 세 가지 Role

- Administrator(관리자) : Cluster 생성, View 생성, Qota 설정, Policy 생성, 업그레이드, 모니터링 등

Administrator은 RBAC(Role-Based Access Control) 사용, Role에 따라 권한을 준다

예) Storage Admin -> 모든 권한 / Helpdesk -> Read Only / Operator -> Monitoring

Administrator 인증 - 관리자는 Local User 또는 AD 또는 LDAP로 로그인 가능하다.

 

- User(일반 사용자) : GPU서버, Windows PC, S3 Application 등 / VMS로그인하지 않고 mount -> 파일 읽기만 함

User는 AD, LDAP, NIS, Local DB 등 다양한 시스템에서 가져올 수 있다.

예) GPU001 -> UID=1001, Windows User -> AD, S3 App -> IAM

 

- Provider : 외부 인증 시스템(AD, LDAP, NIS) / 이 사람이 누구인가?

실제 동작 예 :

  GPU서버가 NFS Mount를 했다 / GPU001 -> UID=1001 -> VAST

  그러면 VAST는 UID=1001 -> LDAP 조회 -> AI팀 -> View Policy -> Permission OK -> Read 허용

Windows라면,

  Explorer -> SMB -> AD 로그인 -> NTFS ACL 확인 -> 허용

S3라면,

  Application -> Access Key -> IAM Policy -> Bucket Policy -> 허용

 

앞에 배운 Security Flavor와 연결하면,

AD/LDAP - "너 누구야?", 사용자 인증(Authentication) 관점.

Security Flavor - "이 사람이 이 파일을 읽을 수 있나?", 권한 검사(Authorization)

즉,

사용자 -> AD -> 사용자 확인 -> Security Flavor -> 권한 검사 -> 파일 접근

GPU Server -> UID/GID -> LDAP -> 사용자 확인 -> NFS Security Flavor -> POSIX Permission 확인 -> AI Dataset 접근

운영자 -> VMS -> RBAC -> Storage Admin -> View 생성, View Policy 수정, Capacity 확인, Analytics 확인 등 수행

 

• Administrator: VMS에 로그인해서 클러스터를 관리하는 사람(RBAC 적용)
• User: NFS/SMB/S3로 실제 데이터를 사용하는 사용자나 애플리케이션
• Provider: Active Directory, LDAP, NIS처럼 사용자와 그룹 정보를 제공하는 외부 인증 시스템
• Security Flavor: 인증이 끝난 사용자의 파일 접근 권한을 NFS(POSIX), SMB(NTFS ACL), S3(IAM/ACL) 방식 중 어떤 모델로 검사할지 결정하는 정책

즉, Provider는 "누구인지"를 확인하고(Authentication), Security Flavor는 "무엇을 할 수 있는지"를 판단(Authorization)한다는 차이를 이해하면 VAST의 보안 구조를 쉽게 이해할 수 있다.

 

-----

 

Identity Provider

VAST가 사용자(Users)와 그룹(Group) 정보를 어디에서 가져오는지(Identity Provider)

 

1. Active Directory(AD) : Microsoft의 사용자 관리 시스템

가장 많이 사용하는 방식, 계정(ID, 비밀번호), 그룹, 조직 정보가 모두 AD에 저장되어 있다.

예) Username : hong / password : 1234 / Department : AI team / Group : AI_Researchers

VAST는 AD와 연동해서 GPU서버 -> VAST -> AD에게 물어봄 "hong 맞아?" 라고 확인한다.

 

  "Supports multi-domain and cross forest trust"

  companyA.local, companyB.local 도메인이 여러 개 있어도, 전부 다 사용할 수 있다는 의미

 

2.Lightweight Directory Access Protocol(LDAP) : AD와 비슷하지만 운영체제에 독립적인 사용자 관리 시스템

Linux 환경에서는 보통 openLDAP를 많이 사용한다.

예를 들어 GPU 서버가 로그인하려면,

UID=1001 -> LDAP 조회 -> AI Team -> 허용

 

3. NIS(Network Information Service) : 옛날 Unix에서 많이 사용하던 사용자 관리 시스템

4. Local Users : 외부 인증 서버가 없는 경우 VAST 안에서 직접 사용자를 만든다.

소수 계정이 필요한 경우 또는 S3 Object Storage만 사용하는 경우 Local User를 많이 사용한다.

예를 들어 Access Key, Secret Key를 VAST 내부에서 관리한다.

GPU 클러스터 기준으로 가장 많이 사용하는 조합은,

LDAP 또는 AD -> NFS Security Flavor -> POSIX Permission -> GPU서버 접근

 

만약 운영팀이 Windows에서 SMB로 동일한 데이터를 사용한다면 AD와 연동하여 SMB View를 추가하거나, Linux와 Windows가 모두 동일한 데이터를 관리해야 한다면 Mixed-Last-Wins Security Flavor를 선택하는 구성을 사용할 수 있다.

 

-----

 

Multiple Identity Providers(여러 인증 시스템 동시 사용) : AD, LDAP, Local User 등 여러 인증 시스템 동시 사용 가능

User Mapping : common field를 사용하여 맵핑.

예를 들어,

EmployeeID = 10001이라는 공통 필드를 보고, AD의 hong = LDAP의 hong 이라고 판단한다.

즉 두 계정을 한 사용자로 인식한다.

WIndows에서는 SMB로 접속하고, GPU 서버에서 NFS로 접속할 경우,

User Mapping이 없으면 VAST는 Windows 사용자는 Linux 사용자와 다르다고 생각할 수 있다.

 

Platform-Independent Permission

single-set of permissions / 권한을 하나만 저장한다.

예전 스토리지는 NFS권한, SMB권한, S3 권한을 따로 관리해야 해서 권한이 서로 달라질 수 있다.

하지만 VAST는 파일 -> 권한 -> 1개만 존재한다.

그리고 Security Flavor가 그 권한을 어떻게 해석할지 결정한다.

예) 파일 하나가 있다. /dataset/image001.jpg

  권한은 Owner, AI Team, Read 딱 하나만 있다.

  Linux에서 NFS로 보면 / -rw-r----- 처럼 보이고

  Windows에서는 Read Modify Full Control 처럼 보인다.

  S3에서는 IAM Policy로 해석된다.

  하지만 실제 권한은 하나이다.

 

Security Flavor 역할 : 권한을 어떻게 해석할 것인가를 결정

예)

  NFS Flavor면, POSIX/chmod/UID/GID 기준으로 해석

  SMB Flavor면, NTFS ACL 기준으로 해석

 

* Users will have the same access rights regardless of protocol.

* Permissions are immediately reflected across all protocols.

 

1. Multiple Identity Providers: AD, LDAP, NIS, Local User 등 여러 인증 시스템을 동시에 사용할 수 있으며, 공통 식별자(Employee ID, Username 등)를 이용해 서로 다른 시스템의 계정을 하나의 사용자로 매핑할 수 있다.
2. Platform-Independent Permissions: 파일의 권한은 하나만 저장되고, NFS·SMB·S3는 Security Flavor에 따라 그 권한을 각 프로토콜에 맞게 해석한다. 따라서 어떤 프로토콜로 접근하든 동일한 권한이 적용되며, 권한 변경도 모든 프로토콜에 즉시 반영된다.

이 구조 덕분에 Windows 사용자, Linux GPU 서버, S3 기반 AI 애플리케이션이 같은 데이터를 서로 다른 방식으로 접근하면서도 일관된 보안 정책을 유지할 수 있다.