feat: VM 인가를 자원별 접근 목록으로 전환 - #31
Merged
Merged
Conversation
Ten services each carried their own copy of the same three steps: load the VM, look up the requester's role in its owning group, choose between the masking 404 and a 403. Three of them were byte-identical apart from the message text, and the 404 factory existed nine times over. They now ask one resolver, which is what lets the coming per-resource access list replace the role lookup without touching any caller. Behavior is unchanged: every refusal keeps its status, code and wording, and each call site keeps its own 403 text because that text names the operation. Admin surfaces stay out of it deliberately. Their scope is the organisation rather than group membership, and folding the two together is how a bypass gets written by accident.
A VM role and a group role were the same enum, which only held while the group role was the sole axis. Containers and API keys are next, and neither has a group meaning, so the resource axis gets ResourceRole and the group axis keeps GroupMemberRole. Only the type moves here; the values, the ladder and every decision stay as they were. The resolver still reads the group ladder and maps it across, which is the one line the access list replaces next. VmDetail.myGroupRole becomes myResourceRole, since after this it answers a different question: what the requester may do to this VM, not what they are in its group.
A rung in the owning group no longer implies reaching that group's VMs. Each VM carries its own access list, a VM starts with only its requester on it, and a member the list does not name sees that it exists and nothing else. The list is keyed by resource type rather than by vm_id. Containers, GPU allocations and LLM API keys are all decided additions that ask the same question, and each should arrive as a value plus an adapter rather than as another table with the same five columns. Group standing keeps three powers over the group's resources: see they exist, delete them, and manage who reaches them. It is held as a flag rather than a rung so that nothing inside a VM can be reached by owning its group; an owner who needs inside grants themselves, and that leaves a break-glass record. V70 carries the schema and the move together, because the new judgment reads grants: any gap between the two would be a gap in which nobody can reach their own VM. It checks each grant against the membership it came from while both still exist, since counting rows cannot catch a wrong rung.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
📝 작업내용
ResourceRole4단 신설, 그룹 역할은OWNER/MEMBER2단으로 축소resource_access_grants신설, 자원 종류 판별자를 갖고 이번 라운드는 VM만 연결⭐️ 검증
scripts/verify.sh통과, mvn verify와 테스트 701개💬 리뷰 포인트