[Olivier SOTIN (T0t1n)]

Proposed changes

• docker-compose.yml, docker-compose.opensearch.yml: the minio service runs rustfs/rustfs:1.0.4 instead of pgsty/silo:latest. Credentials come from the same .env variables (RUSTFS_ACCESS_KEY: ${MINIO_ROOT_USER}, RUSTFS_SECRET_KEY: ${MINIO_ROOT_PASSWORD}). The server /data command is gone (RustFS serves /data by default). The healthcheck uses the RustFS readiness route /health/ready with curl, since the image has no mc, with a 60 s start period. Logs go to stdout (RUSTFS_OBS_LOG_DIRECTORY empty), otherwise the image writes them to files inside the container. RUSTFS_CHECK_UPDATE=false turns off the update check RustFS runs at startup (a call to version.rustfs.com, also attempted on air-gapped installs).
• docker-compose.dev.yml: same change on opencti-dev-minio, console kept on 9001, and a named volume rustfsdata: the anonymous /data volume of a previous Silo container belongs to root, RustFS restarts in a loop on it.
• README.md: short "Object storage" section with the upgrade warning (the first steps of the guide run with the previous compose file, before a git pull), the dev stack note and the link to the OpenCTI breaking changes page. .env.sample: comment updated.

Unchanged on purpose: service name minio, volume s3data, MINIO_ROOT_* variables, port 9000, MINIO__* variables of the OpenCTI services (the S3__* names only exist from the OpenCTI release of #19371, and the stack runs opencti/platform:latest), XTM One S3_* settings.

The version is pinned (no latest): moving data to RustFS is one way, upgrades go through Renovate.

No automatic migration: on an existing s3data volume, RustFS stops at startup with Permission denied until the volume is backed up and given to uid 10001, as described in the guide. This is on purpose, the stack does not run a one-way data move without a backup.

Related issues

• closes chore(compose): run RustFS as the object storage of the stacks #620
• feat(storage): support RustFS as an Apache-2.0, S3-compatible alternative to MinIO opencti#16749, feat(storage): run RustFS in the dev and CI stacks and rename the minio configuration section to s3 (#16749) opencti#19371 (migration guide)

How to test this PR

Fresh install:

cp .env.sample .env
docker compose up -d --wait minio
docker compose ps minio            # healthy
docker compose logs minio          # JSON logs

Then start the full stack, upload a file on an entity in OpenCTI and attach a file in XTM One.

Upgrade from Silo: follow the migration guide of OpenCTI-Platform/opencti#19371 (docs/docs/deployment/breaking-changes/s3-object-storage-rustfs.md, option 2).

Checked locally: the three service definitions start healthy on an empty volume, bucket creation, write and read work, logs come out on stdout. The guide commands were run end to end on a project using these service definitions with the OpenSearch file name (Silo data, count before and after the move, rollback), and the in-place move was tested on a single node and on a 3 nodes x 2 drives cluster (objects, versions, metadata, users, policies, service accounts kept).

Checklist

• I consider the submitted work as finished
• I tested the code for its functionality
• I added/updated the relevant documentation
• Before merge: merge only once the OpenCTI release containing feat(storage): run RustFS in the dev and CI stacks and rename the minio configuration section to s3 (#16749) opencti#19371 is published and the guide is live on docs.opencti.io/latest (the stack runs latest images, and git pull users get the change at once)
• After merge: XTM-One-Platform/e2e-tests#31 follows (its dependency alignment check flags the storage until then)