Policy Decision Point Framework (PDP)
Sub-Pages and Page Search
Use Cases
| ID | Title | Primary Actor | Secondary Actor | Description |
|---|---|---|---|---|
| NTT-1 | Hierarchical Admin roles | Supervisor/ High level admins | Regional Support team members | In a large operator with multi-location, multi-tenant environment, there are requirements for multiple operator/support teams looking after their local user/customers, and high level administrators who are supervising multiple of those teams. Example use case "regional support team A" is looking after customers #1 to #1000 in their location and have access to customer's resources. "regional support team B" is looking after customers #1001 to #2000 in their location and have access to customer's resources. "Supervisor A" is a manager responsible for regional support team A and B and has "admin" access to resources of customers #1 to #2000 "Supervisor B" is a manager responsible for other support teams(C and D) and has "admin" access to resources of customers #2001 to #4000 Regional support team A can not access to resources of customers #1001 to #2000 and vice versa. |
| NTT-2 | Managed VMs | Service provider | tenant user/customer | Service provider provides "Service VMs" to customers. ”Service VMs” adds functions/ capabilities to customer's tenant network, i.e. FW, Storage, LB Service VMs are managed by service providers and customers do no have direct access to VMs including control over Nova APIs and console. Example customer network
VM3 and 4 are created by service providers based on service order from the customer. Customer have control over VM1 and 2 but can not control(e.g. delete/update/detach/console access) VM3 and 4. VM3 and VM4 have web-based control GUI for customers to config. |
| NTT-3 | API filtering | Operator | End users/customers | A cloud operator exposes OpenStack APIs to end customers. The operator wants to restrict users to access immature functions. (e.g. New/experimental functions not well tested by the community/operator) The operator wants to make APIs invisible to the end users, or restrict users to access to the APIs (granularity of request parameters is necessary for APIs like /servers/{id}/action) *Note: This can be achieved by editing policy.json but not sure if every projects have implemented policy enforcement to every API/features so this might end up checking all APIs in every projects... |
Related LCOO Session, OpenStack Submissions/efforts/projects
| Type | Short Description | URL |
|---|---|---|
| LCOO Topical | 2017.11.30 LCOO Topical - Role Based Access Controls (RBAC) | |
Tools
| Link | Use |
|---|---|
| Jira | tbd |
| GitHub | tbd |
| Slack: | https://lcoo.slack.com/ #security channel |
Upcoming working sessions
| Date | Joint Meeting Page x-ref | Coordinator |
|---|---|---|
Task List and Current Status
Todo: For any requirements or development type items: Create work items for each item below in the Jira which is a dedicated JIRA project that has been created for managing the various work items through their life-cycle.
| Task | Description | Assignees | Status | Reference |
|---|---|---|---|---|