How a Grafana auth proxy setup moves sign-in to the proxy
An organization that wants one identity front door for Grafana and its other internal web apps can move sign-in out of Grafana entirely. In an auth proxy setup, a reverse proxy such as OAuth2 Proxy handles the OIDC or OAuth2 login with the identity provider, then forwards the authenticated user to Grafana with identity headers. Grafana does not check a password or contact the identity provider itself. It reads the headers named in its auth proxy settings and creates or matches a user from them. That shifts the trust decision from Grafana to the proxy, so the proxy's session handling, token validation and group forwarding become part of Grafana's access control.
The trust boundary is the point to design first. Grafana will believe any request that carries the configured header, so anyone who can reach Grafana directly, or send a request that bypasses the proxy, can claim any identity. The supported path is to set the auth proxy options in Grafana's configuration, including the header name used for the user, and to make the proxy the only route to Grafana's listener. Network controls such as firewall rules, a private subnet or a Kubernetes network policy that admits only the proxy are part of the design, not optional hardening. Confirm the exact header names, the group and email headers and the auth proxy setting keys against the current Grafana authentication documentation for your release before you write them into configuration.
Pomerium is the main alternative if the organization wants a proxy that also passes identity to upstream apps and applies policy across them. Its Core edition is open source under Apache-2.0, so the same header-based integration pattern can be evaluated against OAuth2 Proxy. Before choosing, decide which proxy your security team will operate, how sessions will be stored and who owns the header contract with each application. Those decisions shape the rest of the work: role mapping, enforced sync and the spoofing tests that confirm Grafana rejects requests that did not come through the proxy.
What you need before configuring the proxy
Putting OAuth2 Proxy in front of Grafana touches the Grafana version, its database, the proxy and its session store, the identity provider, and the TLS endpoint users reach. Each item below is a decision to settle before any configuration file is edited, because a gap in one usually surfaces as a login loop or an unprotected port later.
A supported Grafana version
Start from a current Grafana release line rather than an older build, since the auth proxy settings and header handling are documented per version. The current releases in the supplied sources include 13.2.0 and patch releases such as 13.2.4, and each minor release has a limited support window. Confirm the exact [auth.proxy] keys against the configuration docs for the version you will run, and plan a patch cadence that keeps you inside support.
A production database
Grafana keeps users, sessions and configuration in its database, and SQLite is not suitable for production or high availability. Choose MySQL 8.0 or later or PostgreSQL 12 or later before go-live, and provision backups for it. Proxy-managed logins still create local Grafana user records, so losing this database means losing role assignments and dashboards.
An OAuth2 Proxy release
Pin a specific OAuth2 Proxy release in your image or package manifest, such as v7.15.5, and record the upgrade path you will follow. The project is MIT licensed and community maintained under the CNCF Sandbox, so confirm that the release notes cover your provider and header options. Test the chosen version against your identity provider before it reaches production.
An identity provider client registration
Register an OIDC or OAuth2 client in your identity provider with the callback URL that OAuth2 Proxy will use for the proxy hostname. Decide early which claims carry the username, email and groups, because Grafana role mapping depends on the group values the proxy forwards. Ask your identity team who owns the client secret and how it is rotated.
A session store decision
Choose between encrypted client-side cookies, which need a cookie secret, and Redis, which keeps only a ticket in the cookie. Cookie sessions hold no server state but cannot be locked, so concurrent token refreshes can force a re-login. Redis, including Sentinel or Cluster, suits larger or highly concurrent user bases but adds a service you must run and back up.
A TLS certificate for the proxy hostname
Users reach Grafana through the proxy hostname, so that name needs a certificate trusted by your clients, and the proxy must be the only path that terminates it. Confirm the hostname, renewal process and certificate chain with your PKI owner. Grafana's own URL settings must match this external address, or redirects and cookies will fail.
Configuring Grafana and the proxy in sequence
The sequence builds the identity path from the provider to the proxy and then to Grafana, so each layer is verified before the next one depends on it. The result is a Grafana instance that accepts sign-ins only from the proxy and creates users from the identity headers it receives.
Register the OIDC client and redirect URL
The identity team registers an OIDC client for the proxy in your identity provider and sets the redirect URL to the callback path on the proxy's public hostname. Confirm the exact callback path in the OAuth2 Proxy configuration overview for your version, and make sure the provider issues the email and group claims you plan to map. The step is done when a test sign-in against the provider's own tester or a browser redirect returns to the proxy hostname without error.
Configure OAuth2 Proxy with the provider
The platform engineer sets the provider type, client ID, client secret, OIDC issuer URL and allowed email domains or groups in the OAuth2 Proxy configuration. Generate the cookie secret from a cryptographically secure source and store it, along with the client secret, in your secrets manager rather than in plain configuration files. The step is done when the proxy starts, its health endpoint responds and it redirects an unauthenticated browser request to the provider.
Choose the session store and identity headers
Decide between encrypted cookie sessions, which hold no server state but cannot be locked and can force re-login when token refreshes collide, and Redis, which keeps only a ticket in the cookie and supports Sentinel or Cluster. Enable the header options that forward user, groups and email, using set-xauthrequest if the proxy runs behind nginx auth_request. The step is done when a sign-in through the proxy shows the expected X-Forwarded-User, X-Forwarded-Groups and X-Forwarded-Email values in a test request to a placeholder upstream.
Enable the auth proxy section in grafana.ini
The Grafana administrator sets enabled to true in the [auth.proxy] section of grafana.ini, then sets the header name Grafana reads for login, along with the headers for email, name and groups. Add the proxy's address to the whitelist setting so Grafana accepts identity headers only from that source, and leave auto_sign_up on if new users should be created on first sign-in. The step is done when Grafana restarts cleanly and the log shows the auth proxy is active.
Map groups to roles and enforce sync
Map the group header values to Grafana organization roles using the auto sign-up and role mapping settings, and decide whether Grafana should enforce sync so that role changes at the provider take effect at the next sign-in. Team sync and active sync depend on the edition, so confirm them against the Grafana authentication documentation before relying on them. The step is done when two test users in different groups receive the expected roles and a user removed from a group loses the matching role after signing in again.
Verify the first sign-in creates the expected user
Sign in through the proxy with a test account and open the Grafana user list as an administrator. Confirm the user was created with the expected login, name and email, and that the role matches the group mapping from the previous step. Record the test in your change log so the baseline is available when you troubleshoot later. The step is done when the user record matches the identity provider profile exactly.
Restrict network access to the proxy only
The network team configures firewall rules, security groups or Kubernetes network policies so that only the proxy's address can reach the Grafana HTTP port, and the public path runs only through the proxy. Test a direct request to the Grafana port from a client outside the proxy, and send a request with forged identity headers to confirm it is rejected. The step is done when the direct request fails and the forged-header test does not produce a session. Review the security hardening guidance for further controls before go-live.
Mapping proxy groups to Grafana roles and orgs
OAuth2 Proxy can forward group membership from the identity provider to the upstream application as an HTTP header, and Grafana reads that header through its auth proxy settings. The group values come from a claim in the token, so the first decision is which claim carries the groups you want to map and whether your identity provider includes it in the tokens that OAuth2 Proxy receives.
- Confirm the group source: check which claim your identity provider uses for groups and that the scopes OAuth2 Proxy requests return it.
- Enable group forwarding: the OAuth2 Proxy configuration overview documents the
X-Forwarded-Groupsheader, and theset-xauthrequestoption returnsX-Auth-Requestheaders for nginxauth_requestsetups. - Match header names in Grafana: the
[auth.proxy]section sets the header names Grafana reads for login, email and groups, so they must match what the proxy sends exactly. - Test with one account: inspect the headers for a user who belongs to several groups before you enable mapping for everyone.
Confirm the header names against the versions of OAuth2 Proxy and Grafana you deploy, using the Grafana authentication docs as the reference for Grafana's side.
In the open-source edition, the proxy's group information can drive which Grafana role a user receives, and you decide how that role maps to the organizations on your instance. Keep the mapping small and explicit. Every group that grants access should correspond to a documented role decision, and anyone outside those groups should land on a role you have chosen deliberately.
- Define a role per group: agree on which groups become Viewer, Editor or Admin, and document the owner of each group in your identity provider.
- Limit admin grants: avoid mapping broad groups to the Admin role, and keep server admin separate from organization admin.
- Plan organization placement: decide whether each team gets its own organization or shares one with folder-level permissions, since that choice changes how mapping works.
- Use folder permissions for detail: where the open-source edition cannot express a team's needs through roles alone, restrict folders and dashboards directly.
For the full mechanics of role attributes and organization mapping, read the sibling topic on generic OAuth role and organization mapping, then confirm each setting against the version you run before you rely on it.
Enforce sync answers a simple question: when a user leaves a group in your identity provider, how quickly does their Grafana access change? Grafana caches what it learns about a user, so the time between a directory change and the Grafana change depends on the settings you choose and on whether the user has an active session. Treat the timing as something to test, not something to assume.
- Open source sync: role changes from the proxy apply when Grafana processes the incoming headers, so verify the behavior after removing a test user from a group.
- Session lifetime: a user with an active session keeps access until the session ends or the proxy refuses the request, so align session lifetimes with your offboarding targets.
- Team sync is Enterprise only: mapping groups to Grafana teams and syncing team membership is part of Grafana Enterprise and Grafana Cloud, according to the Grafana authentication docs.
- Active sync and SCIM are also Enterprise: continuous directory sync and SCIM provisioning fall in the same edition boundary.
If team-level sync is a requirement, confirm the licensing position with Grafana Labs before you design around it, and document how open-source access is removed when a user changes groups.
Group headers are not always present. A user may have no groups, the provider may omit the claim for some accounts, or a proxy misconfiguration may send an empty header. Changing groups can also leave a user with a stale role until the next sync or login. Define both cases before launch, because the default behavior decides who can see your data.
- Set a default for empty headers: choose whether a user with no groups receives a minimal role or no access, and test that path explicitly.
- Fail closed where possible: if the proxy cannot determine groups, prefer denying access over granting a broad default role.
- Handle group changes on session refresh: OAuth2 Proxy holds sessions in cookies or Redis, and cookie sessions cannot be locked, so concurrent token refreshes can force a re-login.
- Review the default role: confirm which role Grafana assigns to a user whose group is unrecognized, and avoid Editor or Admin as fallbacks.
Run a test with a user who has no groups, one whose groups change mid-session, and one removed from every mapped group, then record the results as evidence for your access review.
The open-source edition supports auth proxy login with role and organization handling, but several directory-driven controls belong to Grafana Enterprise and Grafana Cloud. Knowing this boundary early prevents an access design that depends on features your edition does not include. Plan the mapping model for the edition you will run, and record any gap as a decision for the owners of the access model.
- Open source includes: auth proxy login and generic header handling, with role and folder controls as the main access tools.
- Enterprise adds: team sync, active sync, SAML and SCIM provisioning, according to the Grafana authentication docs.
- Licensing check: confirm which edition and license terms apply to your deployment, since the features above depend on it.
- Document the gap: if a control you need is Enterprise only, state the compensating control, such as folder permissions or manual review, in your access documentation.
Before you commit to a design, confirm current edition features with Grafana Labs, because licensing and feature placement can change between releases.
Identity headers and Grafana fields
This table maps each identity value OAuth2 Proxy can send to the Grafana auth proxy setting that reads it and the user field it fills. Header names must match what the proxy actually sends in your setup, so confirm them on a test login before you enable enforced sync. The main takeaway is that the username, email and role headers have the strictest requirements.
| Identity item | Header from the proxy | Grafana setting | Resulting field and requirement |
|---|---|---|---|
| Username | X-Forwarded-User | header_name in the auth.proxy section, with header_property set to username | Login identity. Must be unique and stable for each user. |
| X-Forwarded-Email | headers entry mapping Email to this header | User email field. Confirm it is populated for every account that signs in. | |
| Groups | X-Forwarded-Groups | headers entry mapping Groups to this header | Input for group-based mapping. Group-to-team sync requires Grafana Enterprise, per the authentication docs. |
| Display name | Not sent by default, so confirm the upstream claim | headers entry mapping Name to a name header | Display name shown in the Grafana user profile. |
| Role | No standard role header, so add one through upstream claims or proxy header injection | headers entry mapping Role to the role header | Org role such as Viewer, Editor or Admin. The value must match a valid Grafana role name exactly. |
| Access or ID token | Optional, if enabled in the OAuth2 Proxy configuration | Grafana auth proxy does not read tokens as identity | Keep tokens at the proxy unless another service needs them. Do not treat a token as a Grafana login. |
| Auth request headers (nginx) | X-Auth-Request-User, X-Auth-Request-Email and X-Auth-Request-Groups when set-xauthrequest is used | nginx proxy_set_header lines that copy these into the names Grafana reads | Same user fields as above. The names differ from X-Forwarded-*, so the nginx mapping must match the mode you run. |
Why header trust is the core risk
Grafana trusts whatever identity the proxy header carries. When auth proxy mode is enabled, Grafana reads the user from a configured header and signs that user in without a password or session of its own. The consequence is direct: any client that can reach Grafana without passing through the proxy can send its own X-Forwarded-User or X-Forwarded-Groups header and sign in as anyone, including an administrator. The proxy is therefore not a convenience layer on top of Grafana security. It is the security boundary, and every path to Grafana has to pass through it.
Two controls make that boundary hold. First, the proxy must strip any identity headers a client sends on inbound requests before it adds its own, so a client cannot supply a header the proxy then passes through unchanged. Second, the network must make the proxy the only route to Grafana: bind Grafana to a private address or a restricted network segment, allow inbound traffic only from the proxy's addresses, and configure Grafana's trusted proxy list so it accepts the auth header only from that source. Confirm each of these in your own environment with a request sent directly to the Grafana port carrying a forged header, which should be refused. Check the current behavior of your OAuth2 Proxy version, since header forwarding options are set in its configuration overview.
Session handling adds a second risk. OAuth2 Proxy stores sessions in encrypted cookies by default or in Redis, and its documentation states that cookie sessions cannot be locked. When two requests refresh the same token at once, the refresh can conflict and force the user to log in again. Redis-backed storage keeps only a ticket in the cookie, which is a design choice to weigh before go-live. Plan for re-login prompts in your user communication and test refresh behavior under concurrent browser tabs and API clients before you rely on it for a shared dashboard estate.
Locking Grafana so only the proxy can reach it
Once the proxy authenticates users, Grafana must trust only what the proxy sends and nothing else. The controls below work as layers: keep Grafana off the public network, let only the proxy connect, overwrite identity headers at the edge, and harden cookies and the browser policy. Each one closes a different path an attacker could use to impersonate a user.
Bind Grafana to a private interface
Configure Grafana to listen only on a private address or a loopback interface so it is not reachable directly from user networks. Keep the proxy on the same host or subnet, and confirm with a port scan from outside the proxy's network that the Grafana port does not answer. A Grafana instance that is reachable directly can accept forged identity headers from any client, which defeats the proxy entirely.
Allow only the proxy in firewall rules
Write firewall or security group rules that permit inbound connections to the Grafana port only from the proxy's addresses, and deny everything else, including other application servers on the same network. Review these rules whenever the proxy is scaled out or moved, because a new proxy node that is not listed will either fail or, if rules are too broad, open a bypass. Ask your network team to show the effective rules, not only the intended ones.
Strip and overwrite identity headers
At the edge, the proxy must delete any client-supplied copy of the identity headers before it sets its own. Otherwise a user can send a request with a forged user or group header and Grafana may accept it when the request reaches the proxy with a valid session. Test this directly by sending a request with a spoofed header through the public address and confirming Grafana logs the proxy-set identity instead.
Set trusted proxy addresses
Grafana's auth proxy settings should name the proxy's address as the only trusted source of identity headers. Keep the whitelist narrow and specific, and do not use broad ranges that include application or user networks. Document the list alongside the firewall rules so both controls change together during proxy maintenance or failover.
Secure and SameSite session cookies
Grafana's hardening guidance recommends secure and SameSite cookie settings so browser sessions are sent only over HTTPS and are limited against cross-site requests. Pair this with a Content Security Policy that limits where scripts and frames can load from. Confirm the settings in the running browser's developer tools, because a proxy that terminates TLS may need matching configuration to set the secure flag correctly.
Require authentication on metrics
Grafana exposes a metrics endpoint that can reveal internal details, and the hardening guidance recommends requiring authentication on it. Either restrict that path at the proxy so only your monitoring system can reach it, or require credentials for it in Grafana. Protect the OAuth2 Proxy cookie secret and any Redis session store as credentials too, since anyone holding them can forge or replay a logged-in session.
Questions teams ask before configuring an auth proxy
How much effort does putting Grafana behind an auth proxy take?
The effort depends mostly on how many identity providers you connect, how much group logic maps to Grafana roles and organizations, how the network is designed, and whether Grafana runs as one server or as a high availability group. A single identity provider with a flat group model and one Grafana server is a small, bounded task. Each additional provider, nested group rule, or organization mapping adds configuration and testing. Ask any partner for a written scope that lists each provider, each group mapping, each network path and each test case, because those items set the quote. No duration is given here because none is supplied for this topic.
Can our in-house team configure an auth proxy using the Grafana docs alone?
Yes, a team with reliable experience in reverse proxies, TLS, and identity protocols can usually do the work from the documentation, provided it tests the result carefully. The risky parts are not the settings themselves but the surrounding decisions: making sure Grafana accepts identity headers only from the proxy, locking the Grafana port to the proxy, deciding how sessions are stored, and testing that a forged header is rejected. Review the Grafana authentication docs and the security hardening guidance before you start, and confirm each step in a non-production environment first.
Why are team sync and SCIM separate from the open-source edition?
According to the Grafana authentication docs, all editions support auth proxy, but SAML, team sync, active sync and SCIM provisioning are available only in Grafana Enterprise and Grafana Cloud. This means that when your identity provider pushes group membership into Grafana teams or provisions and deprovisions users automatically, you need Enterprise. With open-source Grafana behind a proxy, roles and organizations come from the headers on each request, so removing someone from a group in your identity provider takes effect at the next sign-in rather than through an automated sync. Confirm the current edition boundaries with Grafana Labs, since they affect licensing and your access model.
Should we use OAuth2 Proxy or Pomerium in front of Grafana?
OAuth2 Proxy is a focused, community-driven reverse proxy under the MIT License that authenticates users with Google, Microsoft Entra ID, OpenID Connect and other providers, then forwards identity headers to the application. Pomerium is an identity and context-aware reverse proxy that also offers clientless access to internal apps, with Pomerium Core under Apache-2.0. Pomerium Core is open source and self-run, while its Zero and Enterprise plans add managed control plane, directory sync, Rego policies and administrator RBAC. Choose OAuth2 Proxy when you need a narrow header-based gateway for Grafana. Choose Pomerium when you also need policy engines or access to other internal services. Confirm which features you need against the license terms.
How does high availability change the auth proxy design?
Grafana high availability uses two or more active-active servers behind a load balancer sharing a MySQL or PostgreSQL database, with database-backed auth tokens so users can reach any node. The proxy layer must then route requests to all Grafana nodes, and the identity headers must be trusted from each node's proxy path. Session handling matters too: OAuth2 Proxy keeps sessions in encrypted cookies by default, which needs a shared cookie secret across proxy instances, or in Redis, which needs its own high availability design. Grafana's docs also note that alerting needs extra configuration to avoid duplicate notifications and that Grafana Live has limitations in high availability. Plan these items together rather than as a later add-on.
What do we need to provide before the work starts?
Plan for administrator access to your identity provider so the work can register the application, define claims or group attributes, and create test accounts for each role. You will also need change approval for network changes, including a path from the proxy to Grafana and a rule that blocks direct access to the Grafana port. Provide a list of groups and their intended Grafana roles, the target database and hosting platform, and a named owner who can test sign-in with each group. Ask the partner to confirm this list in the written scope so that access and approvals are agreed before the build begins.
What are the main security risks with header-based sign-in?
The central risk is header spoofing. If Grafana accepts the identity header from any client that can reach it, an attacker can send a forged user or role header and sign in as anyone. The fix has two parts: Grafana must be reachable only through the proxy, and the proxy must strip any incoming identity headers before adding its own. Verify both with a test that sends a forged header directly to Grafana and confirms it is rejected. Use secure and SameSite cookies as described in the Grafana security hardening guidance, and treat the test results as part of your change record.
Common failures when Grafana sits behind a proxy
This table lists the failures teams most often hit when an authenticating proxy fronts Grafana, with the likely cause and the fix for each. Read it before go-live, then use it as a checklist during testing, since most of these faults show up only after users, sessions or nodes multiply.
| Failure | Likely cause | Fix |
|---|---|---|
| Login loop after sign-in | Redirect URL or cookie domain in the proxy does not match the public Grafana hostname, so the session cookie is never accepted | Set the proxy redirect URL and cookie domain to the exact public hostname, serve both over HTTPS, and confirm the Grafana root URL matches |
| Users created with wrong email or no role | Header names in the proxy (for example X-Forwarded-Email or X-Auth-Request-Email) differ from the names Grafana auth proxy settings expect | Align the header name settings on both sides, test with a single user, and check the created user record before opening access |
| Direct access bypasses the proxy | Grafana listens on a network address the users or other hosts can reach, so anyone who sets the identity header can sign in | Bind Grafana to localhost or a private interface, restrict port access at the network layer, and allow only the proxy address in the auth proxy whitelist |
| Sessions dropped on token refresh | Cookie-based session storage in OAuth2 Proxy cannot be locked, so concurrent refreshes from several browser tabs or requests conflict and force new logins | Move sessions to a shared Redis store, or accept and document the forced re-login behavior for affected users |
| Empty group headers | The identity provider does not send group claims, or the proxy is not configured to forward them, so Grafana receives no group data for role mapping | Confirm the group claim in a test token, enable group forwarding in the proxy, and check that Grafana role mapping reads the header that is actually sent |
| Nodes behave differently in HA | Each Grafana node or proxy instance keeps its own session store, so a request routed to another node is not recognized | Use one shared session store for every proxy instance and confirm that Grafana nodes share the same database, as the Grafana HA guidance requires |
| Stale roles after a role change | Grafana applies header-based role data at sign-in and, without enforced sync, does not refresh it on each request | Test role changes end to end, ask users to sign out and back in, and confirm the sync behavior of your Grafana edition before promising access changes |
How the auth proxy work is scoped and tested
The test plan for a Grafana auth proxy deployment proves three things before users depend on it: the proxy signs people in through each identity provider group, Grafana assigns the right role and organization to each group, and nothing outside the proxy can impersonate a user. Each identity provider group gets its own sign-in test with a named account, and the expected Grafana role and organization are written down beforehand. Forged header attempts come next. Send requests directly to the Grafana port and to any other path that bypasses the proxy, with headers such as X-WEBAUTH-USER set to an administrator account. Every attempt should fail. A failed forgery test is the evidence that the lockdown in the previous section actually works.
Role and organization checks should run per group, including the negative cases: a user outside the allowed groups must be refused, and a user whose group changes must lose access after the next sync. Because the proxy holds sessions in encrypted cookies by default, test a long session, a token refresh and a forced logout, and confirm which behavior your chosen session storage produces. Failover tests run against every Grafana node behind the load balancer, with the database and shared session state in place, so a user can reach any node and keep their identity after one node is stopped. Grafana's high availability guidance notes that alerting and Grafana Live need extra configuration, so include those in the test list.
Scope, deliverables and timelines are agreed in writing before work starts, and the written plan should name who signs off each test result. Documentation covers the final settings for both the proxy and Grafana, the test evidence, and a tested rollback path that returns users to the previous sign-in method. Confirm with your own team which identity provider groups, environments and change windows apply, because those determine the number of test cases and the effort involved. Ask any implementation partner to show the test script and rollback steps as part of the quote, not as an add-on after go-live.
How DeployOpen works on this
DeployOpen plans, builds, documents and supports Grafana behind an authenticating proxy inside your own infrastructure, whether the proxy is OAuth2 Proxy or another reverse proxy you already run. We start with the identity, network and trust decisions, then deliver a configuration you can review, test and operate.
How we scope
- We agree the scope in writing before work starts, covering the identity provider, proxy and Grafana versions involved.
- The scope records which headers the proxy sets, how roles and teams map, and which Grafana edition you run.
- We confirm how only the proxy will reach Grafana, including network paths, load balancers and any Kubernetes ingress.
How we build
- We configure the proxy to set identity headers and Grafana's auth proxy settings to trust only that proxy's address.
- We set up role mapping and enforce sync rules and test them with users in each group before go-live.
- We test header spoofing attempts directly against Grafana to confirm that requests bypassing the proxy are refused.
How we hand over
- You receive the proxy and Grafana configuration files, with the reasoning behind each trust boundary and header decision.
- We document the session storage choice, cookie secret handling and the steps to rotate them safely.
- We provide a runbook covering login failures, role mapping changes and upgrade checks for both the proxy and Grafana.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Retainer work can cover checks against new Grafana releases and proxy releases before you upgrade.
- Changes to identity providers, network paths or trusted proxy addresses can be reviewed and tested before they reach production.
