Traefik Security: Lock Down the Dashboard, TLS and Docker Provider

Traefik sits at the edge of a cluster or Docker host and routes every inbound request, so its API, its certificate store and its connection to the container engine are some of the most valuable things on the platform. Securing Traefik is mostly about a handful of customer-side settings: how the API and dashboard are exposed, which TLS options and certificate resolvers apply, which middlewares sit in front of each router, and how Traefik reads configuration from Docker or Kubernetes. This guide walks through each of those with the exact option names from the Traefik documentation, a hardening baseline and the logging you need to detect misuse. It is written for platform, DevOps and security engineers running Traefik Proxy as an ingress controller or reverse proxy. For general TLS settings that apply to any edge proxy, see the TLS Configuration Baseline Guide.

This is an independent guide from NHI Mgmt Group, based on Traefik Labs' public documentation as of November 2026. It is not sponsored or reviewed by Traefik Labs. Product features change, so confirm settings against Traefik Labs' current documentation.

Key takeaways

• Route the dashboard, never publish it raw. Keep api.insecure at its default of false and expose the API through a router to api@internal with authentication and an IP allow list in front.
• The Docker provider is a privileged identity. Whatever can talk to the Docker API can control the host, so give Traefik a filtered, authenticated path to the engine rather than a bare socket mount.
• Set exposedByDefault to false. Then only containers labelled traefik.enable=true get routes, and nothing reaches the internet by accident.
• Define the default TLS option. Routers without their own TLS options use it, so a minimum version and cipher list set there covers every router at once.
• Trust forwarded headers only from known proxies. Use forwardedHeaders.trustedIPs and proxyProtocol.trustedIPs on entrypoints; the insecure variants are for testing.

How identity and access work in Traefik

Traefik Proxy does not keep its own user directory. Identity enters in three places, and each is controlled by configuration you own:

• Who can reach the API and dashboard: the API is off unless you set api (default false); turning it on also turns on api.dashboard. Access is then decided by the router you attach to the api@internal service and the middlewares on it.
• Who can reach applications behind Traefik: authentication is done by middlewares (basicAuth, digestAuth, forwardAuth) and network restriction by ipAllowList. Mutual TLS is a TLS option (clientAuth).
• What Traefik itself can reach: providers such as Docker and Kubernetes give Traefik credentials to read the container engine or cluster API. These are machine identities, and they usually carry more power than any human login on the proxy.

The API exposes a lot. Traefik's documentation lists GET endpoints including /api/rawdata (dynamic configuration, errors and status), /api/support-dump (an archive of anonymised static and runtime configuration) and, when api.debug is true, the Go /debug/vars and /debug/pprof/* endpoints. The docs state that running the API and dashboard in production is not recommended because they expose all configuration, including sensitive data, and that if you do run them they should at least sit behind authentication and authorisation, with the API port kept off public networks.

Admin roles and privileged access

Administrative power over Traefik is held by whoever can change its configuration, not by a role inside the product. Map those paths and treat each as privileged access.

Static configuration

The static file, CLI flags or environment variables decide entrypoints, providers, the API and certificate resolvers. Anyone who can edit them, or the Helm values that render them, can switch on api.insecure or point a provider elsewhere. Keep static configuration in version control with mandatory review, and restrict write access to the Traefik deployment.

Dynamic configuration

Routers, services and middlewares arrive from providers. With the Docker provider, anyone who can start a container with traefik.* labels can create a route. With Kubernetes, anyone who can create IngressRoute or Middleware objects can do the same in the namespaces Traefik watches. Two controls narrow this:

• providers.docker.exposedByDefault: false: the default is true; with false, containers without traefik.enable=true are ignored.
• providers.docker.constraints: a label expression using Label() or LabelRegex() that limits which containers Traefik will route. An empty value includes every detected container. The traefik.* namespace is reserved and cannot be a custom constraint key.

In Kubernetes, scope who can create Traefik custom resources through RBAC. See the Kubernetes RBAC Guide.

Securing the dashboard router

1. Create a dedicated entrypoint on an internal address or interface for administration.
2. Create a router with a Host() rule for an internal name, matching /api and /dashboard, with service api@internal.
3. Attach ipAllowList with the administrators' network ranges, then an authentication middleware. forwardAuth to your identity provider gives single sign-on and MFA; basicAuth is a fallback.
4. Attach TLS with a certificate from your resolver and the default TLS option.
5. Test from outside the allowed range (expect 403, the ipAllowList default rejectStatusCode) and without credentials (expect a challenge).

