Skip to content

Add new internal users endpoint

Bishwa Hang Rai requested to merge 9770-create-new-users-internal-endpoint into master

What does this MR do and why?

  • Adds new internal users endpoint to be user by CustomersDot
  • Creates new entity ::GitlabSubscriptions::API::Entities::Internal::User to keep the exposed fields minimalistic
  • Currently we only need: [:username, :web_url]
    • Thus, extended ::UserSafe with :web_url
  • The other usage of public api: /api/v4/users/:id is during registration in CustomersDot

Rationale

The issue linked https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/9770+ has bit more context.

I will try to give an overview of overall "Cells" project for Fulfillment/CustomersDot:

  1. With Cells architecture, Admin PAT will be different for different organization in different Cells
  2. This means our current usage of Admin PAT will not work to communicate internally from CustomersDot to GitLab
  3. Thus, we will change the authentication approach for these internal calls from CustomersDot to GitLab.
    1. More on historical discussion on internal endpoints auth for CDot: https://gitlab.com/gitlab-org/gitlab/-/issues/444323
  4. We plan to use either 'shared-secret token' or 'JWT based token' for authentication moving forward
    1. The PoC MR is waiting review from security team before we decide on which to use.
  5. In the meantime, we want to migrate all possible internal calls from CDot to GitLab under the internal/ namespace and GitlabSubscription module.
  6. This makes us easier change the authentication on next step, after the approach has been decided (Ref point 4)
    1. Path based routing will be enabled only for these endpoints in first iteration of Cells.
    2. Some example MRs related to similar effort:
      1. !156458 (comment 1954433851)
      2. !156602 (comment 1959186354)
  7. The overall EPIC for the migration of endpoint and start using new authenticatin system is: https://gitlab.com/groups/gitlab-org/-/epics/14078+

MR acceptance checklist

Please evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

How to set up and validate locally

  1. Checkout this branch in gdk and run the server locally

  2. Go to CustomersDot and open up console bin/rails c

  3. Run following query

    [11] pry(main)> Client::GitlabApp.get("/api/v4/internal/gitlab_subscriptions/users/1", { token: Client::GitlabApp::ADMIN_API_TOKEN })
=> {"id"=>1, "username"=>"root", "name"=>"Administrator", "web_url"=>"http://gdk.test:3000/root"}
[12] pry(main)>

Alternatively, use the curl command from documentation:

curl --header "PRIVATE-TOKEN: <admin-token>" "http://gdk.test:3000/api/v4/internal/gitlab_subscriptions/users/1"

Related to https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/9770+

Edited by Bishwa Hang Rai

Merge request reports