Warden Agent

Every deployment node runs a lightweight agent called Warden. It is the only software that communicates between your infrastructure and the LaserData control plane - and it does so entirely on its own terms.

Why Pull-Based

Traditional deployment agents use a push model - the control plane connects to your servers, runs commands, and pushes configuration. This requires open inbound ports, SSH access, or cloud-specific agents like AWS SSM.

Warden takes the opposite approach:

• Warden initiates all connections outbound to the control plane over HTTPS (port 443)
• The control plane never connects inbound to your infrastructure
• No SSH, no SSM, no open ports - your firewall only needs to allow outbound HTTPS

This means that even if the control plane is fully compromised, an attacker cannot push commands to your VMs. There is no inbound attack surface.

Deployments are also fully network-isolated by default. No traffic reaches your deployment endpoints until you explicitly create Access Rules - this includes LaserData itself. Our control plane orchestrates infrastructure but has no network access to your data or endpoints.

Architecture

What Warden Manages

On each node, Warden is responsible for:

Stream UI

The Stream UI is the in-browser data explorer for an Iggy deployment - streams, topics, partitions, messages, consumer groups, and connected clients. It ships as part of the Console, but the data path stays between your browser and the deployment node.

Data isolation

• Direct browser ↔ Warden - once Stream UI loads in your browser, it calls Warden's HTTP proxy on the deployment node directly. Iggy data and messages travel only between the user's browser and the customer-owned node.
• Control plane is never on the data path - the LaserData backend serves the Stream UI front-end as static assets and is not involved in the data flow afterwards. It never sees stream contents, message bodies, or query results.
• Isolated from the surrounding Console - the Stream UI runs in a sandboxed frame with its own origin, so a compromise of the surrounding Console cannot read its data.
• Short-lived signed session - access is authorized by a per-deployment, per-user session token signed with the same Ed25519 key pair that signs Warden tasks. Tokens expire in minutes, and Warden verifies the signature on every request.

Network requirements

Warden's HTTP proxy listens on the same ports as the Iggy HTTP API (80/443), so the iggy_http toggle gates it. To use Stream UI from a browser, the user's browser IP must be allowlisted by an Access Rule with iggy_http: true on the target deployment - LaserData does not proxy on the customer's behalf and no LaserData-owned IP is required in the rule.

Task System

All operational changes - configuration updates, upgrades, certificate rotations - flow through a cryptographically signed task system:

1. An action is triggered (via Console, API, or automated process)
2. The control plane creates and signs the task
3. Warden polls for new tasks on its next cycle
4. Warden verifies the signature, then executes the task
5. Warden reports completion or failure back to the control plane

Warden rejects any task with an invalid signature. This ensures tasks cannot be tampered with in transit and always originate from the legitimate control plane.

Upgrades and Rollbacks

Upgrades are fully automated and zero-downtime:

1. A new version is published and a task is sent to Warden
2. Warden downloads the new binary, verifies its cryptographic signature, and swaps it in atomically
3. If the new version fails to start, Warden automatically rolls back to the previous version

Warden can also upgrade itself without stopping Iggy or Connectors - managed services continue running uninterrupted during a Warden self-upgrade.

All binaries (Warden, Iggy, Connectors) are cryptographically signed. Warden rejects any binary that fails verification, preventing supply chain attacks.

Credential Scope

Each Warden agent authenticates with a token scoped to a single node. If a token is compromised, the blast radius is minimal:

Network Requirements

No inbound firewall rules required. No SSH, no SSM, no bastion hosts.