Skip to content

Admin Guide: Authentication

This page documents Logster's current authentication posture, the DISABLE_AUTH flag on the dashboard, and the recommended production pattern for putting Logster behind an authenticating reverse proxy.

[!WARNING] Logster's built-in services do not ship authentication in the default build. Treat this page as a must-read before exposing any Logster URL beyond localhost.

Current state

Surface Auth in default build How it's configured
Dashboard (port 5001) Disabled via DISABLE_AUTH=true Environment variable in deploy/docker-compose.yml
REST API (port 8080) None Middleware is not wired in services/api/src/logster_api/app.py
Elasticsearch (port 9200) Disabled xpack.security.enabled: "false" in deploy/docker-compose.yml
Kibana (port 5601) None No security configuration
Grafana (port 3000) Admin password only (admin / logster); anonymous read enabled GF_AUTH_ANONYMOUS_ENABLED=true + GF_SECURITY_ADMIN_PASSWORD=logster
Prometheus (port 9090) None Prometheus has no built-in auth
Kafka (port 9092) None (PLAINTEXT listeners) Broker configuration

This posture is intentional for a single-host development stack. Every port listed above assumes it is only reachable from the host machine itself.

DISABLE_AUTH on the dashboard

The Logster dashboard (Express + React) has a pluggable authentication layer that is bypassed when the DISABLE_AUTH environment variable is set to "true". The default deploy/docker-compose.yml sets this flag so that the development stack "just works" — open http://localhost:5001 and you are in.

dashboard:
    environment:
        ES_HOST: http://elasticsearch:9200
        DISABLE_AUTH: "true"
        NODE_ENV: production

[!IMPORTANT] Flipping DISABLE_AUTH to "false" does not automatically hand you a login screen — it enables the dashboard's pluggable auth layer, which then needs to be wired to a real identity provider. For most production deployments, the simpler path is to leave DISABLE_AUTH enabled but terminate authentication at a reverse proxy, as described below.

The REST API has no auth

create_app() in services/api/src/logster_api/app.py wires only the CORS middleware. There is no authentication middleware mounted, and no token validation on any endpoint.

This means:

  • Anyone who can reach port 8080 can list and modify alerts.
  • Anyone who can reach port 8080 can submit analyst feedback as any identity string they choose.

For any real deployment, this must be closed. The recommended pattern is below.

The simplest, safest way to add authentication to a Logster deployment is to put an auth-enforcing reverse proxy in front of every user-facing port, and keep Logster itself listening only on localhost or an internal bridge network.

Architecture

┌─────────────────────────────────────────────┐
│            Public / corporate network       │
└────────────────────┬────────────────────────┘
                     │
                     ▼ (TLS + auth)
┌─────────────────────────────────────────────┐
│  Reverse proxy (nginx / Traefik / Caddy)    │
│  - TLS termination                          │
│  - OIDC / SAML / Basic auth                 │
│  - Route /dashboard → :5001                 │
│  - Route /api       → :8080                 │
│  - Route /grafana   → :3000                 │
└────────────────────┬────────────────────────┘
                     │ (plaintext, internal only)
                     ▼
┌─────────────────────────────────────────────┐
│              Logster stack                   │
│  Dashboard (5001) │ API (8080) │ Grafana    │
└─────────────────────────────────────────────┘

Implementation checklist

  1. Bind Logster to localhost, not all interfaces. Change each published port in deploy/docker-compose.yml to bind only 127.0.0.1:
api:
    ports:
        - "127.0.0.1:8080:8080"
dashboard:
    ports:
        - "127.0.0.1:5001:5000"

  1. Put a reverse proxy on the host — nginx, Traefik, or Caddy all work. Terminate TLS there, enforce authentication there, and forward to the localhost-bound Logster services.

  2. Enforce authentication. At minimum, HTTP Basic auth with a strong shared password. Better: OIDC with your corporate identity provider (Keycloak, Okta, Azure AD, Google Workspace).

  3. Set api.cors_origins in deploy/service-config.yaml to your actual dashboard origin instead of "*".

  4. Verify that port 8080, 5001, and 3000 are unreachable from outside the host. nmap from another machine should show them closed.

TBD — SaaS auth topology. Confirm how Logster Support operates authentication in the Logster SaaS deployment model (reverse proxy vendor, identity provider integration) before documenting it here. The on-prem deployment model leaves the authentication topology to the customer.

What about authorization?

Logster does not currently implement role-based access control. Everyone who passes authentication sees every alert, every endpoint, and every analytics panel. If you need to segment analysts by team, tenant, or data sensitivity, the current options are:

  • One Logster instance per tenant, with tenant-specific data never commingled.
  • Multiple tenants in one instance, using the tenant_id field on every alert and event, combined with a reverse-proxy layer that restricts which tenant_id query parameter each analyst may pass to the REST API.

The second option is fragile — enforcing tenant_id at a proxy layer is error-prone. The first is recommended unless you have a strong reason otherwise.

Production hardening checklist

Before exposing Logster beyond a dev environment, confirm each of these:

  • [ ] Reverse proxy terminates TLS for every user-facing port.
  • [ ] Reverse proxy enforces authentication on dashboard, API, Grafana, Kibana, Prometheus, and Tempo.
  • [ ] 127.0.0.1-bound port publishing on the Compose file.
  • [ ] api.cors_origins tightened to the dashboard origin.
  • [ ] Grafana admin password changed from logster.
  • [ ] Elasticsearch security enabled if ES is reachable outside the Compose network.
  • [ ] Kafka listeners moved off PLAINTEXT if Kafka is reachable outside the Compose network.

For the full prod checklist, see Important Considerations.

Next steps