Run this before Grafana carries production traffic, and again after any change to the database, the identity provider, the provisioning tree, or the set of people who hold an administrator role. Those four are where the risk lives; the rest of the configuration can drift without anybody getting hurt.
The list is deliberately ordered as storage, then identity, then permissions, then provisioning, then recovery — because each layer only means something if the one before it holds. Folder permissions are decoration on an install where sign-up is open, and a backup is decoration on an install whose dashboards were never written to a file in the first place.
What “ready” means here
Two things, and neither is “the login page loads”. First, that a lost host is a rebuild rather than an archaeology project: the provisioning tree plus a verified database dump reconstruct the install. Second, that the answer to “who can see this, and who can change it” is a configuration somebody wrote down rather than an accident of defaults.
Access this needs
Read access to the Grafana configuration files and provisioning tree on the host, plus a service-account token with administrative read for the API items. Substitute your own Grafana address, provisioning path and repository location; the paths below are the conventional ones. Nothing here writes. The direct header-authentication probe is the one item that must be run from somewhere other than the proxy, because running it through the proxy tests the wrong path.
Sign-off
- Reviewer: ________________ Date: ___________
- Platform owner: ___________ Date: ___________
- Security owner: ___________ Date: ___________