[nanassito]

What problem does this PR solve?

Embedded Dashboard supports SQL TLS through certificate files, but cannot obtain rotating X.509-SVIDs and trust bundles directly from a SPIFFE Workload API. Deployments using SPIFFE identities for SQL mTLS currently need separate credential-file and rotation plumbing; the existing file-based integration does not provide SPIFFE URI identity authorization.

Issue Number: close #11397

What is changed and how does it work?

• Add opt-in [dashboard] configuration for a Unix Workload API endpoint, initialization timeout, and explicit client/server SPIFFE identity patterns. Reject incomplete settings and mixing SPIFFE with certificate-file TLS.
• Use go-spiffe v2.8.2 to watch SVIDs and trust bundles. Require TLS 1.3, select one authorized client SVID, and verify the server certificate chain and SPIFFE URI. Patterns support exact IDs and whole-segment wildcards with explicit trust domains.
• Pass a rotating TLS configuration through Dashboard's existing SQL client integration. Each active Dashboard run owns its source: initialize before startup, close on startup failure or after shutdown, and recreate after ownership migration. Initialization failures keep Dashboard stopped and retry without plaintext fallback.
• Preserve certificate-file TLS when SPIFFE mode is absent and retain SQL username/password authentication and account privileges. Add generic configuration examples and documentation.

Allow the embedded Dashboard SQL client to consume rotating SPIFFE
credentials and trust bundles directly from a Workload API Unix socket.
Authorize explicit workload identities and manage the source together with
Dashboard's service lifecycle, without weakening existing SQL account policy.

Check List

Tests

• Unit and local protocol integration tests cover configuration validation, real Unix Workload API updates, MySQL TLS-config clones, TLS 1.3 handshakes, credential/trust-bundle rotation, unauthorized and ambiguous identities, startup deadlines, and source cleanup across failures and Dashboard ownership changes.
• Passed failpoint-aware basic tests with -race for pkg/dashboard/spiffetls, pkg/dashboard/adapter, and server/config, plus the provider's goroutine-leak verification.
• Passed changed-package lint with upstream's pinned golangci-lint v2.13.2 and a PD server build with Dashboard enabled, using Go 1.26.8.
• Repository-wide module tidiness, all four module linters, leak checks, Prometheus rule checks, and generated error documentation passed. make check GO_EFFECTIVE_TOOLCHAIN=go1.26.8 stops at two pre-existing modernize@v0.52.0 findings, independently reproduced on pristine base 431d773c8752: pkg/schedule/schedulers/hot_region_solver_test.go:1225 (range over int) and pkg/statistics/hot_peer_cache_test.go:942 (t.Context).
• Real Dashboard login and SQL-backed requests against a running TiDB cluster have not been exercised.

Code changes

• Add opt-in Dashboard configuration fields; no new HTTP endpoint or persistent data format.

Side effects

• SPIFFE mode adds a Workload API watch while Dashboard is active. No performance benchmark was run.
• Existing behavior is retained when SPIFFE settings are absent.

Related changes

• Similar Workload API proposals: sink/mysql: support SPIFFE Workload API mTLS pingcap/ticdc#6470 and server: support SPIFFE Workload API for MySQL TLS pingcap/tidb#70738.
• No deployment or release-branch cherry-pick included.

Release note

Support SPIFFE Workload API mTLS for the embedded Dashboard SQL client, including automatic credential and trust-bundle rotation and SPIFFE identity verification.

Summary by CodeRabbit

• New Features
  • Dashboard SQL connections can now use mutual TLS credentials from the SPIFFE Workload API, with configurable socket, startup timeout, and client and server identity patterns.
  • Credentials and trust bundles update automatically for new SQL connections. Dashboard does not fall back to plaintext or certificate-file TLS if SPIFFE credentials are unavailable or invalid.
• Documentation
  • Added guidance on configuring SPIFFE identities, wildcard matching, TLS setting compatibility, and checks to complete before enabling secure transport.

