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 일관성 없는 네이밍
대부분의 OpenStack 서비스, 특히 nova에서 정책 이름에 대한 일관성 없는 컨벤션이 산재해 있습니다. 최근에 서비스 이름, 리소스, 사용사례를 고려한 새로운 컨벤션이 도입되었습니다. 이 새로운 컨벤션은 nova 정책 이름에 적용됩니다. 이 컨벤션은 공식적으로 oslo.policy에 문서화되어 있으며, 정책 deprecation 도구를 사용하여 정책 이름을 원활하게 변경할 수 있습니다.
6 기본 역할 통합
Rocky 릴리스까지, keystone은 설치 시 배포에 단 하나의 역할인 admin만을 보장했습니다. Rocky 릴리스에서는 이러한 지원이 확장되어 설치 시 member와 reader 역할도 일급 시민(first-class citizens)으로 포함되었습니다. 이는 서비스 개발자가 이러한 역할에 의존할 수 있게 하며, 이를 기본 정책 정의에 포함할 수 있게 합니다. 기본 정책에 대한 역할 이름을 표준화하면 배포 간 상호운용성이 증가하고 운영자의 부담이 줄어듭니다.
기본 역할에 대한 자세한 정보는 keystone 사양 또는 개발자 문서에서 확인할 수 있습니다.
7 격리된 정책 집행
정책 로직과 처리는 본질적으로 민감하고 종종 복잡합니다. 이는 코드 작성 실수가 보안 취약점을 초래할 수 있다는 점에서 민감합니다. 또한 보호해야 할 리소스와 API가 많고 지원해야 할 사용사례가 방대하다는 점에서 복잡합니다. 이러한 이유들로 인해 정책 로직과 처리를 분할된 공간으로 격리하는 것이 타당하며, 이는 정책 로직이 nova의 여러 계층으로 흩어지는 것을 방지할 수 있습니다. 모든 정책 로직이 한 곳에 모이지 않으면 정책 집행 시스템을 발전시키는 것이 어렵고 정책 시스템 자체가 취약해집니다.
현재 nova의 데이터베이스 및 API 구성 요소에는 정책 로직이 포함되어 있습니다. 향후 유지보수가 용이한 단일 컴포넌트로 이러한 시스템을 리팩토링해야 합니다. 이를 실행하기 전에, 정책 회귀를 예방하거나 인지할 수 있도록 테스트 커버리지를 강화하는 방법을 고려해야 합니다. API 보호 테스트 가이드에 예제와 문서가 있습니다.
8 하드코딩된 권한 체크 리팩토링
노바(Nova)의 정책 시스템은 설정가능하게 설계되었습니다. 그럼에도 불구하고, 특정 역할에 대해 하드코딩된 체크를 사용하는 API가 있습니다. 이는 설정을 불가능하게 만들고, 운영자에게 혼란과 좌절을 안겨줍니다. 하드코딩된 정책을 제거하고 설정 기반 접근방식을 보장함으로써 기술 부채를 줄이고 일관성을 높이며 운영자에게 더 나은 사용자 경험을 제공할 수 있습니다. 또한, 하드코딩된 체크를 일급 정책 규칙으로 이동시키면 기존의 정책 도구를 사용하여 정책을 지원중단, 문서화, 발전시킬 수 있습니다.
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}}