-
Notifications
You must be signed in to change notification settings - Fork 4.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix project creation with robot account #14754
Conversation
Codecov Report
@@ Coverage Diff @@
## master #14754 +/- ##
==========================================
- Coverage 66.80% 66.80% -0.01%
==========================================
Files 928 928
Lines 76089 76095 +6
Branches 2253 2253
==========================================
- Hits 50833 50832 -1
- Misses 21316 21323 +7
Partials 3940 3940
Flags with carried forward coverage won't be shown. Click here to find out more.
|
I don't think this is the correct way to assign the creation permission of the project to the robot account. Please use ( |
@heww this is not a problem with the actual permission. the rbac check already has passed. at this point the owner of the project is searched. if the current user it is not a solution user, we search for the current authorized user in the user table! but a robot account is not a regular user so the api always repsonds with a "user not found" error. also a robot account does not has a uid, so we have to assign a fix uid (i assigned the admin uid). |
Thanks, I got your point. |
src/server/v2.0/handler/project.go
Outdated
@@ -156,10 +156,10 @@ func (a *projectAPI) CreateProject(ctx context.Context, params operation.CreateP | |||
// set the owner as the system admin when the API being called by replication | |||
// it's a solution to workaround the restriction of project creation API: | |||
// only normal users can create projects | |||
if secCtx.IsSolutionUser() { | |||
ownerName := secCtx.GetUsername() | |||
if secCtx.IsSolutionUser() || strings.HasPrefix(ownerName, config.RobotPrefix(ctx)) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please try to use the security context name to check that the request is from a robot account.
if secCtx.IsSolutionUser() || secCtx.Name() == "robot" {
ownerID = 1
}
@heww i change the code using the security context name for checking if the current user is a robot acocunt |
Hi, @phin1x thanks for your update. We discussed this PR today and there may need more update for it. The project-level robot account can create a project when every authorized |
@heww if think is is already done via the rbac system. project level robot accounts have subjects with a "/project/" prefix, system level robot accounts have subjects with a "/system/" prefix. at the moment, you cannot mix project and system level permissions in a robot account, as we discused in other issues (#14512 (comment)). Since the rbac subject for creating projects is "/system/project", a project level robot account will never be able to create projects. |
There is an option to allow everyone to create the project, everyone is the default value for this option in the harbor. When this option is everyone, a project-level robot can create a project. |
i looked in the code and, yes, you are right. now harbor always checks the permissions when creating a project from a robot account. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
src/server/v2.0/handler/project.go
Outdated
log.Errorf("Only sys admin can create project") | ||
return a.SendError(ctx, errors.ForbiddenError(nil).WithMessage("Only system admin can create project")) | ||
} | ||
|
||
// always check if robots have permissions to create projects |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if !onlyAdmin {
if it's a project level robot {
return errors.ForbiddenError
}
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is there a method to check, if the robot acocunt scope is system or project level? i didn'd saw something like a getLevel method.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@heww is it better to use Can
to define whether it's a system level robot?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or here we can leverage the robot name to query robot, there is an attribute to indicate robot scope.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the robot context have a isSystemLevel property, but it was not exported. i exported the property with a getter and used that getter.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Another trick way, as the robot name has a pattern, the project level name should be {projectname}+robotname, which is difference with system level robot. And +
is illegal character when to issue a new robot, so here we can use whether contains +
to judge.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
imho using a character to identify if a robot is system or project level is not a good idea. if you set the robot prefix for example to "robot+" the check will fail. the robot security context already has a property which identifies if a robot is system or project level so why not use it?
@wy65701436 i updated the check if the robot account is system level |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
please reslove all the review comments before merging.
fd76830
to
f67197f
Compare
@wy65701436 any updates? |
@phin1x can you rebase the PR to resolve the conflict? |
Signed-off-by: Fabian Weber <[email protected]>
Signed-off-by: Fabian Weber <[email protected]>
Signed-off-by: Fabian Weber <[email protected]>
Signed-off-by: Fabian Weber <[email protected]>
Signed-off-by: Fabian Weber <[email protected]>
Signed-off-by: Fabian Weber <[email protected]>
Signed-off-by: Fabian Weber <[email protected]>
Signed-off-by: Fabian Weber <[email protected]>
f67197f
to
6e04ea8
Compare
@wy65701436 i rebased the pr |
we tried to create projects using a robot account, but the api call always fails with the message "user robot$ not found". it turns out that harbor is trying to get the id of the current authorized user when that user is not a "solution user". since a robot account is not a regular user, the api call always aborts with the error "user not found".
this pr fixes the issue by checking if the current authorized user starts with the robot prefix. if thats the case the owner id is set to one.
Related issues: #14145