Schildmark

Appearance

Architecture ​

A Schildmark stack is a set of containers defined in one Docker Compose file and configured by one file, theseus.env. Everything a person or an endpoint uses goes through one HTTPS address. Monitoring agents use one more port, TCP 1514.

Schildmark architectureBrowsers and endpoints reach the Schildmark stack on HTTPS 443; monitoring agents use TCP 1514. The stack calls out to the LLM endpoint, vendor APIs and vulnerability feeds; the Leitstand node dials out to the provider control plane.Your usersAnalysts' browsersconsole, sign-in, analyst, SIEMEndpointsMonitoring agentSchildmark Agent (optional,for patching)Your server(s): the Schildmark stackweb (Caddy)TLS, one origin, pathsManageragents connect hereIndexeralerts, inventory, stateSchildmark Console/Keycloak sign-in/authSchildmark Analyst/aiSIEM dashboard/siemEnrol + patch/enroll /agentvuln-verify, connectors, scannerops (health), reportingLeitstand nodeapplies config, reports healthOutside servicesLLM endpointOpenAI-compatible, optionalVendor APIsAWS, Cloudflare, Microsoft,Sophos (when configured)Vulnerability feedsNVD, MSRC, Canonical, CISASchildmark Leitstandprovider: config, licence,releases and image registry4434431514HTTPS out
Solid arrows: inbound connections to the stack. Dashed arrows: outbound connections the stack makes. Nothing else is published on the host.

Request paths ​

All browser and HTTPS endpoint traffic arrives at the web gateway (Caddy) and is routed by path:

PathService
/Schildmark Console (its API under /api)
/authKeycloak, the sign-in service
/ai/, /ai-analystSchildmark Analyst and its API; /ai-analyst/ws is a WebSocket
/siem/SIEM dashboard
/enroll/Enrolment: installers, Schildmark Agent downloads, the enrolment API
/agent/The Schildmark Agent API (signed long-poll), served by the patch service

Monitoring agents connect to the manager on TCP 1514 (AGENT_PORT). The manager's registration port 1515 is never published: agents are registered by the enrolment service through the manager API, so no shared registration password exists.

Internal services have no host port: the enrolment admin API, the patch service API, the scanner, vuln-verify, connectors, reporting, ops, the databases and Redis are reachable only on the stack's own Docker network.

Data flows ​

  • Telemetry. Agents send events to the manager (1514); the manager's Filebeat writes alerts and state to the indexer (alert and inventory indices). Connectors and vuln-verify write JSON lines to a shared feeds volume that the manager reads; the Schildmark ruleset classifies them.
  • State. Manager, Schildmark Analyst, scanner, patch and enrolment state live in the indexer. The console's configuration, roles and audit log live in its PostgreSQL database; Keycloak has its own.
  • Patching. vuln-verify verdicts become patch candidates; a job is planned, rehearsed on the machine (dry run), approved, installed and then verified by vuln-verify. The patch service reaches machines only through signed jobs to the Schildmark Agent. See Patching.
  • Control. The Leitstand node polls the Schildmark Leitstand over HTTPS. It applies configuration through the ./theseus command, writes the signed licence, and reports health and the agent list. It never listens on a port.

Topologies ​

A stack runs on one server (role all) or is split over two (roles core and app). The split follows the feed boundary: everything that writes files the manager reads stays with the manager.

Single-server and two-server topologiesOne server (role all)Every servicemanager, indexer, SIEM dashboardconsole, sign-in, enrolment, patchinganalyst, scanner, connectors, reportingin: 443, 80 analysts and agentsin: 1514 monitoring agentsout: 443 control plane, registry8 GB RAM minimumTwo servers (roles core and app)Application server (app)web gateway, console, Keycloak,enrolment, patch service, analyst,reporting, opsin: 443, 80 analysts and agents4 GB RAM minimumCore server (core)manager, indexer, SIEMdashboard, vuln-verify,scanner, connectorsin: 1514 monitoring agents6 GB RAM minimumprivate9200 550005601 9001
In a two-server install the core publishes 9200, 55000, 5601 and 9001 on its private address, for the application server only.
RoleServices
coreIndexer, manager and dashboard, vuln-verify, scanner, connectors
appWeb gateway, Keycloak, console, enrolment, patch service, Schildmark Analyst, reporting, ops
allEverything

See Install on two servers for the ports between them.

Gateways ​

By default (GATEWAY=builtin) Caddy on the server terminates TLS on 443. A cloud load balancer or Cloudflare Tunnel can sit in front instead; monitoring agents' TCP 1514 always needs a TCP path of its own. See Cloud gateways.

Security model in brief ​

  • One stack per organisation; nothing is shared between customers' stacks.
  • Every password, key and certificate is generated on your server at install time.
  • The Schildmark Agent and the Leitstand node authenticate with Ed25519 request signatures, and accept only jobs signed by a key they pinned when they enrolled.

More in Security and data flows.