Docker Compose Edits for BloodHound CLI

[chrismaddalena]

Description

This PR adds a name label to the containers and uncomments the bloodhound.config.json volume mounting by default. These changes enable some of the functionality built into the upcoming BloodHound CLI.

The most significant change here is using bloodhound.config.json by default. The CLI ensures the file is present, but someone could run into issues if they do not use the CLI. We have been discussing switching the getbhce link to pull down pre-built binaries so new users would download the CLI and run ./bloodhound-cli install to get started. I am unaware of any decision or movement on that. For now, I think this change will need some consideration.

Motivation and Context

The name labels allow human-identifiable names to be displayed alongside container information when BloodHound CLI's running command is used. It also makes it easier for someone to pull logs from a container (e.g., ./bloodhound-cli logs postgres).

How Has This Been Tested?

I have been testing the changes with the main branch and the current version of BloodHound CLI with Stephen Hinck and others. The changes do not impact the containers.

Screenshots (optional):

Example of the name labels in output:

$ ./bloodhound-cli running        
[+] Checking the status of Docker and the Compose plugin...
[+] Collecting list of running BloodHound containers...
[+] Found 3 running BloodHound containers

 Name            Container ID                                                     Image                                  Status               Ports
 ––––––––––––    ––––––––––––                                                     ––––––––––––                           ––––––––––––         ––––––––––––
 bhce_bloodhound d08a11f9cd5ce7a15a21d632601b979e65121bac1dd7055c10a77ac21a8f4fb7 docker.io/specterops/bloodhound:latest Up 5 hours           127.0.0.1:8080:8080 » 8080/tcp
 bhce_neo4j      30f4e3de52b5c719e195bd8ee880a96e927bafe824432be833682570f9f666e5 docker.io/library/neo4j:4.4            Up 5 hours (healthy) 127.0.0.1:7474:7474 » 7474/tcp, 127.0.0.1:7687:7687 » 7687/tcp, 7473/tcp
 bhce_postgres   17b18be3b847f19696d5f6336be738eb781a45b654e10480881b0ad25a1c6304 docker.io/library/postgres:16          Up 5 hours (healthy) 5432/tcp

Types of changes

• Chore (a change that does not modify the application functionality)

Checklist:

• I have met the contributing prerequisites
  • Assigned myself to this PR
  • Added the appropriate labels
  • Associated an issue: Issues and Pull Requests README #672
  • Read the Contributing guide: https://github.com/SpecterOps/BloodHound/wiki/Contributing
• I have ensured that related documentation is up-to-date
  • Open API docs
  • Code comments (GoDocs / JSDocs)
• I have followed proper test practices
  • Added/updated tests to cover my changes
  • All new and existing tests passed

[github-actions]

CLA Assistant Lite bot All contributors have signed the CLA ✍️ ✅

[chrismaddalena]

I have read the CLA Document and I hereby sign the CLA

[elikmiller]

How would users who are not using the CLI be impacted if they did not create a config file for themselves?

Does it make more sense for the CLI to provide its own docker compose file rather than for us to edit the example provided here?

[chrismaddalena]

@elikmiller If a user does not use the CLI and does not have the JSON file, there will be no file for the volume mount. We could have the CLI provide its own YML. If we place the CLI binary in the BloodHound repository, it will always be present for people to use and will be the intended way you install a new server or manage an existing BloodHound instance. I haven't heard if that's the way we want to go with it or make it an optional utility.

[elikmiller]

@chrismaddalena so if I use your example as is without providing my own config file I'll get the following error message.

Error response from daemon: failed to create task for container: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: error mounting "/Projects/bloodhound-enterprise/bhce/bloodhound.config.json" to rootfs at "/bloodhound.config.json": create mountpoint for /bloodhound.config.json mount: cannot create subdirectories in "/var/lib/docker/overlay2/fec00d17ac49965d3b31bdfacd238e578c524444f5b216dbc7faa92d17dfd5ab/merged/bloodhound.config.json": not a directory: unknown: Are you trying to mount a directory onto a file (or vice-versa)? Check if the specified host path exists and is the expected type

For that reason I do not think we can merge this change as it will break the easy install path for users who do not provide their own config file ahead of time.

[StephenHinck]

@elikmiller @chrismaddalena could we create a separate "examples" folder that has the docker-compose.yaml and config json that BHCLI are expecting and BHCLI can pull fresh from that location if they are missing on disk? That gives the existing path for folks who want to deploy separately via Docker, and the new example for using BHCLI.

[elikmiller]

Yes I think having a separate docker compose file that the CLI can use which doesn't impact the current install experience is a nice compromise. Whether that lives here or in the CLI project shouldn't matter.