Provide access control for Senlin resource
We need to implement privilege management mechanism in Senlin to provide access control of Senlin resources, like cluster, node. It will decide what kind of actions a user can do to a resource and allow user to share or change owner of the resource they own. The basic idea is a framework similar to Linux privilege management: e.g. the owner can show, delete and update a cluster; the user in the same group can only show the cluster; users belong to other groups even can't see this cluster. We hope to implement this support based on keystone project/role mechanism.
Blueprint information
Related branches
Related bugs
Sprints
Whiteboard
Some Questions:
- Is it about permission rather than privilege?
- Do we have to create a new keystone project for each cluster?
- To which domain will these new projects belong?
- Nodes that don't belong to any cluster would be accessible to any users?
- What are the rights to be managed? Do we differentiate list/get from update/delete?
- If only owner can do an update, then all webhooks will have to be created for that account?
Answers:
- Yes, seems permission is more accurate;
- We need an *object* to represent the target resource we want to perform permission control with. This *object* can be the cluster itself or any other things we can define and use. But if we want to rely on keystone to provide all underneath support(e.g. role management, authentication), this object should be a keystone aware object(e.g. project, user). Since project_id has been widely used in current policy check process and different user can have different roles in the same project, it seems to be a proper element for this use case. Of course we can build the permission system without keystone's support. We can make a further discussion about this.
- A specific domain I guess
- Nodes that don't belong to any cluster can only be accessed by its owner(user's project_id is target project_id)
- I'm not very sure about this. My original idea is managing all access to a cluster, including list,get,delete and update since I think a user should not be allowed to get any information of a cluster that he didn't get sharing from the owner.
- So, I think normal user in the same group as owner should be allowed to do any operations to the cluster, except the *sharing operation*.
BTW, about webhook, I think we can split the progress of *creating webhook* and *bonding webhook to a cluster*.Any user can create webhook freely, but they can only bond the webhook to the cluster they can access.
https:/
Keystone has plan to support dynamic RBAC Policy. This is very helpful to for controlling access to resource in RESTful API level. A place it doesn't cover is per-resource access control. Maybe this is Senlin need to provide(e.g. from DB level) to complete the access control chain.
