Include username in Gitlab.com access log

Problem to solve

Currently, Gitlab.com disable access from a certain IP address when repeated failed logins are detected. The logs at Gitlab.com, however, do not include the username used in such logins. As a result, the customer is not effectively able to narrow down the cause of the failed logins.

Intended users

Any Gitlab.com customer

Further details

Including the username in the log should save Gitlab Support a large amount of time. For example, support issue #123000 ended up with almost two days of back and forth between Support and the customer. The customer could have been able to narrow down the cause right away if the username were available.

Proposal

Include the username in the logs

Permissions and Security

This feature should only be available to the Gitlab.com internal personnel including Support

Documentation

Testing

What does success look like, and how can we measure that?

Links / references

To do

• Check behavior on production:
  • Auth.log: https://log.gitlab.net/goto/e4b7365fc2be37fc5b61d24c1d94dbce
  • Throttle events: https://log.gitlab.net/goto/b42bf432a0fb2748b0efa6fe6120c34a
  • Blacklist events: https://log.gitlab.net/goto/e96b65f9cee705e0a3c8944a9f7d1610
• Confirm IP addreses are no longer being logged on user_id and logs are ingested correctly by elastic search. https://gitlab.com/gitlab-org/gitlab-ce/issues/62756#note_196118941
• Move protected paths throttle from Omnibus to GitLab rails - #29952 (closed)
• Update protected paths documentation - !16540 (merged)
• Update auth.log documentation - !18211 (merged)

Development Log

• An MR adding the user information on auth.log was merged gitlab-foss!29821 (merged)
• While exploring the logs on Kibana, we noticed that for Rack Attack blocking events, the Rack Attack discriminator was not being populated hence showing the user_id as NULL.
  • An MR was created to limit the user information to Rack Attack throttles: gitlab-foss!30467 (merged)
  • A follow-up issue was created to also include the user information on Rack Attack blocking events gitlab-foss#64278 (moved)
• It was noticed that GitLab.com does not have RackAttack options activated by default, so it's not going to log user information - gitlab-foss#62756 (comment 189975231)
  • They can't be enabled because they lead to erroneous blocks.
  • Rack Attack throttle it's only active on Omnibus for the protected paths - https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/files/gitlab-cookbooks/gitlab/templates/default/rack_attack.rb.erb
    • Which is what is being currently logged, but that information does not have the current_user
• It appears that some RackAttack events are also logged in the codebase:
  • https://gitlab.com/gitlab-org/gitlab-ee/blob/master/lib/gitlab/auth.rb#L99-118
  • They do not include user information.
• It was reported they were wrongly logged, ip was being populated with the wrong information.
  • gitlab-foss!30467 (merged) fixes that problem
• We've decided to move 'protected paths' throttle into GitLab Rails - #29952 (comment 215825631)
  • Omnibus configuration is going to be deprecated on %12.4 and removed on %13.0 - omnibus-gitlab#4688 (closed)