Sub-Pages and Page Search

Expand all Collapse all

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 VM1: customer's server VM2: customer's server VM3: ServiceVM1(FW) managed by provider1 VM4: Service VM2(IDS) managed by provider2 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...

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

VM1: customer's server

VM2: customer's server

VM3: ServiceVM1(FW) managed by provider1

VM4: Service VM2(IDS) managed by provider2

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

Development Proposal	This development proposal is accepted and being run by Sampath Priyankara and this page and JIRA item are meant to facilitate collaboration from other interested staff.	http://specs.openstack.org/openstack/openstack-user-stories/user-stories/proposed/openstack_extreme_testing.html LCOO-4 - OpenStack Extreme Testing Gap/Overlap Analysis
Specification	Specification for new HA testing project. This pre-existing specification is being adopted under the Development proposal and Sampath has requested our assistance in review.	https://review.openstack.org/#/c/443504/

Development Proposal	This development proposal is accepted and being run by Sampath Priyankara and this page and JIRA item are meant to facilitate collaboration from other interested staff.	http://specs.openstack.org/openstack/openstack-user-stories/user-stories/proposed/openstack_extreme_testing.html LCOO-4 - OpenStack Extreme Testing Gap/Overlap Analysis
Specification	Specification for new HA testing project. This pre-existing specification is being adopted under the Development proposal and Sampath has requested our assistance in review.	https://review.openstack.org/#/c/443504/

Sub-Pages and Page Search

Use Cases

Related LCOO Session, OpenStack Submissions/efforts/projects

Tools

Upcoming working sessions

Task List and Current Status

Formal OpenStack Submissions/efforts/projects

Tools

Upcoming working sessions

Task List and Current Status

Formal OpenStack Submissions/efforts/projects

Tools

Upcoming working sessions

Task List and Current Status

Jira	https://openstack-lcoo.atlassian.net/projects/ERIS
GitHub	https://github.com/lcoo-jira/eris
Slack:	https://lcoo.slack.com/ #testing channel

Browser not supported