Restrict Duo Agent Platform job logs to Developer and above

What does this MR do and why?

Duo Agent Platform (DAP) flows run as CI jobs in pipelines with source duo_workflow. The executor prints the flow's final message to the job log. On public projects with public pipelines, anyone can read that log, including anonymous users. It can contain content the flow posted as an internal note, such as Duo Security Review findings. The agent session page already requires the Developer role.

This MR adds a duo_workflow_job condition to Ci::BuildPolicy. It prevents :read_build_trace for those jobs unless the user has the Developer-level _read_developer_job_artifact permission. It uses that permission instead of update_build, because archived projects lose update_build. The policy is checked on every read, so logs of jobs that already ran are covered too.

What this covers:

  • The job page log, the trace and raw endpoints, and /-/jobs/:id/artifacts/download?file_type=trace.
  • REST GET /projects/:id/jobs/:job_id/trace.
  • GraphQL CiJob.trace.
  • The MCP get_job log.
  • Duo Troubleshoot job (troubleshoot_job_with_ai depends on :read_build_trace).

Impact

  • Anonymous users, Guests, Planners, Reporters and Security Managers can no longer read logs of DAP jobs. They still see the job, its status and the pipeline.
  • Jobs from other pipeline sources are unchanged.
  • Custom flow triggers also run with source duo_workflow, so their logs are restricted too.
  • Restricted users see the existing "The current user is not authorized to access the job log." alert, the same as debug-mode jobs.

Out of scope (follow-ups)

  • Restricting artifacts of DAP jobs. This needs changes in Ci::BuildPolicy and Ci::JobArtifactPolicy, so it is a follow-up MR. !260132
  • Hiding the "View raw" button for users who can't read the log. ()

References

Screenshots or screen recordings

Before After

Anonymous user sees the full DAP job log

image.png

Anonymous:

Jobs page loads but shows authorisation error ✅ image.png

The raw log page shows a 403 ✅

image.png

Trace url returns 401 ✅

image.png

GraphQL as an anonymous user returns "trace": null ✅

curl -s http://gdk.test:3000/api/graphql -H 'Content-Type: application/json' -d '{"query":"{ project(fullPath: "gitlab-org/gitlab-test") { job(id: "gid://gitlab/Ci::Build/404\") { trace { htmlSummary } } } }"}' 

{"data":{"project":{"job":{"trace":null}}}}%

Impersonating a reporter:

Job console shows authorization error ✅

image.png

The trace URL returns 403 ✅

image.png

As a developer:

Job console loads ✅

image.png

Trace url returns the log text ✅

image.png

How to set up and validate locally

  1. Pick a project in GDK and make it public with public pipelines. In a Rails console:

    project = Project.find_by_full_path('<namespace>/<project>')
    project.update!(visibility_level: Gitlab::VisibilityLevel::PUBLIC, public_builds: true)
  2. Create a duo_workflow job with a log (no runner needed):

    definition = Ci::Workloads::WorkloadDefinition.new do |d|
      d.image = 'alpine'
      d.commands = ['echo hello']
    end
    
    workload = Ci::Workloads::RunWorkloadService.new(
      project: project, current_user: User.find_by_username('root'),
      source: :duo_workflow, workload_definition: definition
    ).execute.payload
    
    build = workload.pipeline.builds.first
    build.trace.set("Pretend internal note content\n")
    build.success!
    puts Gitlab::Routing.url_helpers.project_job_url(project, build)
  3. Open that URL in a private window (signed out). The job page loads, but the log area shows "The current user is not authorized to access the job log." Opening <job URL>/raw returns 403.

  4. Sign in as a Reporter of the project. Same result. With a Reporter personal access token, curl --header "PRIVATE-TOKEN: <token>" "<gdk url>/api/v4/projects/<project id>/jobs/<job id>/trace" returns 403.

  5. Sign in as a Developer (or use a Developer token). The log is visible and the API returns it.

  6. Control: open any job from a normal (push) pipeline in the same project while signed out. Its log is still visible.

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 Charlie Linacre

Merge request reports

Loading
Loading