Virtual Machine Security

Overview

Xloud enforces virtual machine security at the hypervisor layer — below the guest OS — through a combination of isolation controls, hardware security features, and network policy enforcement. This agentless model means security policies apply regardless of what runs inside the VM, making it suitable for regulated environments, multi-tenant deployments, and zero-trust architectures.

Prerequisites

Xloud Cloud Platform with XAVS or XPCI
Administrator or project-member role in Xloud Identity
For vTPM: XPCI license with Barbican key management enabled
For Secure Boot: UEFI-compatible image with the appropriate properties set

Hypervisor Isolation

Each virtual machine runs in a fully isolated compute process. The hypervisor enforces the following isolation primitives:

Control	Description
Process isolation	Each VM runs as a separate process owned by a dedicated service account
Namespace separation	Virtual network and storage namespaces are per-tenant
seccomp filtering	Restricts system calls available to the hypervisor process
AppArmor confinement	Mandatory access control profile limits hypervisor file and network access
Resource limits	CPU pinning and memory hard limits prevent noisy-neighbor interference

Xloud uses dedicated service users for the compute hypervisor process. These accounts have no login shell and no home directory. The AppArmor profile is enforced in complain mode by default and can be switched to enforce mode via the hardening guide.

Security Groups

Security groups provide stateful L3/L4 firewalling for virtual machine network interfaces. Rules are enforced at the hypervisor’s virtual switch layer — traffic that does not match an allow rule is silently dropped before reaching the VM.

Dashboard
CLI

Open Security Groups

Navigate to Project → Network → Security Groups in the Xloud Dashboard.

Create a new security group

Click Create Security Group. Provide a name (e.g., web-servers) and an optional description.

Add inbound rules

Click Manage Rules on the new group, then Add Rule:

Field	Example Value	Notes
Rule	Custom TCP Rule	Or use presets: SSH, HTTP, HTTPS
Direction	Ingress	Inbound to the VM
Port Range	443	Single port or range (e.g., 8000-8080)
Remote	CIDR	Restrict by IP range
CIDR	10.0.0.0/8	Limit to internal network only

The default security group permits all outbound traffic and blocks all inbound traffic. Always create explicit inbound rules for required ports.

Attach to an instance

Navigate to Project → Compute → Instances, open the instance, and select Edit Security Groups from the Actions menu. Add the new group and remove the default group if not needed.

The security group is listed in the instance details. Test connectivity using nc or curl from an allowed source.

Create security group

openstack security group create web-servers \
  --description "Inbound HTTPS from internal network"

Add inbound HTTPS rule

openstack security group rule create web-servers \
  --protocol tcp \
  --dst-port 443 \
  --remote-ip 10.0.0.0/8 \
  --ingress

Add inbound SSH rule (restricted)

openstack security group rule create web-servers \
  --protocol tcp \
  --dst-port 22 \
  --remote-ip 192.168.100.0/24 \
  --ingress

Attach security group to instance

openstack server add security group my-instance web-servers

vTPM (Virtual Trusted Platform Module)

Enterprise Virtual TPM provides a hardware-backed cryptographic identity to virtual machines. vTPM state is encrypted using a key stored in Xloud Key Management (Barbican) and is portable across live migrations.

Use Cases

Full-disk encryption (BitLocker, LUKS with TPM unsealing)
Measured boot and attestation
Certificate and secret sealing to the platform

Enable vTPM on an Instance

Dashboard
CLI

Create a vTPM-enabled flavor

Navigate to Admin → Compute → Flavors. Create or edit a flavor and set the extra specification:

Key	Value
`hw:tpm_model`	`tpm-crb`
`hw:tpm_version`	`2.0`

Launch instance with vTPM flavor

Launch the instance using the vTPM-enabled flavor. The hypervisor provisions a software TPM process backed by the platform key management service.

Inside the VM, verify TPM presence: ls /dev/tpm0 or tpm2_getcap properties-fixed.

Create vTPM flavor

openstack flavor create --vcpus 4 --ram 8192 --disk 50 secure-vm-medium
openstack flavor set secure-vm-medium \
  --property hw:tpm_model=tpm-crb \
  --property hw:tpm_version=2.0

Launch instance with vTPM

openstack server create \
  --flavor secure-vm-medium \
  --image ubuntu-24.04 \
  --network private-net \
  my-tpm-instance

Verify vTPM inside VM

# Run inside the virtual machine
ls -la /dev/tpm*
tpm2_getcap properties-fixed | grep TPMVendorID

Encrypted Volumes

Block storage volumes can be encrypted using LUKS (Linux Unified Key Setup). Encryption keys are managed by Xloud Key Management and are never stored on the compute node.

Dashboard
CLI

Create an encrypted volume type

