add proposal for robot permission expansion #249
Conversation
Signed-off-by: wang yan <[email protected]>
wy65701436
force-pushed
the
robot-extend
branch
from
5ee1671
to
3e07e2d
Compare
| Add a new column of creator for table robot. | ||
|
|
||
| ``` | ||
| ALTER TABLE robot ADD COLUMN IF NOT EXISTS creator varchar(255); |
There was a problem hiding this comment.
IMO more details are needed for the value of this column, how to differentiate a user from a robot account?
There was a problem hiding this comment.
Since the creator is identified by the full name of either a Harbor user or a robot account, and robot account names include a unique prefix, it allows easy distinction between robot accounts and human users.
|
|
||
|  | ||
|
|
||
| ## Data provider |
There was a problem hiding this comment.
Will we need to make update to the security context of a robot to list the permissions? Otherwise how do we ensure there's no elevation when a robot account is calling API to create another robot account?
There was a problem hiding this comment.
The API handler knows that the current user is a robot. With this knowledge, it can determine both the scope of the creator and the scope of the robot. The handler then decides whether to proceed based on the comparison of these scopes.
| 3. The creation and deletion of robot accounts will be recorded in the audit log. | ||
| 4. As a system administrator, I can identify the creator of each robot account by performing an SQL query in the database. | ||
| 5. A robot account can create another robot account, but the new account’s scope must be less than or equal to that of the creator. | ||
| 6. A robot account created by another robot can only be updated or deleted by either the human with the relevant permissions, the creator of the robot account, or the robot account itself. |
There was a problem hiding this comment.
I wish to suggest in addition to the items in user story, we should zoom into the scenario where robot account managing robot account, b/c this is where the most requirement come from and there are quite a few technical decisions we made that should be documented for discussion with other maintainers and for reference in future
There was a problem hiding this comment.
I will add a separate section for the robot that created by another robot.
Signed-off-by: wang yan <[email protected]>
| 2. any system level robot account can be created by a system level robot account who with the robot creation permission. | ||
|
|
||
| Deletion/Update: A service account cannot assign permissions to another service account that exceed its own permissions. | ||
| 1. any robot account that created by another robot can be updated by the creator robot or the itself. |
There was a problem hiding this comment.
By "the itself" do you mean "itself"?
Are you saying a robot account can remove itself even if it doesn't have permission to delete "robot account"?
How does it work before we allow a robot account to create a robot account?
There was a problem hiding this comment.
yes, I mean only when the creator has the permission of robot account deletion can delete the created robot.
As for the robot that created by another robot,
- any human/system level robot with the relevant permission can remove it.
- if the creator has the robot deletion permission, it can remove the created robots.
- if itself was granted the robot deletion permission when it was created, it can remove itself.
| 2. The creation and deletion of robot accounts will be recorded in the audit log. | ||
| 3. As a system administrator, I can identify the creator of each robot account by performing an SQL query in the database. | ||
| 4. A robot account can create another robot account, but the new account’s scope must be less than or equal to that of the creator. | ||
| 5. A robot account created by another robot can only be updated or deleted by either the human with the relevant permissions, the creator of the robot account, or the robot account itself. |
There was a problem hiding this comment.
- When a robot account updates a robot account that it created, we should also make sure there's elevation.
- I don't quite understand why we wanna limit the deletion. If a system-level robot account has the permission to delete a robot account, why we don't allow it to delete any other robot account? Isn't this model a little easier to understand?
There was a problem hiding this comment.
1, limitation of updating is the same as creation.
2, as for the system level robot, it can remove any other robots if it has the relevant permission.
Signed-off-by: wang yan <[email protected]>
Signed-off-by: wang yan <[email protected]>
| 2. any system level robot account can be created by a system level robot account who with the robot creation permission. | ||
|
|
||
| Deletion/Update: A robot account cannot assign permissions to another robot account that exceed its own permissions. | ||
| 1. any robot account that created by another robot can be updated by the creator robot or the itself, provided that the update permission has been granted to the creator or the robot itself. |
There was a problem hiding this comment.
the itself should be itself
| ## Robot accounts that are created and managed by another robot accounts | ||
|
|
||
| Robot accounts are principals, it means that you can grant robot account to Harbor resources. However, from the perspective of preventing privilege escalation, generally, a robot account | ||
| cannot grant roles that are higher or more powerful than the roles it possesses. When a robot account creates a new robot account, the new robot account doesn't automatically inherit any roles |
There was a problem hiding this comment.
replace role with permission, avoid using role because the role is only used in project member,
Signed-off-by: wang yan <[email protected]>
No description provided.