Edit Files
Login Register

Role Base Access Control

Role을 이용해서 구현된 Access control을 말합니다.

일반적인 RBAC 구현

구성 요소

  • Subject
    • User
    • Group
    • Service Account
  • Resource
  • Role
  • Assign

주의점

  • Role과 Group 을 자주 오용 하는 경우가 많다.
    • Role 은 권한 정책만 집중하고, Group 은 인원 관리에만 집중한다.
    • 즉 Role 과 Group 는 관심사의 분리 관점에서 보아야 한다.
  • Role을 복잡하게 만드는 경우가 많다.
    • 일반적인 RBAC System에서는 Subject 하나에 여러 Role 을 부여 할수 있다.
    • 그러므로 Role은 되도록 단순하게 유지하고, Subject에 여러 Role 을 부여하는 방식이 더 좋다.
      • eg) 전체를 읽을수 있고 일부 리소스를 쓸수 있는 Role 보다는 전체 viewer Role, 일부 editor Role 두 Role 을 두고 한 Subject에 둘다 부여 하는 것이 더 단순하다.

example

yaml 로 전체 RBAC system의 예시 데이터를 표현해 본다면 아래와 같다.

users:
- name: bluemir
- name: aaaa
- name: bbbb
groups:
- name: admin
  members: [ bluemir, aaaa ]
- name: devops
  member: [ aaaa, bbbb ]
resources:
- kind: issue
  name: i1
- kind: issue
  name: i2
- kind: article
  name: a1
- kind: article
  name: a2
- kind: project
  name: p1
- kind: project
  name: p2
roles:
- name: reader
  rules:
  - verbs: [get, list]
    resources: [] # all

알려진 문제점 과 보완책

Role Explosion

Strict RBAC의 경우 권한이 분리되어야 하는 Resource 별로 Role 이 하나씩 필요하다. 만일 서로 권한이 달라야 하는 Resource가 동적 생성이 되는 경우, 그에 따라 Role 이 폭발적으로 증가할수 있다. 이는 객체별로 소유권이 다르지만 모두 하나의 collection 을 쓰는 multi-tenancy 환경에서 잘 관찰할수 있다.

예를 들어 하나의 게시판에서 각 게시물을 작성자만 다시 수정할 수 있도록 권한 처리 요구사항이 있다고 생각해보자 이 경우 작성자 마다 권한이 조금씩 다르다는 것을 의미하고, 적어도 작성자 마다 Role 이 부여되어야한다는 사실을 알수 있다. 그리고 글 하나가 추가 될떄 마다 Role의 Policy 로 각 게시글을 직접 지정하거나, 게시물 자체에 작성자라는 속성을 부여하고 이 속성을 Policy에서 지정해야 한다.

여러개의 Role은 일괄 Update 등이 어렵고, 유지보수도 어렵다. 이 한계점을 극복하기 위해서는 RBAC 에서 동적인 부분을 도입할수 있다.

가장 흔한 방법은 Rule에 Condition 과 같은 추가적인 filter 를 제공하는 것이다.

` roles: - name: post-owner rules: - verbs: [update] selector: - kind: post condition: - user.name == resource.owner-name

그러나 이 방법은 사실상 ABAC이나 Rule Chaining 방식이라고 봐도 무방할것이다. 하지만 대부분의 요구사항은 RBAC 으로 사용해서 유지 보수가 쉽도록 하고, 특별한 Case 에 대해서 추가적인 option 을 제공 함으로써 가능한 기능의 범위를 넓히려는 경우에 유용하다.