Rundeck - Hardened Runbook Automation and Job Scheduler

What is Rundeck

Rundeck turns the scripts and procedures your team already runs by hand into jobs anyone authorised can run safely from a browser or an API call. Define a job as a sequence of shell commands, scripts or plugin steps; give it options; schedule it or trigger it on demand; and Rundeck records who ran what, when, against which nodes, and with what output. Access is governed by role-based ACL policies, so you can hand routine operations - restarts, backups, user provisioning, data fixes - to the people who need them without handing out SSH keys. Nodes are defined per project and reached over SSH, which makes Rundeck a practical control plane for a fleet of Linux hosts.

Why self-host Rundeck

Runbook automation sits close to production: it holds node inventories, credentials and the command history of your infrastructure. Self-hosting keeps all of it inside your own subscription and network boundary, which simplifies data-residency and audit obligations and avoids per-seat pricing on an operational tool. The project is Apache-2.0 licensed, so there is no licence key to renew and no vendor to depend on for continued access to your own automation.

What this VM image adds

Security hardening:

• No default credentials - the packaged admin/admin login is removed; a random admin password is generated on first boot and stored only as a digest
• Per-instance encryption keys - the key storage and project configuration converters are re-keyed at first boot, so no two deployments share a secret
• PostgreSQL instead of the embedded database - the packaged default is a file-based test database that upstream does not support for production; this image ships PostgreSQL bound to localhost
• Loopback-only application port - the built-in web server listens on 127.0.0.1 and is reachable only through the TLS perimeter
• TLS in front - nginx terminates HTTPS on 443 with a self-signed certificate and Certbot is preinstalled for a one-command switch to a CA-signed one
• Pre-provisioned API token - a per-instance token for automation, revocable in one line
• CVE scan - every image is scanned for vulnerabilities with Trivy before release
• UFW firewall - only 22 and 443 open; the application and database ports are not exposed
• fail2ban - SSH brute-force protection
• AppArmor - mandatory access control

OS hardening (CIS Level 1):

• CIS Level 1 hardened - CIS Ubuntu 24.04 LTS Level 1 Benchmark via ansible-lockdown
• auditd - system call auditing for critical paths
• SSH hardening - PasswordAuthentication disabled, key-only access
• Kernel hardening - SYN cookies, ASLR, rp_filter, TCP BBR
• /tmp as tmpfs - nosuid, nodev, noexec
• Azure IMDS endpoints - egress rules pre-configured (169.254.169.254, 168.63.129.16)

Compliance artifacts (inside the VM):

• SBOM - CycloneDX 1.6 at /etc/lynxroute/sbom.json
• CIS Conformance Report - OpenSCAP HTML at /etc/lynxroute/cis-report.html
• Tailored CIS profile - /usr/share/doc/lynxroute/CIS_TAILORED_PROFILE.md
• Licence and notice files - /usr/share/doc/lynxroute/LICENSES.txt and NOTICE.txt

Quick Start

1. Deploy the VM (Standard_D2s_v3 or larger - the JVM and the database want 8 GB)
2. SSH: ssh -i key.pem <username>@<PUBLIC_IP> (username set during VM creation, default: azureuser)
3. Read the generated login: sudo cat /root/rundeck-credentials.txt
4. Open https://<PUBLIC_IP>/ and sign in as admin. First boot takes 2-4 minutes; until the service is ready the page shows a loading screen that refreshes itself
5. Create a project, add a job with a command step, and run it - the execution log and history are stored in the bundled database
6. Replace the self-signed certificate before production: sudo certbot --nginx -d yourdomain.com

Restrict inbound 443 to your own address until you have signed in and changed the admin password.