Skip to content

Update "globally_allowed" to "global_allowlist_in_use"

Kenneth Chu requested to merge kenneth-global_allowlist_log_field_name into master

What does this MR do and why?

In a recent ticket I worked with a customer, I investigated the logs to see why a git request was failing from our hosted runners. I initially saw the following field:

    "json": {
      "message": "Attempting to access IP restricted group",
      "meta.root_namespace": "REDACTED",
      "severity": "INFO",
      "globally_allowed": true,            <- HERE      
      ...

And thought that the IP address was allowed via the global allowlist.

Only much later did I realise, there was another similarly named field in the log, which was the actual field I was concerned with:

    "json": {
      "message": "Attempting to access IP restricted group",
      "meta.root_namespace": "REDACTED",
      "severity": "INFO",
      "globally_allowed": true,
      ....    
      "allowed": false,               <- HERE
      ....

Digging into the code, it would seem to me that globally_allowed only states if a global allowlist is in use, rather than if the IP was actually allowed in the global allowlist.

This MR seeks to clarify that distinction by making the field name more descriptive.

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.

Comparison

Before:

{
  "severity": "INFO",
  "time": "2024-07-11T05:52:21.900Z",
  "correlation_id": "01J2G5K397268B8WQDHFGDSB1R",
  "meta.caller_id": "Repositories::GitHttpController#info_refs",
  "meta.remote_ip": "REDACTED",
  "meta.feature_category": "source_code_management",
  "meta.user": "usera",
  "meta.user_id": 2,
  "meta.project": "restrict-group-ip/project",
  "meta.root_namespace": "restrict-group-ip",
  "meta.client_id": "user/2",
  "message": "Attempting to access IP restricted group",
  "group_full_path": "restrict-group-ip",
  "ip_address": "REDACTED",
  "allowed": false,
  "globally_allowed": true
}

After:

{
  "severity": "INFO",
  "time": "2024-07-11T05:55:12.199Z",
  "correlation_id": "01J2G5R9H4AWW28C614Z8B37RJ",
  "meta.caller_id": "Repositories::GitHttpController#info_refs",
  "meta.remote_ip": "REDACTED",
  "meta.feature_category": "source_code_management",
  "meta.user": "usera",
  "meta.user_id": 2,
  "meta.project": "restrict-group-ip/project",
  "meta.root_namespace": "restrict-group-ip",
  "meta.client_id": "user/2",
  "message": "Attempting to access IP restricted group",
  "group_full_path": "restrict-group-ip",
  "ip_address": "REDACTED",
  "allowed": false,
  "global_allowlist_in_use": true
}

How to set up and validate locally

Begin with an administrator user.

  1. Add a global allowlist. For example: 1.1.1.1
  2. Create a new Group, and add a Group IP Allowlist. For example, 2.2.2.2
  3. Create a new Project under the group (tick the Initialize repository with a README option).
  4. Add a non-admin user to the project.
  5. Clone the project as the non-admin user. It should return this error message:
remote: The project you were looking for could not be found or you don't have permission to view it.
  1. Check logs under /var/log/gitlab/gitlab-rails/auth_json.log if the field name has been updated.

Merge request reports