> ## Documentation Index
> Fetch the complete documentation index at: https://bloodhound.specterops.io/llms.txt
> Use this file to discover all available pages before exploring further.

# OpenHound for BloodHound Enterprise

> Learn about the OpenHound framework for BloodHound Enterprise.

<img noZoom src="https://mintcdn.com/specterops/tTIczgde9H07oLXf/assets/enterprise-edition-pill-tag.svg?fit=max&auto=format&n=tTIczgde9H07oLXf&q=85&s=b682a26b342bde12302ec829e265bdb6" alt="Applies to BloodHound Enterprise" width="225" height="45" data-path="assets/enterprise-edition-pill-tag.svg" />

<Note>This is a SpecterOps-managed feature. If it is not enabled in your environment, contact your account team for assistance.</Note>

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](https://hub.docker.com/r/specterops/openhound) and includes the collectors for Github, Jamf, and Okta by default.

<Warning>
  OpenHound currently runs one extension per container. Configure and start a separate OpenHound container for each extension you want to use.
</Warning>

## Deployment process

To deploy OpenHound and run a collector:

<Steps>
  <Step title="Provision the environment">
    Provision a server with container (Docker/Podman) support, a Kubernetes cluster, or cloud-native container service to run OpenHound.

    <Note>
      Ensure that the environment meets the [system requirements](/openhound/enterprise#server%2Fcontainer-requirements).
    </Note>
  </Step>

  <Step title="Upload extension assets">
    Upload [saved queries and Privilege Zone rules](/openhound/upload-extension-assets) for each collector extension you want to run to your BloodHound Enterprise tenant.
  </Step>

  <Step title="Create an OpenHound collector client">
    Create an OpenHound [collector client](/collect-data/enterprise-collection/create-collector) on your BloodHound Enterprise tenant to obtain the necessary API credentials for OpenHound to upload data.
  </Step>

  <Step title="Configure the OpenHound container">
    Configure the OpenHound [runtime](/openhound/configuration#runtime-settings) and [collector-specific](/openhound/configuration#collector-specific-settings) configuration parameters.
  </Step>

  <Step title="Deploy the OpenHound container">
    Use one of the supported methods to deploy the OpenHound container.

    * [Deploy with Docker Compose](/openhound/deploy-with-compose)
    * [Deploy with Kubernetes](/openhound/deploy-with-kubernetes)
  </Step>

  <Step title="Run the collector">
    Run an [On Demand](/collect-data/enterprise-collection/on-demand-scan) scan or create a data collection [schedule](/collect-data/enterprise-collection/collection-schedule) to start the collector and collect data from your environment.
  </Step>
</Steps>

## 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.

<Note>
  For the required BloodHound Enterprise destination parameters, file layout, environment variable names, and common runtime options, see [Configuration](/openhound/configuration).
</Note>

## 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.

<CardGroup cols={3}>
  <Card title="Github" href="/openhound/collectors/github/collect-data#configure-openhound">
    View the required configuration parameters for the Github collector.
  </Card>

  <Card title="Jamf" href="/openhound/collectors/jamf/collect-data#configure-openhound">
    View the required configuration parameters for the Jamf collector.
  </Card>

  <Card title="Okta" href="/openhound/collectors/okta/collect-data#configure-openhound">
    View the required configuration parameters for the Okta collector.
  </Card>
</CardGroup>

## 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.

| Component | Minimum Requirement | Recommended Requirement |
| --------- | ------------------- | ----------------------- |
| CPU       | 2 cores             | 6 cores or more         |
| Memory    | 4 GB                | 8 GB or more            |
| Storage   | 50 GB               | 80 GB or more           |

<Note>
  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.
</Note>