Navigate to Admin → Volume → Volume Types. Create a new type (e.g., encrypted-ssd) and configure the encryption provider:

Field	Value
Provider	`nova.volume.encryptors.luks.LuksEncryptor`
Cipher	`aes-xts-plain64`
Key Size	`256`
Control Location	`front-end`

Create an encrypted volume

Navigate to Project → Volumes → Create Volume. Select the encrypted volume type. The system generates and stores the encryption key in Xloud Key Management automatically.

The volume details page shows Encryption as Yes.

Create encrypted volume type

openstack volume type create encrypted-ssd

openstack volume type set encrypted-ssd \
  --encryption-provider nova.volume.encryptors.luks.LuksEncryptor \
  --encryption-cipher aes-xts-plain64 \
  --encryption-key-size 256 \
  --encryption-control-location front-end

Create encrypted volume

openstack volume create \
  --size 100 \
  --type encrypted-ssd \
  my-encrypted-volume

Verify encryption is active

openstack volume show my-encrypted-volume -c encrypted -f value
# Returns: True

Secure Boot (UEFI)

Secure Boot prevents unsigned bootloaders and kernels from loading on virtual machines. It is supported for images that include UEFI firmware.

Enable Secure Boot on an image

openstack image set --property hw_firmware_type=uefi \
  --property hw_machine_type=q35 \
  --property os_secure_boot=required \
  ubuntu-24.04-secure

Verify Secure Boot properties

openstack image show ubuntu-24.04-secure \
  -c properties -f json | python3 -m json.tool

Use os_secure_boot=optional to allow instances to boot with or without Secure Boot. Use required to enforce it — instances will fail to boot if the image does not support UEFI Secure Boot.

Anti-Affinity for Workload Isolation

Server groups with anti-affinity rules ensure that critical workloads are distributed across separate physical hosts, preventing a single hypervisor failure from taking down multiple replicas simultaneously.

Create anti-affinity server group

openstack server group create \
  --policy anti-affinity \
  production-web-tier

Launch instances in the group

openstack server create \
  --flavor m1.large \
  --image ubuntu-24.04 \
  --network private-net \
  --hint group=<server-group-id> \
  web-node-01

Anti-affinity placement may fail if there are insufficient compute hosts. Xloud returns a scheduling error rather than placing instances on the same host when the policy cannot be satisfied.

Live Migration Security

Live migrations transmit VM memory state across the network. Xloud encrypts migration streams using TLS to prevent eavesdropping on in-transit memory contents.

/etc/xavs/globals.d/_60_migration_security.yml

nova_live_migration_tunnelled: "yes"
nova_console_allowed_origins: "https://<dashboard-hostname>"

When nova_live_migration_tunnelled is enabled, migration traffic is routed through the compute service’s encrypted channel rather than directly between hypervisors. This adds a small latency overhead but ensures the migration stream is protected end-to-end.

Next Steps

Network Security

Security groups, FWaaS micro-segmentation, and VLAN/VXLAN isolation

Data Security

Volume encryption, key management, and encrypted backups

Hardening Guide

AppArmor enforcement, SSH hardening, and hypervisor node hardening

Security Groups (Compute)

Detailed security group management for compute instances

Core Services

Other Services

Virtual Machine Security

Overview

Hypervisor Isolation

Security Groups

Open Security Groups

Create a new security group

Add inbound rules

Attach to an instance

vTPM (Virtual Trusted Platform Module)

Use Cases

Enable vTPM on an Instance

Create a vTPM-enabled flavor

Launch instance with vTPM flavor

Encrypted Volumes

Create an encrypted volume type

Create an encrypted volume

Secure Boot (UEFI)

Anti-Affinity for Workload Isolation

Live Migration Security

Next Steps

Network Security

Data Security

Hardening Guide

Security Groups (Compute)

Core Services

Other Services

​Overview

​Hypervisor Isolation

​Security Groups

Open Security Groups

Create a new security group

Add inbound rules

Attach to an instance

​vTPM (Virtual Trusted Platform Module)

​Use Cases

​Enable vTPM on an Instance

Create a vTPM-enabled flavor

Launch instance with vTPM flavor

​Encrypted Volumes

Create an encrypted volume type

Create an encrypted volume

​Secure Boot (UEFI)

​Anti-Affinity for Workload Isolation

​Live Migration Security

​Next Steps

Network Security

Data Security

Hardening Guide

Security Groups (Compute)

Overview

Hypervisor Isolation

Security Groups

vTPM (Virtual Trusted Platform Module)

Use Cases

Enable vTPM on an Instance

Encrypted Volumes

Secure Boot (UEFI)

Anti-Affinity for Workload Isolation

Live Migration Security

Next Steps