Skip to content

Security

Authentication Model

OpenNebula uses a pluggable authentication driver system configured in /etc/one/oned.conf under the AUTH_MAD section:

Auth Driver Method Use Case
SSH Key SSH key pair challenge Developer/admin access
X.509 Client certificate Enterprise PKI integration
LDAP Bind against LDAP/AD Corporate directory integration
SAML 2.0 Federated identity SSO with identity providers
OpenID Connect OAuth2/OIDC flow Keycloak, Okta, Azure AD
Plain Username/password Basic local auth

Multiple drivers can be chained — a user authenticating via LDAP can also have an SSH key for API access.

graph TB
    subgraph Users
        Admin["Admin\n(Sunstone UI)"]
        Dev["Developer\n(CLI / API)"]
        CI["CI/CD\n(XML-RPC)"]
    end
    subgraph AuthN["Authentication Layer"]
        LDAP["LDAP Driver"]
        SSH["SSH Key Driver"]
        OIDC["OIDC Driver"]
        X509["X.509 Driver"]
    end
    subgraph OpenNebula["OpenNebula Core"]
        ACL["ACL Engine"]
        oned["oned Daemon"]
    end
    Admin --> OIDC
    Admin --> LDAP
    Dev --> SSH
    CI --> X509
    LDAP --> ACL
    SSH --> ACL
    OIDC --> ACL
    X509 --> ACL
    ACL --> oned

Authorization: ACL System

OpenNebula implements a granular ACL (Access Control List) system managed via oneacl CLI or the Sunstone GUI:

ACL Rule Syntax

USER/GROUP  RESOURCES  RIGHTS

Object Types

Object Identifier Examples
VM VM Running instances
Template TEMPLATE VM definitions
Image IMAGE Disk images
Network NET Virtual networks
Host HOST Physical hosts
Cluster CLUSTER Host groups
Datastore DATASTORE Storage backends

Rights Levels

Right Description
USE Read and consume the resource
MANAGE Modify the resource
ADMIN Full administrative control
CREATE Create new resources of this type

VDC (Virtual Data Centers)

VDCs provide tenant-level isolation — each VDC maps to a subset of hosts, networks, and datastores:

  • Resources are exclusively allocated to a VDC
  • Users in one VDC cannot see or access resources in another
  • VDCs can span multiple OpenNebula zones (federation)

Network Security

Security Groups

OpenNebula provides distributed firewall rules applied per NIC:

# Create a security group with HTTP/HTTPS rules
onesecgroup create my-sg <<EOF
RULE = [ PROTOCOL = TCP, RULE_TYPE = INBOUND, RANGE = 80:443 ]
RULE = [ PROTOCOL = TCP, RULE_TYPE = INBOUND, RANGE = 22 ]
RULE = [ PROTOCOL = ICMP, RULE_TYPE = INBOUND ]
EOF

Security groups support 5-tuple filtering: protocol, source/destination IP, source/destination port.

Network Isolation Methods

Method Level Description
VLANs L2 802.1Q tagged isolation
VXLANs L2 overlay Multi-tenant overlay networks
Open vSwitch L2/L3 Programmable flow-based switching
WireGuard L3 Encrypted tunnel between hosts
Security Groups L3/L4 Per-NIC firewall rules

VM Isolation

Hypervisor-Level Isolation

Hypervisor Isolation Mechanism
KVM (default) Hardware virtualization (VT-x/AMD-V), sVirt (SELinux/AppArmor)
LXC Container namespaces, cgroups, AppArmor profiles
Firecracker Minimal microVM with strict JAIL separation
vCenter VMware ESXi isolation, vSphere security policies

Anti-Affinity and Host Pinning

  • Anti-affinity rules: Ensure VMs from the same group run on different physical hosts (fault tolerance and security isolation)
  • Host pinning: Restrict VMs to specific hosts for compliance (dedicated tenancy)
  • Host reserved resources: Reserve CPU/memory for system processes

Encryption

In Transit

  • Sunstone UI: HTTPS with configurable TLS certificates
  • XML-RPC API: SSL/TLS encryption for all API communication
  • Inter-host communication: WireGuard or IPsec tunnels for VXLAN traffic
  • Libvirt: TLS for migration and remote connections

At Rest

  • Disk encryption: LUKS-encrypted datastores for VM images
  • Ceph RBD: Native encryption via Ceph dmcrypt on OSDs
  • QCOW2: Encrypted qcow2 images with passphrases

Sunstone Web UI Security

Sunstone (the web management interface) security configuration:

  • Enable HTTPS via server configuration (/etc/one/sunstone-server.conf)
  • Configure SSL/TLS certificates (Let's Encrypt or corporate CA)
  • Enable SSO integration (OIDC/SAML)
  • Restrict access via network-level firewall rules
  • Session timeout configuration
  • CSRF protection enabled by default

Hardening Checklist

  • Enable LDAP/OIDC authentication — disable plain auth driver in production
  • Configure TLS for Sunstone and XML-RPC API endpoints
  • Implement security groups with default-deny inbound rules
  • Use VDCs for multi-tenant isolation
  • Enable anti-affinity rules for critical VMs
  • Encrypt inter-host VXLAN traffic with WireGuard
  • Restrict oneadmin access to jump hosts only
  • Configure audit logging for all API calls
  • Patch hypervisor hosts regularly (KVM/QEMU updates)
  • Restrict datastore access with ACL rules
  • Use SSH key authentication for host access (disable password auth)
  • Set file permissions on /etc/one/ configs to 0600

Known Pitfalls

Pitfall Risk Mitigation
Default oneadmin unchanged Privilege escalation Restrict to jump hosts, use LDAP for daily operations
Unencrypted VXLAN traffic Network sniffing across hosts Enable WireGuard/IPsec encryption
Broad ACL rules Unauthorized resource access Use least-privilege ACLs per group
No security groups VMs exposed to all network traffic Apply default-deny security groups to all NICs
Unpatched KVM/QEMU Hypervisor escape vulnerabilities Regular host OS and hypervisor updates