"Nova REST API 정책 집행"의 두 판 사이의 차이

1번째 줄: 1번째 줄:
==개요==
==개요==
[[분류: OpenStack]]
[[분류: REST API]]
;REST API Policy Enforcement
;REST API Policy Enforcement
;REST API 정책 집행
;REST API 정책 집행

2024년 6월 12일 (수) 18:25 판

1 개요

REST API Policy Enforcement
REST API 정책 집행

다음은 nova에서 정책이 사용되고 집행되는 방식의 단점과 이러한 문제를 해결함으로써 얻을 수 있는 이점에 대해 설명합니다. 각 문제는 그 근본 원인과 역사적 맥락을 자세히 설명하는 섹션으로 구성되어 있습니다.

2 현재 시스템의 문제

다음은 기존 정책 집행 시스템의 이슈 목록입니다:

위 목록을 해소하면 운영자에 도움이 되는 점:

  • 1. 유연하고 유용한 기본값 제공
  • 2. 커스텀 정책 작성 및 유지보수 감소
  • 3. 배포 간 상호운용성 향상
  • 4. 1급 테스트 및 검증을 통한 RBAC 신뢰도 증가
  • 5. 일관된 정책 네이밍 컨벤션 사용으로 복잡성 감소
  • 6. 더 많은 기능을 안전하게 최종사용자에게 노출시켜 nova API를 더 많이 셀프 서비스화하고, 운영자가 사용자를 대신하여 수행해야 하는 작업의 운영 오버헤드 감소

또한 기여자에게 주는 이점:

  • 정책 집행을 단일 계층으로 격리하여 개발자 유지보수 및 비용 감소
  • 일관된 정책 네이밍 컨벤션 사용으로 복잡성 감소
  • 병합 전 회귀를 방지하는 철저한 테스트를 통해 RBAC 리팩토링에 대한 신뢰도 증가

3 기본 정책 테스트

4 불일치된 인가

5 비일관적 네이밍

6 기본 역할 결합

7 구획화된 정책 집행

8 하드코딩된 퍼미션 체크 리팩토링

9 세분화된 정책 체크

정책은 일관성과 합리적인 기본값을 보장하기 위해 가능한 한 세분화되어야 합니다. 전체 API에 대한 CRUD를 보호하기 위해 단일 정책을 사용하는 것은 기본 역할을 사용하여 해당 API에 대한 위임을 유연하게 만드는 것을 방해하기 때문에 제한적입니다. 예를 들어, compute:foorbar에 대한 정책을 compute:foobar:create, compute:foobar:update, compute:foobar:list, compute:foobar:get, compute:foobar:delete로 나눌 수 있습니다. 이렇게 정책을 분리하면 읽기 전용 작업에 대한 정책을 설정하거나 foobar 리소스의 생성 및 관리를 위한 다른 기본 역할을 사용할 수 있습니다. oslo.policy 라이브러리에는 제거예정 정책 규칙을 사용하여 이를 수행하는 예제가 포함되어 있습니다.

문서 댓글 ({{ doc_comments.length }})
{{ comment.name }} {{ comment.created | snstime }}