Skip to main content

Cribl Edge

Visualize your Cribl Edge deployment in JupiterOne — the Fleets you organize your telemetry agents into and the Edge Nodes reporting to your Leader, with the host, OS, and version each Node reports. Edge Nodes running on EC2 instances or Azure VMs are correlated to those hosts in the graph, so you can see which of your compute is covered by telemetry collection and monitor Fleet membership and agent versions through queries and alerts.

Installation​

This integration reads your Cribl Edge deployment through the Cribl Control Plane REST API — the Edge Fleets configured on your Leader and the Edge Nodes reporting into them, including each Node's hostname, operating system, architecture, Cribl version, and connection state. It is read-only: it issues only GET requests against the Fleets and Nodes collections and never modifies your Cribl configuration.

Nodes that report AWS or Azure metadata are mapped to the matching aws_instance or azure_vm entity already in your graph. Those relationships are only created when the target host is present — the integration never creates placeholder cloud instances.

Prerequisites​

  • A Cribl Edge deployment, either on Cribl.Cloud (including Hybrid) or a customer-managed (on-premises) Leader.
  • The base URL of that deployment:
    • Cribl.Cloud — your workspace URL, in the form https://${workspaceName}-${organizationId}.cribl.cloud.
    • On-premises — your Leader URL, including the port, for example https://leader.example.com:9000.
  • Credentials with read access to Worker Groups and Fleets — see below.
  • Access to JupiterOne with permission to configure integrations.
note

Customer-managed Leaders are commonly deployed inside a private network and are not reachable from the internet. In that case, run this integration through a JupiterOne Collector inside your network.

Configuration in Cribl​

This integration supports two authentication methods. Choose the one that matches your deployment when you create the instance in JupiterOne; each presents its own set of fields.

Cribl.Cloud / Hybrid (OAuth2)​

An Organization Owner or Admin creates an API Credential in the Cribl.Cloud UI, which yields a Client ID and a Client Secret. The integration exchanges those for a bearer token against https://login.cribl.cloud/oauth/token.

The credential needs the user:read:workergroups scope, which grants read access to Worker Groups and Edge Fleets. This scope is part of the default set granted to API Credentials.

caution

The Client Secret is shown only when the credential is created. Record it before leaving the page — if you lose it, you must create a new credential.

See the Cribl API authentication guide for the current steps.

On-premises (Username/Password)​

The integration posts a username and password to /api/v1/auth/login on your Leader and uses the returned bearer token. Create a dedicated Cribl user for it rather than reusing an operator account.

Grant that user read access to your Edge Fleets. In the Roles and Policies model this is the built-in reader_all role, which carries the GroupRead policy across all Worker Groups and Fleets; in the Members and Permissions model, grant Read Only at the Worker Group level.

note

Role- and permission-based access control requires a Cribl Enterprise license. On deployments without one, any authenticated user has full access and no explicit grant is needed.

See the Cribl Roles documentation for details.

Configuration in JupiterOne​

To install the Cribl Edge integration in JupiterOne, navigate to the Integrations tab in JupiterOne and select Cribl Edge. Click New Instance to begin configuring your integration.

Creating an instance requires the following:

  • The Account Name used to identify the Cribl Edge account in JupiterOne. Ingested entities will have this value stored in tag.AccountName when the AccountName toggle is enabled.

  • Description to assist in identifying the integration instance, if desired.

  • Polling Interval that you feel is sufficient for your monitoring needs. You may leave this as DISABLED and manually execute the integration.

  • The authentication method matching your deployment, and its fields:

    Cribl.Cloud / Hybrid (OAuth2)

    • Your Workspace URL — for example https://main-acmecorp-abcd1234.cribl.cloud.
    • The Client ID and Client Secret of the API Credential you created.

    On-Premises (Username/Password)

    • Your Leader URL — for example https://leader.example.com:9000.
    • The Username and Password of the Cribl user you created.

  • Optionally, Ingest Disconnected Nodes. Enabled by default, meaning Edge Nodes the Leader currently reports as disconnected are still ingested. Disable it to ingest only Nodes actively connected to the Leader.

Click Create once all values are provided to finalize the integration.

note

The /api/v1 suffix is appended to your URL automatically. A trailing slash, or a URL you paste with /api/v1 already on it, is handled for you.

Data sources​

You can narrow what the integration collects from the instance's ingestion source settings. Fetch Edge Fleets underpins Fetch Edge Nodes — Nodes are attached to the graph through their Fleet, so disabling Fleets also disables Node collection.

Ingestion sourceData collected
Fetch Edge FleetsEdge Fleets on the Leader, their deployed configuration version and Node count, and Subfleet nesting.
Fetch Edge NodesEdge Nodes, with hostname, OS and architecture, Cribl version, connection state, and cloud metadata.

Next steps​

Now that your integration instance has been configured, it will begin running on the polling interval you provided, populating data within JupiterOne. Continue on to our Instance management guide to learn more about working with and editing integration instances.

Additional resources​