Rollback is simple: remove the router and the dashboard is unreachable while routing continues. Since the API is read-only GET, the main risk of exposure is disclosure of configuration and backend topology, which then helps an attacker target services.

Integrations, API tokens and service accounts

Traefik holds several machine credentials. Each needs an owner, a storage location and a rotation plan.

The Docker provider

Traefik's documentation warns that unrestricted Docker API access is a security risk, because whoever gains control of Traefik may reach the underlying host. It lists these mitigations:

• Authenticated transport: expose the Docker daemon over TCP with TLS client certificate authentication, or over SSH with public key authentication (Docker 18.09 and later).
• Request filtering: put a socket proxy in front of the daemon that allows only the read calls Traefik needs, optionally behind HTTP basic authentication (providers.docker.username and password).
• Docker authorisation plugins: enforce policy at the daemon.
• Exposure limits: keep the socket reachable only on a private network for Traefik, on a separate container from Traefik, or confined by kernel controls such as SELinux.

Keep providers.docker.tls.insecureSkipVerify at false so Traefik verifies the daemon's certificate. Set providers.docker.network so Traefik connects to containers over a known network. See the Container Runtime Security Guide for daemon-side protection.

Certificates and ACME

Traefik obtains certificates through a certificate resolver. Choose the challenge to suit your network:

Other settings worth knowing: acme.caServer defaults to the Let's Encrypt production directory, so point it at a staging or private CA while testing; acme.keyType defaults to RSA4096; acme.certificatesDuration defaults to 2160 hours with renewal starting 30 days before expiry. The documentation states that running several Traefik instances against Let's Encrypt with the built-in resolver is unsupported, and suggests cert-manager for high availability. Our recommendation: restrict acme.json to the Traefik user (mode 600), mount it on a persistent encrypted volume, and include it in backups so a restart does not trigger mass reissuance. See the ACME and Automated Certificate Management Guide.

Logging and detection

Traefik writes two streams: the application log (log.*) and the access log (accesslog.*). Both go to standard output unless a filePath is set.

• Application log: log.level defaults to ERROR. Use INFO in production if you want provider and configuration events, and log.format: json for parsing.
• Access log: turn on accesslog with format: json. Request headers are dropped by default (accesslog.fields.headers.defaultMode: drop). If you keep headers, set Authorization and Cookie to redact by name so credentials do not land in your SIEM.
• Query strings: accesslog.fields.queryParameters.defaultMode defaults to keep. Set it to drop where applications put tokens in URLs.
• Metrics: Prometheus metrics use the traefik entrypoint by default. Set manualRouting: true and route prometheus@internal behind the same protections as the dashboard, or keep the entrypoint internal. See the Prometheus Security.

Metrics that show the controls are working: number of internet-reachable routers with no authentication middleware (target zero for admin services); percentage of routers using the default TLS option or stricter; days to certificate expiry for the soonest certificate; count of containers routed without traefik.enable=true (target zero); time from Traefik release to production rollout.

Hardening baseline

Entrypoints

• Redirect HTTP to HTTPS: http.redirections.entryPoint.to: websecure with scheme: https (permanent by default).
• Forwarded headers: list load balancer ranges in forwardedHeaders.trustedIPs; keep forwardedHeaders.insecure at false, which the docs reserve for tests. Do the same for proxyProtocol.trustedIPs.
• Timeouts and limits: readTimeout defaults to 60s, writeTimeout to 0s (none) and idleTimeout to 180s. Set a write timeout suited to your applications. http.maxHeaderBytes defaults to 1 MiB.
• Path handling: leave http.sanitizePath at true; consider http.encodeQuerySemicolons: true where backends parse semicolons differently from Traefik.
• Entrypoint-wide middlewares: use http.middlewares to prepend a security headers middleware to every router, with fully qualified names such as secure-headers@file.

TLS options

Define the TLS option named default, which applies to any router without its own option:

• minVersion: VersionTLS12 (or VersionTLS13 where every client supports it). The docs discourage using maxVersion to switch off TLS 1.3.
• cipherSuites: list AEAD suites only for TLS 1.2. TLS 1.3 suites are not configurable.
• sniStrict: true: rejects clients that do not send a matching server name, so scanners hitting the IP do not receive the default certificate.
• clientAuth: for service-to-service routes, set caFiles and clientAuthType: RequireAndVerifyClientCert. See the mTLS Guide.

