NetBox automatic Django migrations on service startup – missing permission boundary to restrict who can trigger migrations

Answer

Yes – NetBox can be configured to skip its automatic Django migrations on startup and require a manual, privileged invocation.

Confirmed facts

• NetBox’s Docker entrypoint runs ./manage.py migrate by default.
• Setting the environment variable NETBOX_SKIP_MIGRATIONS=1 (or true) disables this automatic step in NetBox 3.3 and later.
• When the flag is set, migrations must be executed manually via ./manage.py migrate inside the container or from a separate process.

Likely explanation (based on typical deployment patterns)

NetBox does not provide a built‑in approval token or role‑based gate for migrations. To enforce that only authorized operators can trigger the migration step, you must wrap the startup sequence with a check (e.g., for a secret file, environment variable, or external approval signal) before calling manage.py migrate. This wrapper can be a simple shell script that replaces the container’s entrypoint.

Recommended steps for a containerized/orchestrated deployment

1. Disable auto‑migrate: Add NETBOX_SKIP_MIGRATIONS=1 to the container’s environment (e.g., in a Deployment spec or docker run command).
2. Create a privileged migration task: Define a Kubernetes Job (or an initContainer) that runs ./manage.py migrate. This task should use a dedicated ServiceAccount with limited permissions.
3. Restrict migration execution via RBAC:
   • Create a ServiceAccount netbox-migrator.
   • Bind it to a Role (or ClusterRole) that allows execution of the migration Job only.
   • Ensure the main NetBox Deployment runs under a different, less‑privileged ServiceAccount (e.g., netbox-app).
4. Optional approval wrapper: If you need a token‑based gate, replace the container’s entrypoint with a script such as:

   #!/bin/sh
   if [ -f /run/secrets/migration_approved ]; then
       exec ./manage.py migrate
   else
       echo "Migration not approved; exiting."
       exit 1
   fi
   

   Mount the approval token as a secret at /run/secrets/migration_approved and restrict who can create/update that secret.
5. Verify:
   • Check that the NetBox container starts without migration output: docker logs <container> | grep -i migrate should show none.
   • Run the migration Job manually and confirm tables are created: kubectl logs job/netbox-migrate.
   • Restart the NetBox pod; it should start successfully because the schema is up‑to‑date.

Missing diagnostic detail

To confirm that NETBOX_SKIP_MIGRATIONS is available, please specify the NetBox version you are running (e.g., via docker exec <container> python -c "import netbox; print(netbox.__version__)"). If you are on a pre‑3.3 release, the flag will be ignored and a different approach (custom entrypoint or upstream patch) will be required.