Skip to main content
Applies to BloodHound Enterprise
This is a SpecterOps-managed feature. If it is not enabled in your environment, contact your account team for assistance.
OpenHound for BloodHound Enterprise is deployed as a container and can be run in different environments, such as:
  • Bare-metal or virtual Linux server using Docker or Podman (e.g., Ubuntu, RHEL)
  • Cloud-native container service such as AWS Fargate
  • Self-managed Kubernetes cluster on-premises or in the cloud
  • Managed Kubernetes service such as Amazon EKS, Google GKE, or Azure AKS
The OpenHound container image is available on Docker Hub and includes the collectors for Github, Jamf, and Okta by default.
OpenHound currently runs one extension per container. Configure and start a separate OpenHound container for each extension you want to use.

​
Deployment process

To deploy OpenHound and run a collector:
1

Provision the environment

Provision a server with container (Docker/Podman) support, a Kubernetes cluster, or cloud-native container service to run OpenHound.
Ensure that the environment meets the system requirements.
2

Upload extension assets

Upload saved queries and Privilege Zone rules for each collector extension you want to run to your BloodHound Enterprise tenant.
3

Create an OpenHound collector client

Create an OpenHound collector client on your BloodHound Enterprise tenant to obtain the necessary API credentials for OpenHound to upload data.
4

Configure the OpenHound container

Configure the OpenHound runtime and collector-specific configuration parameters.
5

Deploy the OpenHound container

Use one of the supported methods to deploy the OpenHound container.
6

Run the collector

Run an On Demand scan or create a data collection schedule to start the collector and collect data from your environment.

​
Enterprise configuration

OpenHound configuration defines how each collector container connects to BloodHound Enterprise, authenticates to the source system, and controls the collection pipeline. Each OpenHound container requires three groups of settings:
  • BloodHound Enterprise destination settings identify the tenant and collector client that receive the collected data.
  • Collector source settings authenticate to the system being collected, such as Github, Jamf, or Okta.
  • Runtime settings control operational behavior such as logging, retry handling, worker counts, and file handling.
Define non-sensitive runtime settings in config.toml and store credentials or tokens in secrets.toml, environment variables, or your container platform’s secret management system. This separation helps you reuse the same operational defaults across collectors while keeping each collector’s credentials isolated.
For the required BloodHound Enterprise destination parameters, file layout, environment variable names, and common runtime options, see Configuration.

​
Collector-specific configuration

Each collector requires additional configuration parameters that are unique to its data source. These settings can be defined in the secrets.toml file or supplied via environment variables. For details on the available parameters, refer to the collector-specific configuration documentation using the links below.

Github

View the required configuration parameters for the Github collector.

Jamf

View the required configuration parameters for the Jamf collector.

Okta

View the required configuration parameters for the Okta collector.

​
Server/container requirements

Use these requirements to size the host, virtual machine, or container service that runs OpenHound. Actual resource usage depends on the collector, the size of the source environment, and the number of objects OpenHound processes during each collection run.
The requirements vary depending on the size of the environment being collected/converted. Container storage persistence is not required. However, it is recommended to have a persistent storage for the logs for troubleshooting.OpenHound stores logs in the ~/.local/share/openhound/logs directory. You can configure log rotation by time or file size in the config.toml file.