Without a configured certificate, Traefik generates a self-signed one; replace it in production.

Middlewares

• headers: set stsSeconds with stsIncludeSubdomains, contentTypeNosniff: true, frameDeny: true, a contentSecurityPolicy (trial it with contentSecurityPolicyReportOnly), referrerPolicy and permissionsPolicy.
• forwardAuth: set authRequestHeaders explicitly (all client headers go to the auth server when it is empty), list authResponseHeaders, verify the auth server certificate, and set maxBodySize and maxResponseBodySize, which the docs recommend to avoid memory exhaustion. trustForwardHeader is deprecated; rely on entrypoint trustedIPs.
• basicAuth: use BCrypt hashes from htpasswd -B (MD5 and SHA1 are also accepted; our recommendation is BCrypt only), set removeHeader: true so credentials do not reach the backend, and in Kubernetes prefer a secret of hashed entries over kubernetes.io/basic-auth secrets, which the docs note are not hashed.
• ipAllowList: without an ipStrategy the remote address is checked. If Traefik sits behind a load balancer, set ipStrategy.depth to match your exact proxy chain so a client cannot choose its own address through X-Forwarded-For.
• Rate limiting: apply rateLimit to login and API routes. See the Rate Limiting and API Abuse Guide.

Rollout order

1. Inventory routers from /api/http/routers on an internal instance and record which have authentication and TLS.
2. Set exposedByDefault: false in staging, label the containers that should be routed, and compare the router list.
3. Introduce the default TLS option and headers middleware in staging; test clients and use CSP report-only first.
4. Move the dashboard to a protected internal router and remove any api.insecure setting.
5. Replace the raw Docker socket with an authenticated or filtered endpoint; confirm routing still updates on container events.
6. Promote to production one entrypoint at a time, keeping the previous static configuration ready to redeploy as rollback.

Apply Traefik security updates promptly and watch Traefik's security advisories.

Common misconfigurations

• Dashboard published with api.insecure: true on a public port. Fix: remove it and route api@internal behind ipAllowList and forwardAuth.
• Every container routed automatically. With exposedByDefault left at true, a test or admin container started with a port can become reachable. Fix: set false and opt in by label.
• Docker socket mounted straight into the Traefik container. Anyone who gains control of the Traefik process then also controls the engine. Fix: socket proxy, TLS or SSH endpoint, separate container.
• forwardedHeaders.insecure left on after testing. Clients can then set their own source address and bypass IP restrictions. Fix: trustedIPs for your load balancers only.
• Credentials in labels and logs. basicAuth hashes in labels, DNS tokens in compose files, or Authorization headers kept in access logs. Fix: files or secrets, header redaction. See the Secrets Management Guide.
• acme.json lost or world-readable. Fix: persistent volume, mode 600 (our recommendation), backups and a staging CA for tests.

Practitioner checklist

• Confirm api.insecure and api.debug are false on every instance.
• Expose api@internal only through an internal router with ipAllowList and SSO through forwardAuth.
• Set providers.docker.exposedByDefault: false and use constraints where several teams share a host.
• Replace the raw Docker socket with a TLS, SSH or filtered socket proxy endpoint, and keep insecureSkipVerify off.
• Define the default TLS option with minVersion: VersionTLS12 or higher and sniStrict: true.
• Redirect HTTP to HTTPS on the web entrypoint and add a headers middleware with HSTS and CSP.
• Restrict forwardedHeaders.trustedIPs and proxyProtocol.trustedIPs to known load balancers.
• Store DNS and EAB credentials in a secrets manager with zone-scoped tokens; protect and back up acme.json.
• Enable JSON access logs with header redaction and alert on admin path requests and 401 bursts.
• Track Traefik security advisories and patch within your edge-component service level.

Standards and references

• Traefik Labs: API and Dashboard
• Traefik Labs: Docker Provider
• Traefik Labs: ACME Certificate Resolver
• Traefik Labs: TLS Options
• Traefik Labs: EntryPoints
• Traefik Labs: ForwardAuth Middleware
• Traefik Labs: Logs and Access Logs
• Traefik: Security Policy and Advisories

Related NHI Mgmt Group resources: TLS Configuration Baseline Guide · API Gateway Security Guide · Web Application Firewall Guide · Kubernetes Security Guide