Skip to main content

​
Forwarding overview

Asymptote Managed is the forwarding path that lands Beacon endpoint events on the Asymptote dashboard without any customer-run infrastructure. Beacon stays the local JSONL producer. A Vector forwarder on the endpoint tails the runtime JSONL log and the inventory log and POSTs gzip-compressed NDJSON batches over HTTPS to Asymptote’s ingest service, authenticated with a key issued to that one device. This is the only Beacon destination that sends telemetry to an Asymptote-run endpoint, and it is opt-in. Beacon’s default remains local-only; nothing is forwarded until a member of your Asymptote organization approves the device in the browser and the forwarder is started with the resulting key. Revoking the device from the dashboard’s Beacon Endpoints page stops ingestion within about a minute. Generate the pack with beacon endpoint asymptote. beacon endpoint connect performs enrollment and runs the forwarder as a service; the pack is for running or inspecting the same forwarder by hand.

​
What leaves the machine

Every line written to runtime.jsonl after the forwarder starts, and every line of inventory_state.jsonl, exactly as Beacon wrote them locally. Beacon’s retention and redaction settings apply before a line is written, so they apply to what is forwarded. The ingest service adds a tenant block (organization, device, approving user, receive time) to every event server-side and ignores any tenant fields sent by the client. Nothing else is sent. The forwarder does not read prompts, files, environment variables, or shell history beyond what the events already contain.

​
How identity works

Each enrolled machine gets its own key. Enrollment is a browser flow: the CLI registers the machine’s hostname, operating system, and Beacon version, opens the dashboard, and a signed-in member of the organization chooses the organization and clicks Approve. The key is minted only after that click and is shown to the CLI once. It is stored in a 0600 secrets file that Vector reads through its secret backend, so the key is in neither vector.toml nor the environment of the Vector process. The ingest service checks three things on every request: the key is known and not revoked or expired, the user who approved the device is still a member of the organization, and the organization is enabled for managed ingest. Those checks are cached for one minute, which is the longest a revoked device can keep sending.

​
Wire contract

  • POST <ingest url>/v1/ingest/runtime and POST <ingest url>/v1/ingest/inventory with Authorization: Bearer <device key>, Content-Type: application/x-ndjson, and Content-Encoding: gzip. HTTPS only; the CLI and pack refuse other schemes.
  • Each line must be a Beacon endpoint event: vendor=beacon, product=endpoint-agent, schema_version, a parseable timestamp, and event.kind and event.action. Malformed lines are counted and reported; a batch fails only if every line is bad.
  • Limits per request: 8 MiB compressed, 10,000 lines, 1 MiB per line. The pack batches at 5 MB or 5,000 events or 60 seconds, whichever comes first.
  • Responses: 200 with accepted and rejected counts and the object written; 401 for an unknown, revoked, or expired key, or an approver who left the organization; 403 when the organization is not enabled; 413 when a limit is exceeded; 429 and 5xx are retried by Vector with backoff. Other 4xx responses are dropped, which is the intended behavior for a revoked key.
  • GET /v1/ingest/health (or HEAD) with the bearer key returns 200 or 401 and is the credential check the forwarder’s startup healthcheck and the smoke-test script use.

​
Offline behavior

Vector keeps reading into a disk buffer (512 MiB for runtime, 256 MiB for inventory) while the network is unavailable and drains it when connectivity returns. The service accepts events with old timestamps, so a laptop that was asleep or on a flight catches up without loss, up to the buffer size. A batch whose acknowledgement was lost is re-sent; the dashboard’s storage collapses duplicates on Beacon’s deterministic event id.

​
Install the pack

Generate the Asymptote pack for a system-mode deployment
The pack includes README.md, vector.toml, asymptote-ingest-smoke-test.sh, and sample-event.jsonl. Run Vector by hand with the environment described in beacon endpoint asymptote print-config.

​
Validation

  1. Run sh ./beacon-asymptote-pack/asymptote-ingest-smoke-test.sh with BEACON_ASYMPTOTE_INGEST_URL and BEACON_ASYMPTOTE_SECRETS_FILE set. It checks the key (200 valid, 401 revoked) and posts the log tail once.
  2. With Vector running, write a validation event: beacon endpoint asymptote validate.
  3. Within a minute or two, search the dashboard telemetry page for Beacon endpoint Asymptote validation event.

​
Revocation

Revoke a device, or every device a person approved, from the dashboard’s Beacon Endpoints page. The ingest service rejects the key within about a minute, Vector logs 401 responses and drops those batches, and the forwarder needs a new enrollment to resume. Removing a user from the organization has the same effect on every device they approved.

beacon endpoint asymptote

Generate the pack, print the config, and write validation events.

Data flow and threat model

Where this channel sits among Beacon’s trust boundaries.

Retention and redaction

Controls applied before events are written or forwarded.

Log forwarding

Every other destination Beacon supports.