Overview
This guide provides a structured hardening walkthrough for Xloud Platform nodes. Apply these controls before the first production deployment. The checklist at the end of this page provides a verification reference for compliance audits. Hardening operates at four levels: the host operating system (XOS), the Xloud platform services, supporting infrastructure components (database, message queue), and the metadata service.Xloud-Developed — XAVS ships with automated hardening roles that enforce CIS benchmarks out of the box. Automated controls include SSH hardening and allowlisting, audit logging configuration, Docker security benchmarks, and AppArmor profile enforcement. These roles run during initial deployment and can be re-applied at any time via
xavs-ansible reconfigure --tags hardening.Prerequisites
- XOS installed on all control and compute nodes
- XDeploy access with bootstrap credentials
- SSH access to all cluster nodes
- A change management window — some steps require service restarts
OS Hardening
Configure SSH
Restrict SSH to key-based authentication and disable direct root login on all nodes:
Harden SSH configuration
Verify:
ssh root@<node> is rejected. Key-based login as the xloud user succeeds.Enable automatic security updates
Configure unattended upgrades for security patches:
Configure unattended upgrades
Configure host firewall (ufw)
Restrict inbound traffic to required service ports only:
Configure ufw on control nodes
Configure ufw on compute nodes
Disable unused kernel modules
Remove attack surface by disabling kernel modules that are not required:
Disable unused modules
Configure kernel security parameters
Apply kernel hardening via sysctl
Enable AppArmor enforcement
AppArmor profiles for hypervisor processes ship in enforce mode on XOS. Verify and enable:Switch complain-mode profiles to enforce:
Verify AppArmor status
Enforce all complain-mode profiles
Run
aa-status and confirm no profiles remain in complain mode for hypervisor-related processes.Service Hardening
Minimize running services
Disable services that are not required on each node type:
Disable unused services on control nodes
Disable unused services on compute nodes
Set file permission baselines
Restrict sensitive configuration files
Harden the metadata service
The instance metadata service is accessible at
169.254.169.254 from all VMs. Enable the shared secret to prevent unauthorized cross-tenant metadata access:/etc/xavs/globals.d/_60_metadata.yml
Deploy metadata hardening
Configure audit daemon (auditd)
Install and configure auditd
Database Hardening
Remove anonymous and test accounts
Audit MariaDB accounts
Restrict remote root access
Disable remote root login
Enable binary log encryption
/etc/xavs/globals.d/_60_db_security.yml
Message Queue Hardening
Enable RabbitMQ TLS
/etc/xavs/globals.d/_60_rabbitmq.yml
Remove default guest account
The
guest account in RabbitMQ is restricted to localhost by default in the Xloud deployment. Verify it is not accessible remotely:Verify guest user restrictions
Set queue and message TTLs
Configure message TTLs to prevent message queue buildup from accumulating sensitive data:
RabbitMQ TTL policy
Pre-Deployment Hardening Checklist
Use this checklist to verify hardening is complete before going to production.Next Steps
Infrastructure Security
TLS configuration and certificate management
Compliance
Map hardening controls to SOC 2, ISO 27001, and PCI-DSS requirements
Network Security
Security groups, FWaaS, and network segmentation
Troubleshooting
Diagnose and resolve common security configuration issues