Bug 1041932 - [RFE][keystone]: Fine-Grained Access Control
Summary: [RFE][keystone]: Fine-Grained Access Control
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: RFEs
Version: unspecified
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
: ---
Assignee: RHOS Maint
QA Contact:
URL: https://blueprints.launchpad.net/keys...
Whiteboard: upstream_milestone_none upstream_stat...
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-12-12 20:08 UTC by RHOS Integration
Modified: 2015-03-19 17:28 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-03-19 17:28:45 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description RHOS Integration 2013-12-12 20:08:49 UTC
Cloned from launchpad blueprint https://blueprints.launchpad.net/keystone/+spec/fine-grain.

Description:

In a large implementation, there can be many users each having some level of access to a shared pool of resources. Not all users need that much access though and there are cases where access must be restricted further. V3 introduces policies and that works for restricting access to certain capabilities (only a user with the role "admin" or group "foo" can create server in nova, etc). Policies bloat up though if they need to get down the resource level (only joe can delete server "ABC").

This blue print (which will be expanded upon) introduces the concept of a "resource group" in an attempt to provide highly-available, easily modifiable fine grained access control to OpenStack services.



1.	The v3 core spec doesn’t allow for fine-grained access control.  You can force it into policy blobs, but that isn’t scalable or transparent enough
2.	Identity shouldn’t act as a CMDB, keeping track and storing references to all resources
3.	Having a configurable group that represents resources across services is easier to maintain in identity
4.	Token scope has layers (all optional), and 
     a.	Service endpoints the token has access to
     b.	Which roles the token is scoped to
     c.	Which policies the token is scoped to
5.	Likewise, policies should have scope:
     a.	Which resource groups the policies apply to
6.	Services should make a call available to introspect which servers, files, etc make up that resource group


Specification URL (additional information):

None


Note You need to log in before you can comment on or make changes to this bug.