NXD lib:gitlab:auth Accept Basic auth from project runner_token

From gitlab 8.12 there is new CI job permissions model which only accept login
from ci token for running job. Then the access is revoked after the job is finished.
In Nexedi, when have a lot of URLs which rely on gitlab-ci-token and project-runners-token, so
we need to re-allow access else access to all those URL will be refused.

More info are here: https://docs.gitlab.com/ee/user/project/new_ci_build_permissions_model.html#before-gitlab-8-12

lib/gitlab/auth.rb

@@ -179,16 +179,22 @@ module Gitlab
         return unless login == 'gitlab-ci-token'
         return unless password
 
-        build = ::Ci::Build.running.find_by_token(password)
-        return unless build
-        return unless build.project.builds_enabled?
-
-        if build.user
-          # If user is assigned to build, use restricted credentials of user
-          Gitlab::Auth::Result.new(build.user, build.project, :build, build_authentication_abilities)
+        # XXX-nxd: we also accept runners_token if enabled on projects
+        project = Project.with_builds_enabled.find_by(runners_token: password)
+        if project
+          Gitlab::Auth::Result.new(nil, project, :ci, build_authentication_abilities)
         else
-          # Otherwise use generic CI credentials (backward compatibility)
-          Gitlab::Auth::Result.new(nil, build.project, :ci, build_authentication_abilities)
+          build = ::Ci::Build.running.find_by_token(password)
+          return unless build
+          return unless build.project.builds_enabled?
+
+          if build.user
+            # If user is assigned to build, use restricted credentials of user
+            Gitlab::Auth::Result.new(build.user, build.project, :build, build_authentication_abilities)
+          else
+            # Otherwise use generic CI credentials (backward compatibility)
+            Gitlab::Auth::Result.new(nil, build.project, :ci, build_authentication_abilities)
+          end
         end
       end
 

[Jérome Perrin]

@alain.takoudjou so that I understand correctly, before the patch, gitlab-ci-token can only be used if there's already a test running ( the ::Ci::Build.running.find_by_token(password) check ). After the patch we make this token usable even if no build is currently running.

I was thinking if it's possible to update testnode to fit in gitlab's security model, but that does not seem so easy because in our architecture testnode watch repository and if it find changes it starts tests. But with gitlab model the test needs to be started to be able to access CI token.

Maybe we could also not rely on gitlab-ci-token magic token and create actual gitlab user for protected projects (one per project) then we don't have to patch, do we ?

[Kirill Smelkov]

@jerome, just for the reference: if I recall correctly we introduced gitlab-ci-token instead of nxdtestbot user whose password was leaked. In a sense gitlab-ci-token is already a "virtual per-project user" automatically created by lab system. Do we want to drop this automation and ask people to create users by hand? My prediction is that it will return to nxdtestbot style era with corresponding security implications.

Appologize if I misunderstood something, as I grasped hereby patch and your message only briefly.

[Jérome Perrin]

Thanks for feedback @kirr yes, that would be the problem with this approach. At this point it's just an idea, we are evaluating options. Having to maintain patches on the authentication system complexifies updates and also has security implications (the patches looks OK, but in theory they can introduce a vulnerability), so we are considering possible alternatives to this patch.

Also thinking more about it, we should try harder to use existing ci permission system. I was very fast in saying we cannot use it.

[Kirill Smelkov]

@jerome, thanks for feedback. Yes carrying on patches has its own weight and risks. I just wanted to highlight the cons of the alternative approach to make sure the decision of which way to go is balanced and well thought.

[Jérome Perrin]

@kirr yes, thanks it's useful and always appreciated

[Jérome Perrin]

( the feedback I mean )

[Kirill Smelkov]

@jerome, thanks, you are welcome.

[Alain Takoudjou]

Maybe we could also not rely on gitlab-ci-token magic token and create actual gitlab user for protected projects (one per project) then we don't have to patch, do we ?

I understand the needs, the advantage with gitlab-ci-token is that we can easily generate a new token and virtual user creation is automated for each project like @kirr said.

The proper solution is to allow testnode to create running job and use the token for authentication but I don't know how hard it will be to make testnode compatible ?

If we go in the way to create a real user to replace gitlab-ci-token, I think we can create only one user for testnode, then add it as member of projet when required to launch test ? So it will be easier to maintain the user and update password.