PMM-15379 Feature build

[ademidoff]

PMM-15379

Component PRs

• PMM-15379 Fix LBAC bypass and gate the VM proxy paths percona/pmm#5923

ci.yml

deps:
  - name: pmm
    branch: PMM-15379-lbac-datasource-proxy-prefix
    url: https://github.com/percona/pmm

Single repo — only percona/pmm is pinned; every other dependency stays at its default. Rebuilt components are pmm-managed and vmproxy.

What QA needs to know

Two changes on the Grafana data source surface:

1. Label-based access control now applies to every data source proxy URL form. Previously only /graph/api/datasources/proxy/1/api/v1/... was filtered, so a user restricted by an access-control role could read unfiltered metrics through the UID form or through a data source whose numeric id was not 1.
2. vmproxy now forwards only the VictoriaMetrics query endpoints. Anything else — snapshots, /metrics, /flags, /debug/pprof/*, /api/v1/status/config, /api/v1/targets, the /api/v1/admin/* surface — returns 403 with a warn line in /srv/logs/vmproxy.log naming the path.

The main regression risk is dashboards

Change 2 restricts what can pass through the Metrics data source, so the thing worth testing hardest is that normal dashboard use is unaffected: panels render, template variables populate, Explore works, and QAN is unaffected. Any panel that breaks will leave a Refusing request to a path outside the read-only allow-list line in /srv/logs/vmproxy.log with the exact path — please attach that line if you hit one, it identifies a missing entry directly.

Verified before submitting by driving 10 dashboards plus Explore in a browser against a patched 3.10.0 server: zero non-2xx responses, all template-variable lookups fine, and the deny log empty for the whole run. That was on a server with only PMM's own PostgreSQL monitored, so dashboards for MySQL, MongoDB, ProxySQL, HAProxy and the cloud integrations are exactly what this run did not cover.

Also worth checking

• An access-control role with a label filter must filter identically on every proxy URL form, not just proxy/1.
• Admin access to VictoriaMetrics through /prometheus/* is unchanged and must still work — it does not cross vmproxy.
• Metric ingestion is unaffected: vmagent writes via a route that bypasses vmproxy. Confirm clients still report data.

[JNKPercona]

Server docker: perconalab/pmm-server-fb:PR-4563-e4eae77
Client docker: perconalab/pmm-client-fb:PR-4563-e4eae77
Client tarball: https://s3.us-east-2.amazonaws.com/pmm-build-cache/PR-BUILDS/pmm-client/pmm-client-PR-4563-e4eae77.tar.gz
Staging instance: https://pmm.cd.percona.com/job/pmm3-aws-staging-start/parambuild/?DOCKER_VERSION=perconalab/pmm-server-fb:PR-4563-e4eae77&CLIENT_VERSION=https://s3.us-east-2.amazonaws.com/pmm-build-cache/PR-BUILDS/pmm-client/pmm-client-PR-4563-e4eae77.tar.gz

[JNKPercona]

API tests have succeded: https://pmm.cd.percona.com/job/pmm3-api-tests/7342/

[JNKPercona]

Server docker: perconalab/pmm-server-fb:PR-4563-8fab4f5
Client docker: perconalab/pmm-client-fb:PR-4563-8fab4f5
Client tarball: https://s3.us-east-2.amazonaws.com/pmm-build-cache/PR-BUILDS/pmm-client/pmm-client-PR-4563-8fab4f5.tar.gz
Staging instance: https://pmm.cd.percona.com/job/pmm3-aws-staging-start/parambuild/?DOCKER_VERSION=perconalab/pmm-server-fb:PR-4563-8fab4f5&CLIENT_VERSION=https://s3.us-east-2.amazonaws.com/pmm-build-cache/PR-BUILDS/pmm-client/pmm-client-PR-4563-8fab4f5.tar.gz

[JNKPercona]

API tests have succeded: https://pmm.cd.percona.com/job/pmm3-api-tests/7378/

[travagliad]

FB Tests triage — not caused by this PR. The one red job (@pmm-ps-integration) failed on PMM-T2028 (both data rows) and PMM-T1897. Neither involves LBAC or vmproxy: they follow from pmm-qa #1433, which moved pmm-framework's PS DEFAULT_VERSION from 8.0 to 8.4. The control is exact — the same 10 tests all passed on pmm-qa main at 02:22 UTC that day (run 34920911833) with identical setup args, differing only in the provisioned version (ps_pmm_replication_8_0_* there, 8_4_* here).

Reproduced on a throwaway Linode VM running this PR's own FB image (perconalab/pmm-server-fb:PR-4563-8fab4f5) at pmm-qa 6f57cd2 — 3 failed / 7 passed, byte-identical errors. The product is fine: under PS 8.4.11-11 the server exports mysql_slave_status_replica_{io,sql}_running (8.4 renamed the SHOW SLAVE STATUS columns) while the test asserted the old slave_* names; the same FB image with PS 8.0 passed all three. PMM-T1897's extra query is the 8.4 client forwarding comments into the slow log as an empty-fingerprint digest.

The fix is already merged in pmm-qa as #1436. I verified it end to end on the failing configuration — PS 8.4 with this PR's FB image — and all three now pass (replica_io_running 411 ms, replica_sql_running 245 ms, PMM-T1897 at 19). I have re-run the failed job on this run; it should come back green with no action needed from you.

---

Generated by Claude Code

[JNKPercona]

Server docker: perconalab/pmm-server-fb:PR-4563-5bbbab1
Client docker: perconalab/pmm-client-fb:PR-4563-5bbbab1
Client tarball: https://s3.us-east-2.amazonaws.com/pmm-build-cache/PR-BUILDS/pmm-client/pmm-client-PR-4563-5bbbab1.tar.gz
Staging instance: https://pmm.cd.percona.com/job/pmm3-aws-staging-start/parambuild/?DOCKER_VERSION=perconalab/pmm-server-fb:PR-4563-5bbbab1&CLIENT_VERSION=https://s3.us-east-2.amazonaws.com/pmm-build-cache/PR-BUILDS/pmm-client/pmm-client-PR-4563-5bbbab1.tar.gz

[JNKPercona]

API tests have failed: https://pmm.cd.percona.com/job/pmm3-api-tests/7379/

[JNKPercona]

Server docker: perconalab/pmm-server-fb:PR-4563-8af4a8d
Client docker: perconalab/pmm-client-fb:PR-4563-8af4a8d
Client tarball: https://s3.us-east-2.amazonaws.com/pmm-build-cache/PR-BUILDS/pmm-client/pmm-client-PR-4563-8af4a8d.tar.gz
Staging instance: https://pmm.cd.percona.com/job/pmm3-aws-staging-start/parambuild/?DOCKER_VERSION=perconalab/pmm-server-fb:PR-4563-8af4a8d&CLIENT_VERSION=https://s3.us-east-2.amazonaws.com/pmm-build-cache/PR-BUILDS/pmm-client/pmm-client-PR-4563-8af4a8d.tar.gz

[JNKPercona]

API tests have succeded: https://pmm.cd.percona.com/job/pmm3-api-tests/7403/