Difference between revisions of "MagnetoDB/specs/rbac"
(→= References) |
(→Proposed change) |
||
(One intermediate revision by the same user not shown) | |||
Line 11: | Line 11: | ||
# Implement role based access control in all apis like all other openstack projects. A file called policy.json would reside in the config directory wherein the magnetodb administrator can specify rules to control access to an api. | # Implement role based access control in all apis like all other openstack projects. A file called policy.json would reside in the config directory wherein the magnetodb administrator can specify rules to control access to an api. | ||
− | # For e.g. A rule such as this "mdb:create_table": "role:admin" would allow any user with admin role to create table in any project. | + | # Enforcement of rules is going to be based only on roles and project_ids. It means that we will use project_id and role from keystone token to enforce rules. The rule engine supports a combination of rules through 'AND', 'OR', 'NOT' clause. |
− | + | # The list of apis which are going to be restricted is: | |
− | + | ## create_table | |
+ | ## delete_table | ||
+ | ## describe_table | ||
+ | ## list_table | ||
+ | ## put_item | ||
+ | ## get_item | ||
+ | ## update_item | ||
+ | ## query | ||
+ | ## scan | ||
+ | ## batch_write | ||
+ | ## batch_get | ||
+ | # For e.g. A rule such as this "mdb:create_table": "role:admin" would allow any user with admin role to create table in any project. A rule like "mdb:create_table":"role:admin or tenant:(tenant_id)s". This would enforce the user either to have an admin role or create a table in his project only. A rule like "mdb:create_table": "" would allow everyone to access that api.A rule like "mdb:create_table": "!" wouldn't allow anyone to access that api. | ||
+ | |||
====Alternatives==== | ====Alternatives==== | ||
Continue to have the relaxed approach like now. | Continue to have the relaxed approach like now. |
Latest revision as of 09:50, 10 October 2014
MagnetoDB RBAC
Launchpad: RBAC
Role based access control of apis.
Problem description
Currently there is no way to control the access to apis. Right now there is a simple check in magnetodb which only checks whether the project present in the user's token is same as the project being used in the URL. In short, to create a table in a project the user needs to have a keystone token scoped to that project.
Proposed change
- Implement role based access control in all apis like all other openstack projects. A file called policy.json would reside in the config directory wherein the magnetodb administrator can specify rules to control access to an api.
- Enforcement of rules is going to be based only on roles and project_ids. It means that we will use project_id and role from keystone token to enforce rules. The rule engine supports a combination of rules through 'AND', 'OR', 'NOT' clause.
- The list of apis which are going to be restricted is:
- create_table
- delete_table
- describe_table
- list_table
- put_item
- get_item
- update_item
- query
- scan
- batch_write
- batch_get
- For e.g. A rule such as this "mdb:create_table": "role:admin" would allow any user with admin role to create table in any project. A rule like "mdb:create_table":"role:admin or tenant:(tenant_id)s". This would enforce the user either to have an admin role or create a table in his project only. A rule like "mdb:create_table": "" would allow everyone to access that api.A rule like "mdb:create_table": "!" wouldn't allow anyone to access that api.
Alternatives
Continue to have the relaxed approach like now.
Security impact
With this change magnetodb would be more secure and administrators would be able to give fine-grained access control to users.
Notifications Impact
None
Other End User Impact
None
Performance Impact
Each time an api call is made to magnetodb, the rule will be checked. As the file policy.json is cached in memory there would be little performance impact.
Other Deployer Impact
Existing deployers of magnetodb can modify policy.json to suit their previous model of authorization.
Developer Impact
None
Implementation
There would be some modification needed in the way context is built. Some more fields need to be added to context. Code for rule checking can be reused from other openstack projects. Appropriate checks for rules have to placed in all api calls.
Assignee(s)
Primary assignee:
<ajayaa>
Other contributors:
<None>
Work Items
- Define rules to enforce.
- List out apis to enforce rules.
- Enforce policy on each api call.
- Mock policy in existing unit-tests to make them pass.
- Write unit-tests for policy.
Dependencies
None.
Documentation Impact
Policy section should be added here http://magnetodb.readthedocs.org/
References
None