techcobweb
commented
3 weeks ago @jadecarino @aashir21 I spoke to @hobbit1983 and he made the point that all CPS properties should be protected from regular non-admin users. We should be encouraging users to use overrides if they want to change anything, and let the CI/CD pipelines maintain the CPS properties using config as code, or at least only let admins change CPS properties. I agree. Story text above changed to reflect that.
Story
As a galasa service admin I can set a role for a particular user as
defaultoradmin, and some actions are possible by admin users, and some are not possible if a user only has a default role, so that my system is more protected from damage by regular galasa service users.Background
The aim of this story is to create functions within the framework code and REST APIs which have hard-coded responses for default and admin user roles, which control some actions, and adding a user role field to the user record. ie: A few fixed roles which can't be edited.
Levels of role:
A
defaultuser has the least amount of privilege.An
adminuser has the highest level of privilege. They can do anything that Galasa supports.Some admins are on an 'initial-admin' list, maintained at the kubernetes level. Such users can't be demoted to non-admins without the kubernetes configuration being altered. It that sense they are 'protected admins' but still have normal admin rights.
We played with the idea of having a different role to represent these 'protected admin' people, like 'owner' or similar, but it just makes things more complex when it comes to special-casing what such people can do.
How does the first user get admin access ?
We have the problem in that how do we know who to set up as the first admin user, so they can grant admin privileges to other admin users ?
ways we could go:
admin. After that point they can anoint whoever they wish as other admins.Promoting someone to be an admin/ Recovering a system
It may be that the admin of the system has left the company or no longer works with the real responsibility associated with the ownership. It may be that there are no active administrators on the system doing the actual admin tasks. In such cases, how do you 'anoint' someone with admin rights ?
You get this situation when you first install the Galasa service. There are no administrators.
To create a system
adminyou need to do this:Demoting someone who is an initial admin to be a regular user
adminwith admin rights stilladminroleDeleting administrators
Any admin can delete an admin. If the user deleted is on the initial-admin list still, and the user logs in again, they will be set up as an admin.
If they are first removed from the initial-admin list config map, then deleted, they will be set up as a default user like everyone else when they next log in.
You can delete an init-admin, just like you can delete an admin, but you can't stop someone being an admin if they are on the initial-admin list without first changing the config map to remove them from that list.
Tasks
[ ] Any user logging in first time is created as a
defaultuser.[ ] When a user logs in:
[ ] Function in API server code returns a list of available roles on the system in total
[ ] Function in API server which gives a list of roles that a specific user can be assigned. To do this, the list of initial-admins is consulted, and if the user is on the list, they can only ever be an admin role.
[ ] Function in the API server to get a list of actions which a user can perform.
[ ] If a user role does not exist in a couchdb document, then it gets upgraded to have the role field with
defaulta user value[ ] Every time a user record is read within the API server, if the user exists in the list of initial-admins available in the configmap passed from the helm chart, then the role of that user will always be set to
adminbefore it gets returned on any API. In couchDB their record will be set to being anadmin. So in this way the list of admins can be managed by the helm values, and the kube systems admin. Doing it this way will mean that if the last admin on the system deletes themselves, or leaves the company, there is a way of anoint a new admin, though it will mean changing a config map and recycling the api server, then getting that user to log in again.For example:
[ ] User record contains a role, which travels from the web UI through the API/Framework into being stored in couchdb.
[ ] Web UI:
[ ] CLI
rolefield.defaultoradmindefaultoradmin[ ] Only an admin can list the tokens for other users.
[ ] Only an admin can delete a token of another user.
[ ] Only an admin can set a CPS value (all namespaces are protected) This is opinionated such that we are encouraging configuration as code to be used.
[ ] Only an admin can update the role field
[ ] Only an admin should be able to delete a user
[ ] Changing the role of someone who is on the initial-admin list to be a non-admin is rejected, because to do that they first need to be removed from the initial-admin list in kube.
[ ] Documentation to add to the 'how to install the ecosystem' which may not exist in much detail yet.
[ ] The system will not permit a user to delete themselves. This makes it less likely that the last administrator on the system will be lost.
[ ] Decide whether only admins should be able to delete test runs or not. @hobbit1983 thinks that deleting test runs should be an admin-only thing, but I'm not so sure.