feat: hardening of containers #3328
Conversation
Add user 1001:1001 in backend and frontend Modify all docker-compose files to leverage this change and harden the config.
📝 WalkthroughWalkthroughThis pull request implements non-root user support and container security hardening across Docker configurations. Changes include creating a dedicated app user (UID/GID 1001) in Dockerfiles, adding XDG environment variables to multiple services, and introducing security constraints such as read-only filesystems, capability drops, and restricted privilege escalation across docker-compose templates and configuration files. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 6
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
enterprise/config/templates/docker-compose-sqlite-caddy.yml.j2 (1)
50-71:⚠️ Potential issue | 🟠 MajorAlign backend/huey UID for the shared SQLite volume to avoid permission failures.
hueynow runs as1001:1001whilebackendstill runs as root and both share./db. If the backend creates SQLite files as root, huey may fail to read/write them. Consider runningbackendwith the same UID/GID or ensuring./dband its files are owned/writable by1001(e.g., a documentedchown -R 1001:1001 ./dbpre-step or a startup permission fixup).config/templates/docker-compose-sqlite-traefik.yml.j2 (1)
52-73:⚠️ Potential issue | 🟠 MajorPotential SQLite permission conflict with non-root huey.
hueynow runs as1001:1001whilebackendremains root, and both share./db. If SQLite files are created as root,hueycan fail to access them. Please align the backend UID/GID or ensure the DB files are owned/writable by1001before startup.
🤖 Fix all issues with AI agents
In `@config/templates/docker-compose-postgresql-caddy.yml.j2`:
- Around line 100-102: The backend and huey services both mount ./db:/code/db
but run as different users, causing permission errors; make them consistent by
adding user: "1001:1001" to the backend service (so both backend and huey run as
UID/GID 1001) or alternatively ensure ./db is pre-created with ownership
1001:1001 before containers start; also scan the other PostgreSQL templates
(postgresql-bunkerweb, postgresql-traefik) and make the same consistency change
where backend has user but huey lacks it so both services using the shared ./db
volume use the same user.
In `@config/templates/docker-compose-sqlite-bunkerweb.yml.j2`:
- Around line 61-70: The compose fragment mounts ./db (volumes: - ./db:/code/db)
but sets the container user to "1001:1001" only for the Huey service, leading to
permission mismatches when the backend (which runs as root) creates the SQLite
DB; fix by making ownership consistent: either set the backend service's user
key to "1001:1001" as well, or add an init step (init container or entrypoint
script referenced from the backend service) that chowns /code/db to 1001:1001
before the backend starts; alternatively add documentation to ensure ./db is
pre-created with owner 1001:1001 — adjust the compose "user" field and/or add
the init/chown logic so both backend and Huey can read/write the SQLite file.
In `@docker-compose-build.yml`:
- Around line 12-25: The docker-compose bind-mount ./db:/code/db combined with
user: "1001:1001" will cause permission errors unless the host ./db is owned by
UID 1001; either document the required host setup (e.g., instruct to mkdir -p db
&& sudo chown 1001:1001 db) or add an automatic init step that ensures ownership
before the main process runs (for example run a startup/entrypoint action that
checks and chowns /code/db to 1001:1001 or add a lightweight init container to
perform the chown), or switch to a volume driver that handles UID mapping—update
the docker-compose file and README accordingly to include the chosen remediation
and mention the user: "1001:1001" and volumes: ./db:/code/db symbols.
In `@enterprise/config/templates/docker-compose-postgresql-caddy.yml.j2`:
- Around line 97-106: The shared bind-mount ./db:/code/db creates permission
conflicts between services (Backend and huey) running as different users; update
the docker-compose template to avoid using the same host bind for both
services—either convert ./db to a named volume used by both (so Docker manages
ownership) or give each service its own volume mount and/or ensure a consistent
container user (the user: "1001:1001" setting) and an init step that chowns the
volume; locate references to the ./db:/code/db volume in the template and
replace them with a named volume or per-service volumes and add the consistent
ownership/init approach so both Backend and huey can read/write without
permission errors.
In `@enterprise/config/templates/docker-compose-postgresql-traefik.yml.j2`:
- Around line 105-114: Shared volume ./db:/code/db is mounted with user:
"1001:1001" for the huey container but the backend container runs as root,
causing permission mismatches; update the docker-compose template so both
services use the same UID/GID or ensure the volume is owned by 1001:1001 at
startup. Concretely, either set the backend service to run as user 1001 (match
the huey user: "1001:1001") or add an init step in the container entrypoint to
chown /code/db to 1001:1001 before starting the process; ensure the change
references the volumes entry "./db:/code/db" and the user field user:
"1001:1001" so both containers can read/write the shared DB directory.
In `@README.md`:
- Around line 600-601: Update the README note text that currently reads "udpate"
to the correct spelling "update" in the docker-compose template paragraph (the
block starting "[!NOTE] The docker-compose template files..."). Locate the
sentence mentioning "If you use an old docker-compose.yml file, it is
recommended to udpate it." and change "udpate" to "update" so the sentence reads
"...it is recommended to update it."
🧹 Nitpick comments (2)
backend/startup.sh (1)
8-9: Verifyinstallwith process substitution works in the target environment.Using
install -m 600 <(cat /proc/sys/kernel/random/uuid)is an unusual pattern. While it should work in bash, consider:
- The echo on line 9 runs regardless of whether
installsucceeds- Process substitution behavior may vary in restricted environments
A more robust alternative:
♻️ Suggested improvement with error handling
- install -m 600 <(cat /proc/sys/kernel/random/uuid) db/django_secret_key - echo "generating initial Django secret key" + umask 077 && cat /proc/sys/kernel/random/uuid > db/django_secret_key + echo "generated initial Django secret key"This uses
umaskto ensure 600 permissions while being more portable and keeping the original simple approach.config/templates/docker-compose-postgresql-bunkerweb.yml.j2 (1)
37-40: Consider hardening backend here for parity with other compose files.Other compose variants in this PR set
read_only,cap_drop,security_opt,tmpfs, anduserfor backend. If the omission here isn’t intentional, consider aligning this template to avoid a weaker default.
| volumes: | ||
| - ./db:/code/db | ||
| user: "1001:1001" |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# First, let's find and examine the docker-compose files
echo "=== Docker Compose files in the repository ==="
find . -name "*docker-compose*.yml*" -o -name "*docker-compose*.yml.j2" | head -20
# Check the specific file mentioned in the review
echo -e "\n=== Checking the postgresql-caddy template ==="
if [ -f "config/templates/docker-compose-postgresql-caddy.yml.j2" ]; then
echo "File exists. Getting line count..."
wc -l "config/templates/docker-compose-postgresql-caddy.yml.j2"
fiRepository: intuitem/ciso-assistant-community
Length of output: 1270
🏁 Script executed:
#!/bin/bash
# Now let's examine the backend service definition in the docker-compose file
echo "=== Searching for backend service definition ==="
rg -n "backend:" config/templates/docker-compose-postgresql-caddy.yml.j2 -A 30
echo -e "\n=== Searching for huey service definition ==="
rg -n "huey:" config/templates/docker-compose-postgresql-caddy.yml.j2 -A 30Repository: intuitem/ciso-assistant-community
Length of output: 7181
🏁 Script executed:
#!/bin/bash
# Read the complete backend and huey service definitions
echo "=== Backend and Huey service definitions (lines 22-102) ==="
sed -n '22,102p' config/templates/docker-compose-postgresql-caddy.yml.j2Repository: intuitem/ciso-assistant-community
Length of output: 2743
🏁 Script executed:
#!/bin/bash
# Check if this pattern exists in other docker-compose templates
echo "=== Checking other docker-compose templates for similar pattern ==="
for file in config/templates/docker-compose-*.yml.j2 enterprise/config/templates/docker-compose-*.yml.j2; do
if [ -f "$file" ]; then
echo -e "\n--- File: $file ---"
# Check if both backend and huey exist and their user directives
if rg -q "backend:" "$file" && rg -q "huey:" "$file"; then
echo "Found both backend and huey services"
echo "Backend user directive:"
rg -A 35 "^\s+backend:" "$file" | grep -i "user:" || echo " (none found)"
echo "Huey user directive:"
rg -A 35 "^\s+huey:" "$file" | grep -i "user:" || echo " (none found)"
fi
fi
doneRepository: intuitem/ciso-assistant-community
Length of output: 2281
Fix user directive mismatch between backend and huey services on shared volume.
Both backend and huey services mount ./db:/code/db, but currently:
backendruns as root (nouser:directive)hueyruns asuser: "1001:1001"
This creates permission conflicts: files created by backend (e.g., django_secret_key, SQLite database) will be owned by root, causing potential permission denied errors when huey tries to access them. Since huey has a security-hardened configuration with read-only root filesystem, it specifically needs write access to ./db and must be able to read files created by backend.
Recommendation: Add user: "1001:1001" to the backend service to match huey, or ensure the ./db directory is pre-created with appropriate ownership (1001:1001).
Note: This same inconsistency exists across PostgreSQL templates (postgresql-bunkerweb, postgresql-traefik) where backend has the user directive but huey lacks it.
🤖 Prompt for AI Agents
In `@config/templates/docker-compose-postgresql-caddy.yml.j2` around lines 100 -
102, The backend and huey services both mount ./db:/code/db but run as different
users, causing permission errors; make them consistent by adding user:
"1001:1001" to the backend service (so both backend and huey run as UID/GID
1001) or alternatively ensure ./db is pre-created with ownership 1001:1001
before containers start; also scan the other PostgreSQL templates
(postgresql-bunkerweb, postgresql-traefik) and make the same consistency change
where backend has user but huey lacks it so both services using the shared ./db
volume use the same user.
| read_only: true | ||
| cap_drop: | ||
| - ALL | ||
| security_opt: | ||
| - no-new-privileges:true | ||
| tmpfs: | ||
| - /tmp:rw,noexec,nosuid,nodev | ||
| volumes: | ||
| - ./db:/code/db | ||
| user: "1001:1001" |
There was a problem hiding this comment.
Critical permission issue with SQLite database.
With SQLite, this permission mismatch is especially problematic:
- Backend runs as root, creates/migrates the SQLite database in
./db - Huey runs as 1001:1001 and needs read/write access to the same SQLite database
This will likely cause "permission denied" or "database is locked" errors when huey attempts to access the database.
💡 Potential solutions
- Add user directive to backend: Run backend as 1001:1001 as well
- Pre-create with correct permissions: Document that
./dbmust be created with ownership1001:1001before first run - Use init container/script: Add an init step to fix permissions on the db directory
🤖 Prompt for AI Agents
In `@config/templates/docker-compose-sqlite-bunkerweb.yml.j2` around lines 61 -
70, The compose fragment mounts ./db (volumes: - ./db:/code/db) but sets the
container user to "1001:1001" only for the Huey service, leading to permission
mismatches when the backend (which runs as root) creates the SQLite DB; fix by
making ownership consistent: either set the backend service's user key to
"1001:1001" as well, or add an init step (init container or entrypoint script
referenced from the backend service) that chowns /code/db to 1001:1001 before
the backend starts; alternatively add documentation to ensure ./db is
pre-created with owner 1001:1001 — adjust the compose "user" field and/or add
the init/chown logic so both backend and Huey can read/write the SQLite file.
| - HOME=/tmp | ||
| - XDG_CACHE_HOME=/tmp/.cache | ||
| - XDG_CONFIG_HOME=/tmp/.config | ||
| - XDG_DATA_HOME=/tmp/.local/share | ||
| read_only: true | ||
| cap_drop: | ||
| - ALL | ||
| security_opt: | ||
| - no-new-privileges:true | ||
| tmpfs: | ||
| - /tmp:rw,noexec,nosuid,nodev | ||
| volumes: | ||
| - ./db:/code/db | ||
| user: "1001:1001" |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# First, find and read the docker-compose-build.yml file
fd -t f "docker-compose-build.yml" -x cat -n {}Repository: intuitem/ciso-assistant-community
Length of output: 5233
🏁 Script executed:
# Search for any setup documentation or scripts that might handle volume ownership
fd -t f -E node_modules -E ".git" | head -20Repository: intuitem/ciso-assistant-community
Length of output: 1013
🏁 Script executed:
# Look for any initialization or entrypoint scripts
fd -t f \( -name "*.sh" -o -name "entrypoint*" -o -name "init*" \) | head -20Repository: intuitem/ciso-assistant-community
Length of output: 307
🏁 Script executed:
# Search for any documentation files mentioning setup or permissions
fd -t f \( -name "README*" -o -name "SETUP*" -o -name "INSTALL*" -o -name "*.md" \) | head -20Repository: intuitem/ciso-assistant-community
Length of output: 307
🏁 Script executed:
# Search for setup/documentation files
find . -maxdepth 2 -type f \( -name "README*" -o -name "SETUP*" -o -name "*.md" \) | grep -v node_modulesRepository: intuitem/ciso-assistant-community
Length of output: 600
🏁 Script executed:
# Check the update script for volume/permission handling
cat update-ciso-assistant.shRepository: intuitem/ciso-assistant-community
Length of output: 649
🏁 Script executed:
# Search for any chown or permission-related setup in backend Dockerfile
fd "Dockerfile" --type f | head -5 | xargs -I {} sh -c 'echo "=== {} ===" && head -50 {}'Repository: intuitem/ciso-assistant-community
Length of output: 4533
🏁 Script executed:
# Search for any initialization or permission handling in the codebase
rg "chown|chmod|mkdir.*db" --type-list all -i | head -30Repository: intuitem/ciso-assistant-community
Length of output: 466
🏁 Script executed:
# Search for permission/setup documentation in README files
rg "permission|setup|docker|volume|db" README.md -i -A 3 | head -50Repository: intuitem/ciso-assistant-community
Length of output: 1969
🏁 Script executed:
# Check the main README and backend README for setup instructions
cat README.md | head -100Repository: intuitem/ciso-assistant-community
Length of output: 6179
🏁 Script executed:
# Search for any Docker entrypoint or initialization in backend
find backend -name "entrypoint.sh" -o -name "init.sh" -o -name "start.sh" | xargs cat 2>/dev/nullRepository: intuitem/ciso-assistant-community
Length of output: 59
🏁 Script executed:
# Search for any dockerfile or compose documentation
rg "user|permission|volume|1001" docker-compose-build.yml docker-compose-build-enterprise.yml -A 2 -B 2Repository: intuitem/ciso-assistant-community
Length of output: 1338
🏁 Script executed:
# Check if there's any initialization logic in manage.py or settings
rg "mkdir|chown|chmod" backend/ --type py | head -20Repository: intuitem/ciso-assistant-community
Length of output: 59
Document required host directory ownership or add init step to fix permissions.
With user: "1001:1001" and bind mount ./db:/code/db, container operations will fail with permission denied unless the host directory is owned by UID 1001. This affects database migrations and startup. Either:
- Document the required host setup (e.g.,
mkdir -p db && sudo chown 1001:1001 db) - Add an init container or entrypoint step to fix ownership automatically, or
- Use volume drivers that handle ownership transparently.
Currently there is no documented setup step or automatic remediation.
🤖 Prompt for AI Agents
In `@docker-compose-build.yml` around lines 12 - 25, The docker-compose bind-mount
./db:/code/db combined with user: "1001:1001" will cause permission errors
unless the host ./db is owned by UID 1001; either document the required host
setup (e.g., instruct to mkdir -p db && sudo chown 1001:1001 db) or add an
automatic init step that ensures ownership before the main process runs (for
example run a startup/entrypoint action that checks and chowns /code/db to
1001:1001 or add a lightweight init container to perform the chown), or switch
to a volume driver that handles UID mapping—update the docker-compose file and
README accordingly to include the chosen remediation and mention the user:
"1001:1001" and volumes: ./db:/code/db symbols.
| read_only: true | ||
| cap_drop: | ||
| - ALL | ||
| security_opt: | ||
| - no-new-privileges:true | ||
| tmpfs: | ||
| - /tmp:rw,noexec,nosuid,nodev | ||
| volumes: | ||
| - ./db:/code/db | ||
| user: "1001:1001" |
There was a problem hiding this comment.
Same shared volume permission concern.
Backend and huey share ./db:/code/db with different user contexts. See previous comments for detailed analysis and solutions.
🤖 Prompt for AI Agents
In `@enterprise/config/templates/docker-compose-postgresql-caddy.yml.j2` around
lines 97 - 106, The shared bind-mount ./db:/code/db creates permission conflicts
between services (Backend and huey) running as different users; update the
docker-compose template to avoid using the same host bind for both
services—either convert ./db to a named volume used by both (so Docker manages
ownership) or give each service its own volume mount and/or ensure a consistent
container user (the user: "1001:1001" setting) and an init step that chowns the
volume; locate references to the ./db:/code/db volume in the template and
replace them with a named volume or per-service volumes and add the consistent
ownership/init approach so both Backend and huey can read/write without
permission errors.
| read_only: true | ||
| cap_drop: | ||
| - ALL | ||
| security_opt: | ||
| - no-new-privileges:true | ||
| tmpfs: | ||
| - /tmp:rw,noexec,nosuid,nodev | ||
| volumes: | ||
| - ./db:/code/db | ||
| user: "1001:1001" |
There was a problem hiding this comment.
Same shared volume permission concern as the community template.
Backend runs as root while huey runs as 1001:1001, both sharing ./db:/code/db. See the comment on the community template for details and recommendations.
🤖 Prompt for AI Agents
In `@enterprise/config/templates/docker-compose-postgresql-traefik.yml.j2` around
lines 105 - 114, Shared volume ./db:/code/db is mounted with user: "1001:1001"
for the huey container but the backend container runs as root, causing
permission mismatches; update the docker-compose template so both services use
the same UID/GID or ensure the volume is owned by 1001:1001 at startup.
Concretely, either set the backend service to run as user 1001 (match the huey
user: "1001:1001") or add an init step in the container entrypoint to chown
/code/db to 1001:1001 before starting the process; ensure the change references
the volumes entry "./db:/code/db" and the user field user: "1001:1001" so both
containers can read/write the shared DB directory.
| > [!NOTE] | ||
| > The docker-compose template files are now launching the backend, huey and frontend in non-root mode. If you use an old docker-compose.yml file, it is recommended to udpate it. The containers are compatible with both root and non-root modes. |
There was a problem hiding this comment.
Fix typo: “udpate” → “update”.
✏️ Proposed fix
-> The docker-compose template files are now launching the backend, huey and frontend in non-root mode. If you use an old docker-compose.yml file, it is recommended to udpate it. The containers are compatible with both root and non-root modes.
+> The docker-compose template files are now launching the backend, huey and frontend in non-root mode. If you use an old docker-compose.yml file, it is recommended to update it. The containers are compatible with both root and non-root modes.📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| > [!NOTE] | |
| > The docker-compose template files are now launching the backend, huey and frontend in non-root mode. If you use an old docker-compose.yml file, it is recommended to udpate it. The containers are compatible with both root and non-root modes. | |
| > [!NOTE] | |
| > The docker-compose template files are now launching the backend, huey and frontend in non-root mode. If you use an old docker-compose.yml file, it is recommended to update it. The containers are compatible with both root and non-root modes. |
🧰 Tools
🪛 LanguageTool
[grammar] ~601-~601: Ensure spelling is correct
Context: ...-compose.yml file, it is recommended to udpate it. The containers are compatible with ...
(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)
🤖 Prompt for AI Agents
In `@README.md` around lines 600 - 601, Update the README note text that currently
reads "udpate" to the correct spelling "update" in the docker-compose template
paragraph (the block starting "[!NOTE] The docker-compose template files...").
Locate the sentence mentioning "If you use an old docker-compose.yml file, it is
recommended to udpate it." and change "udpate" to "update" so the sentence reads
"...it is recommended to update it."
Add user 1001:1001 in backend and frontend
Modify all docker-compose files to leverage this change and harden the config.
Summary by CodeRabbit
Release Notes
New Features
Improvements
Documentation
✏️ Tip: You can customize this high-level summary in your review settings.