Currently, there is no enforced access control to the Fuel UI.
Anyone with access to network can create, change and delete environment.
At a minimum, this requirement could be fulfilled by a login/password when connecting to the Fuel UI. If implemented in this manner, additional requirements will be needed:
- Ability for a user to set / change their own password
- Default admin/admin
- Should be configurable in fuelmenu
More advanced options:
- Secure/Encrypted storage of passwords (potentially on the Fuel Master Node)
- A more advanced feature would be integration with an external authentication source (e.g. Active Directory, LDAP)
- A “super user” account that can create additional accounts - but these additional accounts cannot create more users
- A better implementation would be to have Role Based Access Control and have “super user” as a role that can be assigned to one or more users
- This may lead, in the future, to a more granular RBAC - e.g. ability to view but not take actions, restriction to specific environments, etc.
- Ability for a “super user” to change a user’s password and/or disable/remove an account
- Read only mode
Use Keystone as authorization tool.
- it can be used with LDAP or AD
- supports authorization via tokens
- support scopes, and groups of users
- has good written api with many functions like getting accessible endpoints for user
- has api easy for consumption
- has implemented events system that we can use in future for additional monitoring
- has implemented multifactor authentication (can be used with external systems)
- all apis that we need for future managing groups, roles, users and project are created
- for UI we can base our solution on horizon solution
- keystone will be also used by Ironic project
- need to run in separate container/process
- next external dependency
- may be overkill
We tested keystone with postgresql, it’s working. We tested it via console: create (user, role, tenant, endpoint) add role, get token, list(role, user, tenant) and also we used api to: get user info, get token, operations via v3 api
- install in nailgun container
- run script for creating separate db in postgresql container
- make available ports for keystone
- create base configuration
- in nginx allow connection to keystone
- login page
- logout button
- create new container for keystone
- create service user for OSTF
- Try to use keystone middleware, for api and api v1
- for node agent we should run separate webpy app without middleware
- Add authorization credentials to all requests
- use keystone token in auth header
- add handling of 401
- change password page
- create backup script for db
Write everything by yourself or use some existing components:
we need to write user model and apis for creating and managing: user, groups etc oauth, in this case we can reuse some existing libs like oauth2 for creating and consuming tokens. Oauth will be easy to use with clients and node authorization Maybe we can also use sessions for UI to persistence user token
- full control
- possibilities to write good oauth2 authorization easy to use also with nodes
Use basic auth in nginx
New database for keystone is required
Keystone API will be used
Fuel will be safer now. It will protect users against unauthorized access. All actions will require authorization.
Keystone can log all requests to log file.
Password for postgresql should be generated and access from remote locations should be blocked.
External connections to cobbler and rabbitmq should be allowed. But passwords should be changed to the same as for API even in first version, if possible. In future versions we’ll be able to transfer options for bootstrap node. So we should generate bootstrap ssh key during master node installation. And use password-protected API for nailgun agents.
There will be new container with keystone installed.
Unit tests and functional tests are required.
It should be described how to change password and where it’s required.