OpenCTI Platform Docker image is creating unnamed volumes for logs, telemetry, and .support directories

[animedbz16]

Description

I had not realized this until looking at restructuring our deployment, but it appears that the OpenCTI platform is defining docker volumes within its base Dockerfile which when deployed creates random docker volumes names with sha256 hashes.

The issue is that when deploying with docker compose and doing a down / up, these volumes will remain on the system and become detached from the old containers and when the deployment is upped, then new volumes with different random sha256 hashes are created and attached to the new containers.

opencti/opencti-platform/Dockerfile

Line 92 in c1def1b

VOLUME ["/opt/opencti/logs", "/opt/opencti/telemetry", "/opt/opencti/.support"]

Its not clear to me why docker volumes are being leveraged here for this to begin with.

The logs are being piped into stdout so they can be viewed from docker logs, we leverage filebeat to discover any docker containers on systems and stream anything piped out from the stdout from docker into Elasticsearch for retaining these logs.

It doesn't seem to make any sense for the application to capture and retain any of this information inside the container itself for logging.

Telemetry metrics are supposedly disabled by default according to the docs:

• https://github.com/OpenCTI-Platform/docs/blob/bfad20edfff0d21ba1e519af5ccc23cfa9dbd3d1/docs/deployment/configuration.md?plain=1#L90
  but I can see that inside the telemetry directory / volume that it capturing JSON output every day and storing a file there. The telemetry itself would never work since this is hosted on an air gapped network, but still not sure why its attempting to capture this when it should be disable by default and also not sure why it is storing this information inside the container on disk on a volume mount.

Similarly, it appears that the .support directory is capturing errors, which are already being captured in the docker container stdout. It is not clear why this is being stored on disk inside the container on a volume mount.

This problem is compounded when spinning up OpenCTI platform replica servers for scaling up to multiple platform nodes

Environment

1. OS (where OpenCTI server runs): Docker
2. OpenCTI version: 6.3.1
3. OpenCTI client: N/A
4. Other environment details:

Reproducible Steps

Steps to create the smallest reproducible scenario:

1. Start OpenCTI with docker compose up
2. OpenCTI platform creates sha256 named volumes
3. Down docker compose
4. Start OpenCTI with docker compose up
5. OpenCTI platform creates new sha256 named volumes

Expected Output

OpenCTI platform should not be creating docker volumes to store logs within the container on a disk / volume mount

Actual Output

OpenCTI platform is unnecessarily storing logs inside the container on a disk / volume mount. These volumes will persist after using docker compose up / down and every up will create new volumes which ever increases the number of volumes being retained on the server until it is manually cleaned up.

Additional information

This problem is compounded when spinning up OpenCTI platform replica servers for scaling up to multiple platform nodes

Screenshots (optional)