Enable TLS and secure cookies on Grafana

The fix/etc/grafana/grafana.ini

[server]
protocol = https
http_port = 3000
domain = grafana.example.com
root_url = https://grafana.example.com/
cert_file = /etc/grafana/certs/grafana.crt
cert_key = /etc/grafana/certs/grafana.key
min_tls_version = TLS1.2

[security]
cookie_secure = true
cookie_samesite = strict

What the defaults are

[server]
protocol = http
http_port = 3000
min_tls_version = ""

[security]
cookie_secure = false
cookie_samesite = lax

Grafana serves plain HTTP out of the box, and cookie_secure = false follows from it — a Secure cookie would not be sent over the plaintext connection Grafana is expecting.

The consequence is direct: the session cookie that represents a logged-in Grafana user, up to and including the Server Admin, travels unencrypted. Anyone positioned on the path can lift it and replay it. No password needed, and password rotation does not help.

Two ways to do this, and one is more common

Terminate TLS in Grafana with cert_file and cert_key, as the fix block shows. Simplest when Grafana is directly exposed.

Terminate at a reverse proxy — nginx, Apache or HAProxy — and speak HTTP to Grafana over loopback. This is the more common production arrangement and it is a perfectly good answer, with one condition people miss:

[server]
protocol = http
http_addr = 127.0.0.1
root_url = https://grafana.example.com/

[security]
cookie_secure = true

cookie_secure = true is still required, even though Grafana itself speaks HTTP. The cookie’s Secure flag is about the browser’s connection to the proxy, not the proxy’s connection to Grafana. Leaving it false because “Grafana is on HTTP” reintroduces the whole problem one hop further out.

http_addr = 127.0.0.1 is the other half — without it Grafana listens on all interfaces, and the plaintext port stays reachable alongside the TLS one. And root_url must be the public HTTPS URL or Grafana will generate broken links and OAuth redirects.

Cookie flags

cookie_samesite defaults to lax, which is reasonable. strict is better for an internal tool where no cross-site navigation into Grafana is expected; it will break inbound links that expect to arrive already-authenticated, such as an alert notification that deep-links to a panel.

Grafana sets HttpOnly on its session cookie regardless, so JavaScript cannot read it. That is a good default and worth knowing so you do not go looking for a setting.

HSTS

[security]
strict_transport_security = true
strict_transport_security_max_age_seconds = 31536000

Defaults to false. Enable it once HTTPS is confirmed working — includeSubDomains and preload options exist here too, and carry the same one-way risk as anywhere else. If a reverse proxy already sets HSTS, set it in one place, not both.

Verify it worked

Confirm the protocol on the wire, not in the file:

curl -sSI https://grafana.example.com/login | head -1
openssl s_client -connect grafana.example.com:443 -brief </dev/null

Check the cookie flags on a real login response — this is the claim that matters:

curl -sS -i -X POST https://grafana.example.com/login \
  -H 'Content-Type: application/json' \
  -d '{"user":"'"$GF_ADMIN_USER"'","password":"'"$GF_ADMIN_PASS"'"}' \
  | grep -i 'set-cookie'

Expect grafana_session=...; Path=/; Secure; HttpOnly; SameSite=Strict. A missing Secure means the cookie will be sent over plaintext if anything ever reaches Grafana that way.

Confirm the plaintext port is not still open in parallel:

sudo ss -lntp | grep grafana
curl -sS -o /dev/null -w '%{http_code}\n' http://grafana.example.com:3000/login

Behind a proxy, expect Grafana bound to 127.0.0.1:3000 only.

Before you apply this

The setting most likely to break things is root_url, not the certificate. Get it wrong and Grafana keeps serving pages while generating redirects to the wrong host — OAuth logins fail with an opaque error, alert notification links point somewhere useless, and rendered panel images break. Set it to the exact public URL including scheme and trailing slash.

Grafana runs as the grafana user and reads the certificate after dropping privileges, so the key must be readable by that user — the same arrangement as memcached and unlike nginx or HAProxy, where a privileged parent reads it first:

sudo chown grafana:grafana /etc/grafana/certs/grafana.key
sudo chmod 400 /etc/grafana/certs/grafana.key
sudo -u grafana test -r /etc/grafana/certs/grafana.key && echo readable

Getting this wrong produces a Grafana that will not start, with the reason in the journal:

sudo journalctl -u grafana-server -n 50 --no-pager

cookie_samesite = strict breaks deep links that arrive from another site already expecting a session — most visibly, links in Slack or email alert notifications. If your team relies on those, lax is the pragmatic choice and still blocks the cross-site request forgery cases that matter.

Certificate renewal must restart Grafana, and a restart drops active sessions and in-flight queries. Automate the restart with the renewal or you will get a confusing partial outage when the certificate rolls.

Related

• Change the Grafana admin password — the credential this stops leaking in transit.
• Security headers and CSP — the other browser-side settings, and one bad default.