[ti-chi-bot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign likidu, nolouch for approval. For more information see the Code Review Process.
Please ensure that each of them provides their approval before proceeding.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS
• conf/OWNERS
• server/config/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[coderabbitai]

No actionable comments were generated in the recent review.

Recent review info

Run configuration

• Source mode: Auto
• Repository: Unavailable
• Branch: Unavailable
• File: No configuration file from this repository applied
• Commit: Unavailable
• Layers: Repository UI
• Review profile: CHILL
• Plan: Advanced
• Run ID: ce58c2d7-8f54-41b7-a017-07c6a7b37996

Commits

Reviewing files that changed from the base of the PR and between 6f57b95 and 0dd0d7f.

Files ignored due to path filters: 3

• go.sum is excluded by !**/*.sum
• tests/integrations/go.sum is excluded by !**/*.sum
• tools/go.sum is excluded by !**/*.sum

Files selected for processing: 14

• conf/config.toml
• docs/dashboard-spiffe.md
• go.mod
• pkg/dashboard/adapter/config.go
• pkg/dashboard/adapter/manager.go
• pkg/dashboard/adapter/manager_test.go
• pkg/dashboard/dashboard.go
• pkg/dashboard/spiffetls/main_test.go
• pkg/dashboard/spiffetls/source.go
• pkg/dashboard/spiffetls/source_test.go
• server/config/config.go
• server/config/dashboard_spiffe_test.go
• tests/integrations/go.mod
• tools/go.mod

Included review availability: This review used your included allowance. Your plan provides up to 4 included reviews per hour; 3 remain after this review.

Walkthrough

Adds opt-in SPIFFE Workload API mTLS for Dashboard SQL connections. Configuration validates the endpoint and identity patterns. A TLS source obtains and rotates credentials, and the Dashboard manager manages the source during service startup and shutdown.

Changes: Dashboard SPIFFE SQL TLS

Layer / File(s)	Summary
SPIFFE settings and validation server/config/config.go, server/config/dashboard_spiffe_test.go, conf/config.toml, docs/dashboard-spiffe.md	Adds SPIFFE endpoint, timeout, and identity pattern settings. Validation rejects invalid settings and combinations with certificate-file TLS. The config example and documentation describe identity matching, startup behavior, credential rotation, and operational checks.
Rotating SPIFFE TLS source pkg/dashboard/spiffetls/source.go, pkg/dashboard/spiffetls/source_test.go, pkg/dashboard/spiffetls/main_test.go, go.mod, tests/integrations/go.mod, tools/go.mod	Adds Workload API credential loading, SVID validation, TLS 1.3 mutual TLS, identity matching, and credential and trust-bundle rotation. Tests cover configuration, startup, rotation, and source cleanup. Module files add or update related dependencies.
Dashboard manager TLS lifecycle pkg/dashboard/adapter/config.go, pkg/dashboard/adapter/manager.go, pkg/dashboard/adapter/manager_test.go, pkg/dashboard/dashboard.go	Passes Dashboard configuration to the manager. The manager initializes the SPIFFE source before startup, assigns its TLS configuration, and closes the source on startup failure or shutdown. Tests cover lifecycle and cancellation cases.

Priority: Normal

Estimated code review effort: 4 (Complex) | ~45 minutes

Change: Feature · Severity of issue fixed: Medium

Sequence Diagram(s)

sequenceDiagram
  participant Manager
  participant TLSSource as SPIFFE TLS source
  participant Dashboard as Dashboard service
  Manager->>TLSSource: Initialize source with configured timeout
  TLSSource-->>Manager: Return TLS configuration
  Manager->>Dashboard: Start service with TLS configuration
  Dashboard-->>Manager: Return startup result
  Manager->>Dashboard: Stop service with timeout
  Manager->>TLSSource: Close source

Loading

Suggested reviewers: rleungx

Merge Risk: Minimal · up to 0dd0d

An unavailable Workload API can slow Dashboard-host status refreshes, but no actionable merge-blocking risk remains.

Pre-merge checks: 3 · 2

Failed checks: 2 warnings

Check name	Status	Explanation	Resolution
Linked Issues check		Issue [#11397] requires native SPIFFE Workload API TLS for embedded Dashboard SQL connections, including rotation, identity authorization, bounded fail-closed startup, lifecycle ownership changes, ret…	Add an automated Dashboard integration test that uses SPIFFE SQL TLS against a running TiDB setup with require_secure_transport=ON, and verify Dashboard login and SQL-backed requests. Keep the existing unit and local protocol tests.
Docstring Coverage		Docstring coverage is 21.74% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 23 functions across 9 files. (5 skipped: …	Write docstrings for the functions missing them to satisfy the coverage threshold.

Passed checks: 3 passed

Check name	Status	Explanation
Title check		The title clearly and concisely describes the main change: SPIFFE Workload API support for Dashboard SQL TLS.
Description check		The description covers the required problem, issue reference, implementation, tests, code changes, side effects, related changes, and release note. It also clearly records known test limitations and p…
Out of Scope Changes check		The changes stay within issue [#11397]. Configuration, SPIFFE source code, lifecycle handling, tests, dependencies, and documentation directly support embedded Dashboard SQL TLS. The summary identifie…

Full details: Description check

Explanation

The description covers the required problem, issue reference, implementation, tests, code changes, side effects, related changes, and release note. It also clearly records known test limitations and pre-existing failures.

Full details: Out of Scope Changes check

Explanation

The changes stay within issue [#11397]. Configuration, SPIFFE source code, lifecycle handling, tests, dependencies, and documentation directly support embedded Dashboard SQL TLS. The summary identifies no browser TLS, PD cluster TLS, deployment, release-branch, or persistent data changes.

Full details: Linked Issues check

Explanation

Issue [#11397] requires native SPIFFE Workload API TLS for embedded Dashboard SQL connections, including rotation, identity authorization, bounded fail-closed startup, lifecycle ownership changes, retained file TLS, and configuration documentation. The change summary and tests cover these coding areas. The issue also requires acceptance coverage for Dashboard login with require_secure_transport=ON. The PR explicitly states that real Dashboard login and SQL-backed requests against a running TiDB cluster were not exercised, so this requirement is not demonstrated by an automated test.

Resolution

Add an automated Dashboard integration test that uses SPIFFE SQL TLS against a running TiDB setup with require_secure_transport=ON, and verify Dashboard login and SQL-backed requests. Keep the existing unit and local protocol tests.

Full details: Docstring Coverage

Explanation

Docstring coverage is 21.74% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 23 functions across 9 files. (5 skipped: 5 unsupported.)

Resolution

Write docstrings for the functions missing them to satisfy the coverage threshold.

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[ti-chi-bot]

Hi @nanassito. Thanks for your PR.

I'm waiting for a tikv member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work.

Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[ti-chi-bot]

Welcome @nanassito!

It looks like this is your first PR to tikv/pd 🎉.

I'm the bot to help you request reviewers, add labels and more, See available commands.

We want to make sure your contribution gets all the attention it needs!



Thank you, and welcome to tikv/pd. 😃

[nanassito]

/auto-cc