[Feature] Harden rootless Docker Compose more with read-only filesystem, dropped all capabilities and network isolation

[Im-hsh]

The official rootless Compose configuration already runs the Immich containers as 1000:1000, enables no-new-privileges and drops NET_RAW.

I have been running the rootless configuration with additional hardening successfully:

read_only: true for all containers
cap_drop: ALL
Hardened writable /tmp tmpfs where required for read-only operation
Writable PostgreSQL runtime/config paths required for read-only operation
Separate frontend and internal backend networks to isolate Redis, PostgreSQL and machine-learning services from the frontend webui off immich

I've included a sample Compose configuration showing these changes and have been running it successfully for months now.

Would these additional hardening measures be suitable for inclusion in the official rootless Compose example?

services:
  immich-server:
    image: ghcr.io/immich-app/immich-server:v3
    container_name: immich_server
    restart: always
    user: 1000:1000
    # Added: enable read-only filesystem.
    read_only: true
    security_opt:
      - no-new-privileges:true
    # Changed: drop all Linux capabilities instead of only NET_RAW.
    cap_drop:
      - ALL
    # Added: writable /tmp required for read-only filesystem.
    tmpfs:
      - /tmp:rw,noexec,nosuid,nodev
    networks:
    # Added: isolate frontend and backend services on the internal backend network.
      - immich-frontend
      - immich-backend
    #    ports: # caddy reverse proxy to container internal port
    #      - '2283:2283'
    depends_on:
      - redis
      - database
    environment:
      TZ: ${TZ}
    volumes:
      - ${UPLOAD_LOCATION}:/data
      - /etc/localtime:/etc/localtime:ro
    healthcheck:
      disable: false

  immich-machine-learning:
    image: ghcr.io/immich-app/immich-machine-learning:v3
    container_name: immich_machine_learning
    restart: always
    user: 1000:1000
    # Added: enable read-only filesystem.
    read_only: true
    security_opt:
      - no-new-privileges:true
    # Changed: drop all Linux capabilities instead of only NET_RAW.
    cap_drop:
      - ALL
    # Added: writable /tmp required for read-only filesystem.
    tmpfs:
      - /tmp:rw,noexec,nosuid,nodev
    # Added: isolate backend services on the internal backend network.
    networks:
      - immich-backend
    # Added: writable ML paths required for read-only filesystem.
    volumes:
      - ./ml-model-cache:/cache
      - ./ml-config:/.config
      - ./ml-dotcache:/.cache
    healthcheck:
      disable: false

  redis:
    image: docker.io/valkey/valkey:9@sha256:c123e3715db63d06d4ad6964884037aa0d5d4d703939b9929954112889708e1d
    container_name: immich_redis
    restart: always
    user: 1000:1000
    # Added: enable read-only filesystem.
    read_only: true
    security_opt:
      - no-new-privileges:true
    # Changed: drop all Linux capabilities instead of only NET_RAW.
    cap_drop:
      - ALL
    # Added: isolate backend services on the internal backend network.
    networks:
      - immich-backend
    volumes:
      - ./redis:/data
    healthcheck:
      test: redis-cli ping | grep -q PONG || exit 1

  database:
    image: ghcr.io/immich-app/postgres:14-vectorchord0.4.3-pgvectors0.2.0@sha256:bcf63357191b76a916ae5eb93464d65c07511da41e3bf7a8416db519b40b1c23
    container_name: immich_postgres
    restart: always
    user: 1000:1000
    # Added: enable read-only filesystem.
    read_only: true
    security_opt:
      - no-new-privileges:true
    # Changed: drop all Linux capabilities instead of only NET_RAW.
    cap_drop:
      - ALL
    # Added: writable PostgreSQL paths required for read-only filesystem.
    tmpfs:
      - /var/run/postgresql:rw,noexec,nosuid,nodev
      - /etc/postgresql:rw,noexec,nosuid,nodev
    # Added: isolate backend services on the internal backend network.
    networks:
      - immich-backend
    environment:
      POSTGRES_PASSWORD: ${DB_PASSWORD}
      POSTGRES_USER: ${DB_USERNAME}
      POSTGRES_DB: ${DB_DATABASE_NAME}
      POSTGRES_INITDB_ARGS: '--data-checksums'
    volumes:
      - ${DB_DATA_LOCATION}:/var/lib/postgresql/data
    shm_size: 128mb
    healthcheck:
      disable: false

# Added: separate frontend and private backend networks.
networks:
  immich-frontend:
    name: immich-frontend
  immich-backend:
    name: immich-backend
    internal: true

[schildbach]

I have problems with dropping ALL permissions for the postgres and valkey containers. Postgres is the exact same image as yours (by hash).

database-1  | chmod: changing permissions of '/var/lib/postgresql/data': Operation not permitted
database-1  | find: ‘/var/lib/postgresql/data’: Permission denied

I see one difference I'm using the default uid=999 gid=999 rather than your user: 1000:1000 but both should be unprivileged? I'm using Docker version 26.1.5+dfsg1 (Debian trixie). Do have any idea what could be the issue here?

[Im-hsh]

Yes I guess the difference is the UID/GID. Make sure the user running the container owns the bind-mounted directories on the host. because with cap_drop: ALL the container can't rely on capabilities to fix permissions/ownership at startup.

Could you check:

docker compose exec database id

Maybe in your case it will show something like:

uid=999(postgres) gid=999(postgres)

If so, you can check if you make PostgreSQL data directory owned by that UID/GID will fix or not:

sudo chown -R 999:999 /DOCKERDIR/immich/db # which is your ${DB_DATA_LOCATION}

In my setup runs the containers as 1000:1000 with the bind-mounted directories owned by 1000:1000, As before I up the containers I do

sudo chown -R $USER:$USER /MY_DOCKER_DIR/immich/{db,redis,uploads,machine-learning}

and I haven't had this issue.

Let me know if this helps

[schildbach]

My data directory was chowned to 999:999 already. But I now chowned it to 1000:1000 to match your setup and use your user directive, and now it doesn't need any capabilities.

[schildbach]

The redis container had a similar problem for me, as soon as I set user: 1000:1000 it doesn't need caps any more, despite it already using user 1000. Weird.

[schildbach]

Btw. you don't need to prefix your networks with immich-, docker-compose uses a default prefix (name of the directory your compose file is in).

[Im-hsh]

Yeah, I intentionally name my networks explicitly after the service it self not the stack name in every compose file like this.

networks:
  immich-frontend:
    name: immich-frontend
  immich-backend:
    name: immich-backend
    internal: true

I prefer this instead of relying on compose stack directory prefix. It makes things easier for me to inspect and identify when I have a stack runnnig multiple services like my monitoring stack , I dont want networks to inheret the stack name but the service name.

After all its just a personal prefrence and It what I used to do :) but both ways are Ok.