Security
iTop holds sensitive operational data — asset inventory, contacts, and workflow that can trigger changes — and authenticates staff. Harden it before exposing it beyond a trusted network.
TLS via a Reverse Proxy
Do not expose the iTop HTTP port directly. Put a reverse proxy in front for TLS termination and access control (Nginx or Apache), and obtain a certificate with Let's Encrypt.
# Nginx reverse proxy for iTop
server {
listen 443 ssl http2;
server_name itop.example.com;
ssl_certificate /etc/letsencrypt/live/itop.example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/itop.example.com/privkey.pem;
ssl_protocols TLSv1.2 TLSv1.3;
client_max_body_size 32m; # allow attachment uploads
location / {
proxy_pass http://127.0.0.1:8080;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto https; # iTop needs this for correct links
}
}
server {
listen 80;
server_name itop.example.com;
return 301 https://$host$request_uri;
}
Then, in config-itop.php (see Configuration):
'app_root_url' => 'https://itop.example.com/',
'secure_connection_required' => true, // reject plain HTTP
Important
Forward X-Forwarded-Proto https from the proxy and set app_root_url to the HTTPS URL. If iTop thinks it's on HTTP it generates insecure links, breaks the portal, and may loop on redirects. client_max_body_size/upload_max_filesize must be large enough for attachments.
Lock Down the Setup Wizard
The installer at /setup/ can rebuild the database and configuration — it must never be reachable by untrusted users:
iTop disables setup after installation; keep it disabled. Re-enable it only briefly for upgrades, from a trusted network, then disable again.
Optionally block
/setup/and/toolkit/at the reverse proxy except from admin source IPs:location ~ ^/(setup|toolkit)/ { allow 10.0.0.0/8; deny all; proxy_pass http://127.0.0.1:8080; }
Authentication and Profiles
- Enforce strong passwords and prefer LDAP/SSO over local accounts where possible (see Integration).
- iTop authorization is profile-based — assign users the minimum profiles for their role (e.g. Portal user, Service Desk Agent, Configuration Manager) rather than Administrator.
- Create dedicated, least-privilege service accounts for the REST API and the cron scheduler — never reuse the admin account for automation.
- Review the Administrator profile membership periodically; it can change the data model and configuration.
Database Hardening
- Give iTop a dedicated database user limited to its own schema — not the MySQL root account. The Deployment Compose file does this with
MARIADB_USER. - Keep the database on the internal Docker network; do not publish port 3306.
- Source DB credentials from secrets/
_FILEvariables, not inline environment values. See PostgreSQL Security for the same principles applied to a database backend, and MySQL.
File Permissions
iTop needs write access only to specific directories; everything else should be read-only to the web-server user:
| Path | Access |
|---|---|
conf/ |
Writable during setup; read-only afterwards is safest (the app reads config-itop.php) |
data/ |
Writable — attachments, backups, temp |
env-production/ |
Writable during setup/compile |
log/ |
Writable |
| everything else | Read-only to www-data |
# Own the tree by the web user, then restrict
docker exec itop-app chown -R www-data:www-data /var/www/html
docker exec itop-app find /var/www/html -type f -exec chmod 640 {} \;
docker exec itop-app find /var/www/html -type d -exec chmod 750 {} \;
Tip
Running the writable directories on separate volumes (as in Deployment) both persists data and makes it easy to keep the rest of the web root immutable — rebuild the image to update code, and the mounted conf/data/env-production carry state forward.
Security Checklist
- [ ] iTop reached only through an HTTPS reverse proxy; app port not public
- [ ]
X-Forwarded-Proto httpsforwarded;app_root_urlset to the HTTPS URL;secure_connection_required = true - [ ]
/setup/and/toolkit/disabled or IP-restricted - [ ] Strong auth (LDAP/SSO where possible); least-privilege profiles; dedicated API/cron accounts
- [ ] Dedicated DB user (not root); port 3306 internal-only; credentials from secrets
- [ ] Web root read-only except
conf/data/env-production/log - [ ] iTop, PHP, and the database kept patched to supported versions