Carbon Black (WIP)
Pulls the device list from Carbon Black Cloud — the endpoints its sensor is installed on, with policy, network and OS detail.
| Type name | carbon_black |
| Creates | Endpoints |
| Runs on | A sensor with outbound reach to the Carbon Black Cloud API |
| Presence flag | cbd_exists |
| Field prefix | cbd_ |
The Carbon Black type is defined, its fields are declared and the sensor-side fetch is implemented, but the backend's identification stage for this type is still unimplemented. In practice that means a run can collect device data but will not produce asset change entries yet. Treat this page as a description of the intended integration, not of a working end-to-end path.
What it contributes
The declared fields cover:
- Identity — device ID, device name, logged-in user name
- Network — last internal IP, last external IP, subnet, last location
- Platform — OS, OS version, OS major version
- Policy and agent — current sensor policy name, policy name, sensor kit type, AV pack version, target priority
- Lifecycle timestamps — registered, last contact, last reported, last shutdown, last policy updated, last device policy changed
- Context — AD/LDAP path from device metadata, virtual machine flag
Requirements
The integration is outbound-only: it is a scheduled API client, so nothing is installed on the Carbon Black side, nothing is deployed to the endpoints, and nothing has to reach into the deployment.
Network access
| From | To | Protocol | Port |
|---|---|---|---|
| The sensor running the integration | The Carbon Black Cloud API host for your region, as configured in URL | HTTPS over TCP | 443 |
One host: the credential is sent as request headers rather than exchanged at a separate token endpoint, so the device search is the only call made.
Document the regional Carbon Black Cloud API hostnames, so this rule can be written without reading it off the console first. Tracked with the permissions TODO under Permissions in Carbon Black.
Access in Carbon Black
| Need | Why |
|---|---|
| An account that can create API keys under Settings → API Access | The credential is a Custom API key plus its access level — see Permissions in Carbon Black |
| An access level granting read on devices | The run issues a device search; nothing else is called |
| The organisation key and organisation ID from the console | Both are needed and they are different values — the info note under Configuration explains which is which |
In this deployment
| Need | Why |
|---|---|
| A registered, healthy sensor | The integration runs on a sensor, on the platform's schedule — see Sensors |
There are no special host requirements beyond a sensor that is checking in. The work is a paged HTTPS search per run, so it adds no meaningful load and needs no local storage.
Configuration
| Field | Required | Notes |
|---|---|---|
| Name | Yes | Label for this instance |
| URL | Yes | Carbon Black Cloud API host for your region |
| Organization ID | Yes | Org ID from the console |
| Organization key | Yes | Org key from the console |
| Token | Yes | API secret, paired with the API ID |
| Sensor | Yes | Sensor that will run the integration |
| Ignore SSL | No | Skips certificate validation |
Carbon Black exposes both. The org key is the short alphanumeric string used in API paths; the org ID is numeric. The integration uses the org key when building the device-search request, so a mix-up produces a 404 rather than an auth error.
Permissions in Carbon Black
Create an API key of type Custom under Settings → API Access, backed by an
access level that grants read on devices. The integration issues a
POST device search against
/appservices/v6/orgs/{orgKey}/devices/_search.
Confirm the minimum permission entry (device → READ) for the current Carbon
Black Cloud console generation, and document the regional API hostnames.
See also
- Integrations overview — the shared configuration model
- CrowdStrike — the more complete EDR source, if you run both