Merge "Fuel master access control improvements"
This commit is contained in:
commit
91fff69f1c
158
specs/6.0/access-control-master-node-improvments.rst
Normal file
158
specs/6.0/access-control-master-node-improvments.rst
Normal file
@ -0,0 +1,158 @@
|
|||||||
|
..
|
||||||
|
This work is licensed under a Creative Commons Attribution 3.0 Unported
|
||||||
|
License.
|
||||||
|
|
||||||
|
http://creativecommons.org/licenses/by/3.0/legalcode
|
||||||
|
|
||||||
|
==========================================
|
||||||
|
Fuel Master access control improvements
|
||||||
|
==========================================
|
||||||
|
|
||||||
|
https://blueprints.launchpad.net/fuel/+spec/access-control-master-node-improvments
|
||||||
|
|
||||||
|
In 5.1 release cycle Fuel Master node access control was introduced.
|
||||||
|
In next release, some configuration tuning is required to make it easier
|
||||||
|
to use and upgrade.
|
||||||
|
|
||||||
|
Problem description
|
||||||
|
===================
|
||||||
|
|
||||||
|
With current implementation we have following problems:
|
||||||
|
|
||||||
|
* Each request is validated by middleware using keystone admin token.
|
||||||
|
This method is deprecated.
|
||||||
|
|
||||||
|
* If user changes his password it is not possible to run upgrade.
|
||||||
|
|
||||||
|
* Outdated tokens are not cleaned which in long term
|
||||||
|
may lead to run out of space.
|
||||||
|
|
||||||
|
* No cookies support so some GET requests from UI can not be validated.
|
||||||
|
|
||||||
|
* After login password is stored in browser cache.
|
||||||
|
|
||||||
|
Proposed change
|
||||||
|
===============
|
||||||
|
|
||||||
|
* Create users *nailgun* and *ostf* with admin roles which will be used
|
||||||
|
to authenticate requests in middleware. Both will be added to new
|
||||||
|
*services* tenant.
|
||||||
|
|
||||||
|
* Passwords will be generated by fuelmenu for fresh install and by upgrade
|
||||||
|
script in case of upgrade.
|
||||||
|
|
||||||
|
* During upgrade there will be puppet run for keystone that will add new
|
||||||
|
project and users.
|
||||||
|
|
||||||
|
* Ask user for password before upgrade.
|
||||||
|
|
||||||
|
* Create cron script which runs in keystone container and deletes outdated
|
||||||
|
tokens using `keystone-manage token_flush` command.
|
||||||
|
Script will be run once per day.
|
||||||
|
|
||||||
|
* Add support for cookies, which also will allow to test API from browser.
|
||||||
|
|
||||||
|
* Increase token expiration time to 24h, so it will not be necessary to
|
||||||
|
store password in browser cache.
|
||||||
|
|
||||||
|
* Add two services to keystone: *nailgun* and *ostf*, toghether with endpoints
|
||||||
|
pointing to its urls to enable service discovery instead of hardcoded urls.
|
||||||
|
|
||||||
|
* Use `keystonemiddleware` insted of deprecated `keystoneclinet.middleware`.
|
||||||
|
|
||||||
|
|
||||||
|
Alternatives
|
||||||
|
------------
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
|
Data model impact
|
||||||
|
-----------------
|
||||||
|
|
||||||
|
There will be two new users, two new services and two new endpoints
|
||||||
|
in keystone database.
|
||||||
|
|
||||||
|
|
||||||
|
REST API impact
|
||||||
|
---------------
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
|
Upgrade impact
|
||||||
|
--------------
|
||||||
|
|
||||||
|
During the upgrade user will be asked to give an admin user password.
|
||||||
|
|
||||||
|
Security impact
|
||||||
|
---------------
|
||||||
|
|
||||||
|
Using service user instead of admin_token to verify is safer.
|
||||||
|
|
||||||
|
Notifications impact
|
||||||
|
--------------------
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
|
Other end user impact
|
||||||
|
---------------------
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
|
Performance Impact
|
||||||
|
------------------
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
|
Other deployer impact
|
||||||
|
---------------------
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
|
Developer impact
|
||||||
|
----------------
|
||||||
|
|
||||||
|
When cookies support is added developer will be able to test API from browser.
|
||||||
|
|
||||||
|
Implementation
|
||||||
|
==============
|
||||||
|
|
||||||
|
Assignee(s)
|
||||||
|
-----------
|
||||||
|
|
||||||
|
Primary assignee:
|
||||||
|
skalinowski@mirantis.com
|
||||||
|
loles@mirantis.com
|
||||||
|
|
||||||
|
Work Items
|
||||||
|
----------
|
||||||
|
|
||||||
|
Must have items:
|
||||||
|
|
||||||
|
* Create new users during fresh install and during upgrade.
|
||||||
|
* Ask for admin user password before upgrade.
|
||||||
|
* Remove usage of admin_token in Fuel.
|
||||||
|
|
||||||
|
Rest of the items can be done later and can be done separately.
|
||||||
|
|
||||||
|
Dependencies
|
||||||
|
============
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
|
Testing
|
||||||
|
=======
|
||||||
|
|
||||||
|
All tests from previous blueprint should still apply here.
|
||||||
|
System tests may require changes to pass the password to the upgrade
|
||||||
|
script.
|
||||||
|
|
||||||
|
Documentation Impact
|
||||||
|
====================
|
||||||
|
|
||||||
|
Documentation describing internal architecture should be created.
|
||||||
|
It should contain examples how to use curl with API.
|
||||||
|
|
||||||
|
References
|
||||||
|
==========
|
||||||
|
|
||||||
|
None
|
Loading…
Reference in New Issue
Block a user