Docs · Guides
Secure by default
What CloudNx hardens for you out of the box and what you still need to configure. Read once when you create your first account, revisit before going to production.
What we do automatically
- JWT-signed control plane. Every internal service rejects requests without a valid signed JWT — there’s no implicit trust between control-plane services.
- SSH on random high ports. Each customer VM gets a unique high port (30000+) forwarded to its private 22. Eliminates 99% of internet-scan SSH probes.
- Volume encryption at rest. All Proxmox volumes are on LUKS-encrypted pools. The root key is held by the host, not the customer’s VM.
- HTTPS everywhere. All public-facing endpoints are TLS 1.2+. Let’s Encrypt renews 30 days before expiry; if it fails, our oncall pages within an hour.
- Audit logs. Every state-changing API call is recorded with actor, IP, user-agent, request-id, and duration. View at /portal/audit-logs.
- Per-account isolation. Object Storage tenant IDs, KMS keys, observability namespaces — none are cross-account readable. Pen-tested before launch.
- Stateful firewall on every VM. Default: only the assigned SSH port is reachable. You explicitly open everything else.
What you should turn on within an hour of signup
1. Two-factor auth
From /portal/settings → Security → Enable 2FA. TOTP (Google Authenticator / Authy / 1Password). Backup codes printed once — store them somewhere safe.
2. SSH keys, not passwords
Cloud-init injects your public key on first boot. Disable password auth in /etc/ssh/sshd_config on every new VM:
sudo sed -i 's/^#*PasswordAuthentication.*/PasswordAuthentication no/' /etc/ssh/sshd_config
sudo systemctl reload ssh3. IAM sub-users for everything
The root account is for billing and break-glass — never log in as root day-to-day. Create IAM sub-users for each team member and for each long-running automation. Policies in /portal/iam:
# Read-only operator:
cloudnx iam user create alice
cloudnx iam policy attach alice CloudNxReadOnlyAccess
# CI bot (limited to your bucket):
cloudnx iam user create ci-bot
cloudnx iam policy attach ci-bot CloudNxStorageFullAccess4. KMS for secrets at rest
Don’t commit secrets to git or paste them in cloud-init. Store sensitive values in CloudNx KMS and fetch at startup:
cloudnx kms create-key my-app-secrets
echo -n "$DATABASE_PASSWORD" | cloudnx kms encrypt --key my-app-secrets > db-pw.enc
# In your VM's startup:
DATABASE_PASSWORD=$(cloudnx kms decrypt < db-pw.enc)Firewall — restrictive by default
Every instance starts with an implicit allow rule only for its SSH port. Add per-rule allows from /portal/network/firewall or:
# Web server: open 80 / 443 to anyone, SSH only to your office IP.
cloudnx firewall add web-01 tcp 80 --cidr 0.0.0.0/0
cloudnx firewall add web-01 tcp 443 --cidr 0.0.0.0/0
cloudnx firewall add web-01 tcp 22 --cidr 122.176.45.0/24Rules are stateful — outbound responses are auto-allowed. 0.0.0.0/0means “the public internet”; restrict to your own IPs whenever the workload allows.
Compliance checklist for an Indian SaaS
- DPDP Act (India). CloudNx is your data processor; you’re the controller for your end-users’ data. We honour DSAR within 30 days. Customer-data exports available at /portal/audit-logs.
- GST. Add your company GSTIN at /portal/billing; appears on every invoice for input-credit claim.
- SOC 2. Pre-audit. Engineering preconditions (audit logs, KMS, MFA, RBAC) all shipped. Formal Type II audit gated on the 2nd AX41 (multi-AZ requirement).
- ISO 27001. Same timeline as SOC 2.
Anti-patterns we’ve seen
- Pasting access keys into cloud-init user-data. The keys end up in Proxmox metadata + journald + your application logs. Use IAM instance profiles (workload identity at
169.254.169.254) instead. - Wide-open 0.0.0.0/0 on the database port. Restrict to the application VM’s private IP or, better, attach the DB to the same VPC and only allow internal traffic.
- Long-lived root SSH session. Use
sudofrom a regular user account. - Disabling audit logs. You can’t. They’re append-only and required for DPDP compliance.