Bugzilla

Design update after security review with :sparky (Perf), :jlorenzo and
:hgueniot (RelEng/Firefox-CI), and :benwu (Data Eng).

## Scope change: no try access

The original plan made the task try-runnable for iteration. That is dropped.
Try is level 1 and runs contributor code, so it must never hold a production
BigQuery credential. Production data access is limited to the reviewed level-3
cron on mozilla-central. Developers who need real data locally use their own
GCP credentials via `./mach bhr-aggregate`.

## Credential

The task reads a GCP service-account key from the dedicated TaskCluster secret
project/bhr/aggregation-gcp-key (bug 2056977), rather than reusing the shared
perftest namespace. RelEng granted secrets:get:project/bhr/* to
cron:bhr-aggregate (trust domain gecko, level 3, mozilla-central) in
fxci-config PR #1097.

The secret name is a fixed constant with no {level} templating on either the
kind's scope or the script's default. Previously both interpolated
MOZ_SCM_LEVEL, so a level-1 run resolved to a real level-1 secret name. Now no
level-1 name exists and anything other than the level-3 cron fails closed on a
scope it cannot hold.

Keyless auth (Workload Identity Federation) was investigated first and is
preferred, but RelEng confirmed there is no supported path for a Taskcluster
task to obtain short-lived GCP credentials today. A stored key scoped to level 3
was accepted as the fallback.

Design update after security review with :sparky (Perf), :jlorenzo and
:hgueniot (RelEng/Firefox-CI), and :benwu (Data Eng).

## Scope change: no try access

The original plan made the task try-runnable for iteration. That is dropped.
Try is level 1 and runs contributor code, so it must never hold a production
BigQuery credential. Production data access is limited to the reviewed level-3
cron on mozilla-central. Developers who need real data locally use their own
GCP credentials via `./mach bhr-aggregate`.

## Credential

The task reads a GCP service-account key from the dedicated TaskCluster secret
project/bhr/aggregation-gcp-key (bug 2056977), rather than reusing the shared
perftest namespace. RelEng granted secrets:get:project/bhr/* to
cron:bhr-aggregate (trust domain gecko, level 3, mozilla-central) in
fxci-config PR #1097.

The secret name is a fixed constant with no {level} templating on either the
kind's scope or the script's default. Previously both interpolated
MOZ_SCM_LEVEL, so a level-1 run resolved to a real level-1 secret name. Now no
level-1 name exists and anything other than the level-3 cron fails closed on a
scope it cannot hold.

Keyless auth (Workload Identity Federation) was investigated first and is
preferred, but RelEng confirmed there is no supported path for a Taskcluster
task to obtain short-lived GCP credentials today. A stored key scoped to
level 3 was accepted as the fallback.

## BigQuery access

Service account: hang-report-collection@mozdata.iam.gserviceaccount.com

Grants verified directly as the service account on 2026-07-28:

  mozdata.firefox_desktop.hang_report                            readable
  moz-fx-data-shared-prod.firefox_desktop_stable.hang_report_v1  denied
  mozdata.firefox_desktop.hang_report_redacted                   denied (not created)
  mozdata:tmp                                                    write OK

Note that a missing submission_timestamp filter returns HTTP 400, not 403,
which reads like a denial without being one.

## Verified end to end

Ran the full aggregation authenticated as the service account (not developer
credentials) for build date 2026-04-01 at sample size 0.01: 5686 pings after
filtering, 16363 hangs, 1428 modules symbolicated, 38098 frames resolved, 8261
signatures, artifact written. Row counts were identical to the same run through
the base table under developer credentials, confirming the view is a faithful
projection for every column the job reads.

Untested surface is now limited to TaskCluster plumbing: secret fetch through
taskcluster-proxy, the in-tree docker image, artifact upload, and the index
route.

## Landing order

_BQ_TABLE must be mozdata.firefox_desktop.hang_report until DENG-11394 lands,
then mozdata.firefox_desktop.hang_report_redacted. Bug 2052962 and bug 2056370
currently point at firefox_desktop_stable.hang_report_v1, which the service
account cannot read; those must be corrected before either lands or the first
cron run will 403.