1. Nova에서의 Project와 Role 작동 방식

Nova는 가상머신(VM)과 하이퍼바이저 등 클러스터 전체의 핵심 인프라 자원을 관리합니다. 이 때문에 관리자 권한을 판단할 때 프로젝트 명함보다 '롤(Role)'을 훨씬 더 엄격하게 검사합니다.

• Project (공간)의 의미:

  • Nova에서 일반적인 VM 생성/조회 API는 유저가 속한 프로젝트(project_id) 내부로 영역이 자동 제한됩니다.

  • 하지만 os-services(노드 제어), os-hypervisors 같은 글로벌 인프라 API는 특정 프로젝트에 속하지 않습니다. 따라서 Nova는 "유저가 어떤 프로젝트 소속인가"를 보기 전에 "글로벌 관리자 관문"을 먼저 확인합니다.

• Role (자격)의 의미:

  • Nova의 마스터 키인 "context_is_admin"의 기본값은 명확하게 "role:admin"(롤 이름)입니다.

  • 프로젝트가 admin이든 일반 iwinv_project이든 관계없이, 토큰에 admin이라는 정확한 롤 이름이 없으면 글로벌 인프라 API는 무조건 403 Forbidden으로 튕겨냅니다.

• 실무적 특징: * 우리가 일반 프로젝트 유저에게 노드 제어 권한을 주기 위해 "context_is_admin": "role:admin or role:iwinv_dashboard"라고 설정을 수정한 이유가 바로 이 때문입니다. Nova는 롤 기반(RBAC) 검증이 매우 강력합니다.

2. Neutron에서의 Project와 Role 작동 방식

Neutron은 네트워크, 서브넷, 포트 등 테넌트(프로젝트) 간의 완벽한 격리와 공유를 관리합니다. 이 때문에 Neutron은 롤만큼이나 "이 자원을 소유한 프로젝트가 어디인가"를 매우 중요하게 여깁니다.

• Project (공간)의 의미:

  • Neutron의 기본 마스터 키인 admin_or_owner 규칙은 소스코드 내부에 다음과 같이 박혀 있습니다: "rule:context_is_admin or tenant_id:%(tenant_id)s".

  • 특히 과거 레거시나 일부 기본값에서는 project_name:admin (프로젝트 이름 자체가 admin인 경우) 자체를 최고 관리자 공간으로 신뢰하는 경향이 있습니다.

  • 이 때문에 유저가 admin 프로젝트에 속해 있다면, 롤이 일반 롤(iwinv_dashboard)이더라도 "어? 너 admin 프로젝트 방에 들어와 있네? 그러면 이 방에 있는 포트 리스트는 일반 유저 자격으로 다 봐도 돼"라며 목록을 노출해 버립니다.

• Role (자격)의 의미:

  • Neutron에서도 공유되지 않은 남의 테넌트 자원을 보거나, 물리 호스트 정보(binding:host_id) 같은 민감한 백엔드 속성을 볼 때는 정확히 "role:admin" 자격증이 있는지 검사합니다.

• 실무적 특징:

• Neutron 정책 파일에서 get_port 자체를 롤 기반으로 막아버리면, 백엔드에서 유저 토큰을 대행하여 통신하는 Heat 엔진이나 Nova 엔진의 내부 포트 조회까지 같이 차단되어 인프라 오동작(403 에러)이 발생합니다.