| 36번째 줄: | 36번째 줄: | ||
이러한 유형의 테스트를 개발하는 과정에 대한 설명하는 [https://docs.openstack.org/keystone/latest/contributor/services.html#ruthless-testing 테스트 문서]가 있습니다. | 이러한 유형의 테스트를 개발하는 과정에 대한 설명하는 [https://docs.openstack.org/keystone/latest/contributor/services.html#ruthless-testing 테스트 문서]가 있습니다. | ||
== | ==불일치하는 인가== | ||
Compute API는 물리적 및 가상 하드웨어를 관리하기 위해 풍부한 기능을 제공하며 발전해 왔습니다. 일부 API는 운영자를 돕기 위해 설계된 반면, 다른 API는 최종 사용자를 위해 특정되었습니다. 역사적으로 nova는 의도된 사용자에 상관없이 거의 모든 API를 보호하기 위해 프로젝트 범위의 토큰을 사용했습니다. 프로젝트 범위의 토큰을 사용하여 시스템 수준의 API 요청을 승인하는 것은 바람직하지 않은 사용자 경험을 초래하며 역할의 과부하를 초래할 수 있습니다. 예를 들어, 하드웨어 수준의 API에 접근하는 모든 사용자가 테넌시를 위반하지 않도록 하기 위해 운영자는 <code>system-admin<code> 또는 <code>super-admin<code> 역할을 생성하고, 그 역할을 포함하도록 시스템 수준의 정책을 다시 작성해야 합니다. 이는 프로젝트에서 그 특별한 역할을 가진 사용자가 프로젝트와 관련이 없는 시스템 수준의 리소스에 접근할 수 있음을 의미합니다(하이퍼바이저 정보는 시스템 특정 정보의 예입니다). | |||
Queens 릴리스부터 keystone은 이 문제를 완화하기 위해 시스템 스코프라는 유형을 지원합니다. Compute API 전반에서 시스템 스코프를 사용하면 과부하된 역할이 줄어들고 코드 내의 특수한 승인 논리가 감소하며, 테넌시를 위반하지 않고 사용자에게 더 많은 기능을 노출하는 간단한 정책을 제공할 수 있습니다. 스코프 및 그 효과적인 사용방법에 대한 자세한 내용은 [https://docs.openstack.org/keystone/latest/contributor/services.html#authorization-scopes keystone의 인가 스코프 문서]를 참조하십시오. | |||
==비일관적 네이밍== | ==비일관적 네이밍== | ||
==기본 역할 결합== | ==기본 역할 결합== | ||
2024년 6월 12일 (수) 22:20 판
1 개요
- REST API Policy Enforcement
- REST API 정책 집행
다음은 nova에서 정책이 사용되고 집행되는 방식의 단점과 이러한 문제를 해결함으로써 얻을 수 있는 이점에 대해 설명합니다. 각 문제는 그 근본 원인과 역사적 맥락을 자세히 설명하는 섹션으로 구성되어 있습니다.
2 현재 시스템의 문제
다음은 기존 정책 집행 시스템의 이슈 목록입니다:
위의 이슈들을 해결하면 운영자에 도움이 되는 점:
- 1. 유연하고 유용한 기본값 제공
- 2. 커스텀 정책 작성 및 유지보수 감소
- 3. 배포 간 상호운용성 향상
- 4. 1급 테스트 및 검증을 통한 RBAC 신뢰도 증가
- 5. 일관된 정책 네이밍 컨벤션 사용으로 복잡성 감소
- 6. 더 많은 기능을 안전하게 최종사용자에게 노출시켜 nova API를 더 많이 셀프 서비스화하고, 운영자가 사용자를 대신하여 수행해야 하는 작업의 운영 오버헤드 감소
또한 기여자에게 주는 이점:
- 정책 집행을 단일 계층으로 격리하여 개발자 유지보수 및 비용 감소
- 일관된 정책 네이밍 컨벤션 사용으로 복잡성 감소
- 병합 전 회귀를 방지하는 철저한 테스트를 통해 RBAC 리팩토링에 대한 신뢰도 증가
3 기본 정책 테스트
기본 정책 테스트는 권한 회귀를 방지하는 데 중요합니다. 권한 회귀는 변경사항이 우연히 누군가가 하지 말아야 할 일을 하거나 보지 말아야 할 것을 보게 하거나, 사용자가 이전에 수행할 수 있었던 작업을 할 수 없도록 우연히 제한하는 경우를 말합니다. 이 테스트는 특히 정책 시스템의 큰 부분을 리팩토링하기 전에 유용합니다. 예를 들어, 정책 집행 로직을 데이터베이스 레이어에서 API 레이어로 옮기기 전에 이러한 수준의 테스트는 매우 중요합니다.
이러한 유형의 테스트를 개발하는 과정에 대한 설명하는 테스트 문서가 있습니다.
4 불일치하는 인가
Compute API는 물리적 및 가상 하드웨어를 관리하기 위해 풍부한 기능을 제공하며 발전해 왔습니다. 일부 API는 운영자를 돕기 위해 설계된 반면, 다른 API는 최종 사용자를 위해 특정되었습니다. 역사적으로 nova는 의도된 사용자에 상관없이 거의 모든 API를 보호하기 위해 프로젝트 범위의 토큰을 사용했습니다. 프로젝트 범위의 토큰을 사용하여 시스템 수준의 API 요청을 승인하는 것은 바람직하지 않은 사용자 경험을 초래하며 역할의 과부하를 초래할 수 있습니다. 예를 들어, 하드웨어 수준의 API에 접근하는 모든 사용자가 테넌시를 위반하지 않도록 하기 위해 운영자는 system-admin 또는 super-admin 역할을 생성하고, 그 역할을 포함하도록 시스템 수준의 정책을 다시 작성해야 합니다. 이는 프로젝트에서 그 특별한 역할을 가진 사용자가 프로젝트와 관련이 없는 시스템 수준의 리소스에 접근할 수 있음을 의미합니다(하이퍼바이저 정보는 시스템 특정 정보의 예입니다).
Queens 릴리스부터 keystone은 이 문제를 완화하기 위해 시스템 스코프라는 유형을 지원합니다. Compute API 전반에서 시스템 스코프를 사용하면 과부하된 역할이 줄어들고 코드 내의 특수한 승인 논리가 감소하며, 테넌시를 위반하지 않고 사용자에게 더 많은 기능을 노출하는 간단한 정책을 제공할 수 있습니다. 스코프 및 그 효과적인 사용방법에 대한 자세한 내용은 keystone의 인가 스코프 문서를 참조하십시오.
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 라이브러리에는 제거예정 정책 규칙을 사용하여 이를 수행하는 예제가 포함되어 있습니다.
-
{{comment.page_title}} ―{{comment.name}}