hi, i've implemented some best practices from OWASP Docker Security Best Practices.
i've only tested a little bit, but i didn't have any issues. user&group 1000 is used from upstream node image. maybe we could a dedicated bibliogram user in the Dockerfile.
--- # cant use mem_limit in a 3.x docker-compose file in non swarm mode # see https://github.com/docker/compose/issues/4513 version: '2.4' services: bibliogram: image: cloudrac3r/bibliogram:latest container_name: bibliogram restart: on-failure:5 pids_limit: 50 mem_limit: 256mb memswap_limit: 256mb security_opt: - no-new-privileges cap_drop: - ALL user: '1000:1000' read_only: true tmpfs: - /app/db/:size=10M,uid=1000,gid=1000,mode=1700 volumes: - ./config.js:/app/config.js:ro
i dont know whats get written into the db and if is needs to be persitent.
The DB must persist, and you should not impose a size limit.
I'm excited to see where you take this!
tmpfs:part could can removed. What is cached or persisted in the db? I dont want to gather data what my users a looking up, so i prefer to delete /app/db after container stop. This probably comes the the downside that more pictures need to be re-loaded from instagram.
The important parts i want to suggest are:services: bibliogram: ... restart: on-failure:5 pids_limit: 50 mem_limit: 256mb memswap_limit: 256mb security_opt: - no-new-privileges cap_drop: - ALL user: '1000:1000' read_only: true
Storing data about requested users is required to evade certain blocks by Instagram. Just the data itself is stored, no knowledge of when it was added or who requested it.
read-only mounts the container's root filesystem as read only. So no file manipulation in the container is possible, except in the r/w mounted volumes. The code can't be manipulated during runtime.