Skip to content

Security Guide: Overview

This guide describes Logster's security posture — how events are validated as they flow through the pipeline, how authentication and authorization are configured, and how to harden a deployment for production. It is written for platform engineers, security architects, and anyone responsible for putting Logster in front of real traffic.

What this guide covers

Page You'll learn...
Overview (this page) Logster's current security posture at a glance — what's enforced, what's not, and which surfaces matter most.
Security Validations How the pipeline validates events at ingestion, how malformed data is handled, and what guarantees each stage provides.
Configuration How to configure authentication, CORS, TLS, and reverse-proxy hardening for production deployments.

Current security posture at a glance

Logster in its default build is development-oriented. The Compose stack prioritizes "it just works on localhost" over production-grade defense-in-depth. Before shipping Logster to a real environment, you must close the gaps documented in Admin Guide: Important Considerations.

A short summary of what's enforced out of the box versus what needs to be added:

Surface Default build Production expectation
Dashboard (port 5001) No auth (DISABLE_AUTH=true) Reverse proxy with OIDC/SAML
REST API (port 8080) No auth, CORS ["*"] Reverse proxy with bearer tokens, CORS restricted
Elasticsearch (port 9200) xpack.security.enabled: false Security enabled, TLS, firewalled
Kafka (port 9092) PLAINTEXT listeners SASL/SSL
Grafana (port 3000) Default admin password logster, anonymous read enabled Password rotated, anonymous access off
Kibana (port 5601) No auth Behind reverse proxy
Tracing backend (Tempo) No auth Behind reverse proxy

None of these are bugs. They are documented defaults that Logster Support expects every customer to replace before production use.

Threat model

Logster's threat model reflects its role as a detection platform. There are four main categories of risk to think about:

1. Unauthorized access to the detection surface

The most important risk is someone reaching the dashboard or REST API without authentication. Consequences include:

  • Read-only exposure. An attacker who can list alerts learns what Logster has already detected — and, by elimination, what it has missed. This is a detection-evasion goldmine.
  • Write exposure. An attacker who can PATCH alerts or POST feedback can close real alerts as false positives before the analyst sees them. This is a kill-switch for the entire detection pipeline.

Mitigation: put every user-facing port behind an auth-enforcing reverse proxy. See Configuration.

2. Tampering with ingestion

Logster trusts the events arriving on its raw Kafka topics. Anyone with write access to sysmon-logs, linux-auditd-logs, or the eBPF topics can inject arbitrary events and either poison the model's view of an endpoint or flood the pipeline to drown real activity.

Mitigations:

  • Kafka access controls. In production, Kafka must not use PLAINTEXT listeners. Use SASL/SSL with ACLs that grant only the intended shippers write access to the raw topics.
  • Collector identity. Winlogbeat / Splunk UF / rsyslog must authenticate to Kafka with per-host or per-fleet credentials.
  • Topic ACLs. Only the normalizer should have write access to normalized-endpoint-events; only the inference service to logster-inference-results; only the alerts service to logster-alerts.

3. Denial of service

A noisy or malicious endpoint can produce enough events to saturate the normalizer or the inference service. Logster does not have built-in per-endpoint rate limits — the assumption is that Kafka absorbs bursts durably, and operators scale the pipeline horizontally.

Mitigations:

  • Monitor metrics. inference_time_ms and active_endpoints are the early-warning signals. See Admin Guide: Daily Operations.
  • Size Kafka appropriately. Partition counts set the upper bound on parallel consumption.
  • Linux idle allow-list. Keep inference.use_idle_allowlist enabled to avoid wasting GNN cycles on known-safe idle daemons.

4. Supply chain — models and containers

Logster loads pre-trained GNN weights from .pt files at startup. If those files are swapped by an attacker, every prediction on every endpoint can be manipulated.

Mitigations:

  • Mount model volumes read-only. The default Compose file already does this: deploy/docker-compose.yml.
  • Verify model checksums after a model swap. See Model Deployment.
  • Use signed container images in production.

What the pipeline guarantees

Even in the default build, a few things are enforced throughout the pipeline. Understanding them helps you reason about where your controls need to sit.

  1. Per-endpoint ordering. Every event is keyed by tenant_id:endpoint_id, so events from a given host are guaranteed to be processed in order even when the pipeline is scaled across multiple consumer replicas.
  2. Tenant isolation at the data level. Every record carries a tenant_id. Queries can filter on it. However, Logster does not enforce tenant isolation at the API layer — the REST API happily returns any tenant's alerts if you pass the tenant id. If multi-tenant isolation matters to you, see Configuration.
  3. Immutable events. Normalized events written to Kafka and Elasticsearch are never updated in place. Every event is a write-once record. This simplifies audit and forensic investigation.
  4. Alert lifecycle tracking. Every transition on an alert records the new status, updated_at, resolved_by, and optional analyst_notes. This is the audit trail — treat it as such and ensure the resolved_by field is trustworthy (which requires authenticated access to the API, which requires a reverse proxy, which requires you to read Configuration).

Where to go next