Draft: [skip ci] Record audit events when GitLab Duo for Slack is turned on or off

Thomas Schmidtrequested to merge
duo/slack-duo-group-audit-events into duo/slack-duo-group-marketplace-picker

What does this MR do and why?

Choosing where GitLab Duo runs decides whose settings and credits a whole Slack workspace uses, so an Owner or administrator who does it should leave a record that the group's audit log can show. This MR adds two audit events, slack_duo_group_enabled and slack_duo_group_disabled, recorded in the group with the person who did it and the Slack workspace. Without them nobody could later answer "who moved GitLab Duo for our Slack workspace?".

It builds on !262161 (closed). The flag stays off by default, and this MR must land before the flag moves from wip to beta.

What's in it

  • Two audit event types (ee/config/audit_events/types/), saved to the database and streamable, scope Group. The audit events documentation is regenerated.
  • EnableService records an event for a new claim. A repeated enable, a refused claim, and a claim undone because the Slack flow could not be provisioned record nothing.
  • DisableService records an event when the choice is removed. Moving GitLab Duo through the Admin area records one disable in the previous group and one enable in the new group.

Where this fits

This is one of a stack of merge requests. Each one targets the branch of the one before it, so review and merge them in this order. Audit events and the documentation follow as separate merge requests.

  1. !261830 (closed): Table and model
  2. !261845 (closed): Services to turn GitLab Duo on or off
  3. !262156 (closed): Endpoint and page data
  4. !262157 (closed): Mention path
  5. !262158 (closed): GitLab Duo section on the integration page
  6. !262159 (closed): Claim on the first group install
  7. !262160 (closed): Admin area picker (self-managed)
  8. !262161 (closed): Slack Marketplace install page
  9. !262165 (closed): Audit events (this MR)
  10. !262171 (closed): Documentation

Plan and decisions: #633566. Rollout of the feature flag: #633582. Design discussion: gitlab-org#23704.

Context for review agents
  • Goal: every GitLab Duo session started from a Slack workspace runs and bills in one top-level group chosen by an Owner (the administrator on self-managed for an instance-wide install), instead of each user's default Duo namespace. Plan: #633566.
  • Everything is behind the default-off slack_duo_group feature flag (type wip, becomes beta before rollout, rolled out per top-level group). The Slack flow has its own flag slack_duo_api_flow; DuoGroup.available? requires both for the same group.
  • Deliberate decisions, do not flag them unless you find a real defect:
    • One Duo group per workspace (team_id unique), one group can run several workspaces. No organization_id column: namespace_id is the single sharding key. The unique index on team_id holds per cell only, tracked in #633611.
    • A group install claims the workspace, a project install does not. Copies of group or instance installs (inherit_from_id) never let a group claim a workspace. A workspace installed for the whole instance (self-managed only) is the administrator's to assign.
    • An unclaimed workspace has no fallback to the user's default namespace once the flag is on: the user gets a reply that says who can set it up.
    • A Duo group always runs the Slack API flow (slack_assistant/v1), the Developer flow is out. Members of the Duo group only, also on self-managed. Guests pass the membership check and are blocked later, documented as not supported for now.
    • Audit events for enable and disable come in a separate small MR before the flag leaves wip.
  • Test world for manual validation: #633566 (comment 4012898135).
  • Please look hard at: that no event is recorded for idempotent or refused calls, and that target_details never contains anything but the workspace name and ID.
  • The event types follow ee/config/audit_events/types/disable_ai_catalog_flow.yml.

References

Screenshots or screen recordings

None: the events show in the group's audit events list.

How to set up and validate locally

  1. Seed the test world (users, groups and fake Slack installs in every state, no Slack needed): #633566 (comment 4012898135). Run it from your gitlab directory:

    bin/rails runner -e development seed_duo_slack.rb

    It also enables the slack_duo_group, slack_duo_agent and slack_duo_api_flow feature flags. Run it again at any time to reset all GitLab Duo state.

  2. Open bin/rails console and turn GitLab Duo on and off for sd-a, then read the audit events:

    duo = Integrations::SlackWorkspace::DuoGroup
duo.where(team_id: 'T0WWA').destroy_all
call = ->(service, path, user) do
  Integrations::SlackWorkspace::DuoGroups.const_get(service).new(
    group: Group.find_by_full_path(path), current_user: User.find_by_username(user), params: { team_id: 'T0WWA' }
  ).execute
end

call.(:EnableService, 'sd-a', 'sd-owner')
call.(:EnableService, 'sd-a', 'sd-owner')   # again, records nothing
call.(:DisableService, 'sd-a', 'sd-owner')

group = Group.find_by_full_path('sd-a')
AuditEvents::GroupAuditEvent.where(group_id: group.id).order(:id).last(2).each do |e|
  puts [e.author.username, e.details[:event_name], e.details[:custom_message], e.details[:target_details]].inspect
end

    Expected:

    ["sd-owner", "slack_duo_group_enabled", "Turned on GitLab Duo for a Slack workspace", "Workspace T0WWA (T0WWA)"]
["sd-owner", "slack_duo_group_disabled", "Turned off GitLab Duo for a Slack workspace", "Workspace T0WWA (T0WWA)"]

  3. Optional, if your GDK has a license with audit events: turn GitLab Duo on and off from the integration page as sd-owner (see the UI MR) and open http://gdk.test:3000/groups/sd-a/-/audit_events. Each change shows as an event.

MR acceptance checklist

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

Edited by Thomas Schmidt

Merge request reports