Skip to main content

Overview

Xloud Cloud Platform generates structured audit logs for all API calls, authentication events, and administrative operations. Logs follow the CADF (Cloud Audit Data Federation) standard and can be shipped to external SIEM systems, log aggregation pipelines, or retained locally with configurable retention policies. This page covers audit log configuration, aggregation, and framework-by-framework compliance mapping.
Prerequisites
  • Administrator role in Xloud Identity
  • For log aggregation: XIMP (Infrastructure Monitoring) enabled with the centralized logging add-on
  • For compliance reports: access to the audit log pipeline or SIEM tool receiving Xloud events

Audit Logging

CADF Event Structure

Every platform event produces a CADF-formatted audit record:
Example CADF audit event
{
  "typeURI": "http://schemas.dmtf.org/cloud/audit/1.0/event",
  "id": "evt-a1b2c3d4-...",
  "eventTime": "2025-03-18T09:30:00.000000+00:00",
  "action": "create",
  "outcome": "success",
  "initiator": {
    "typeURI": "service/security/account/user",
    "id": "user-id-...",
    "name": "admin",
    "project_id": "project-id-...",
    "host": {
      "address": "10.0.0.100",
      "agent": "python-keystoneclient"
    }
  },
  "target": {
    "typeURI": "compute/machine",
    "id": "server-id-...",
    "name": "prod-web-01"
  },
  "observer": {
    "typeURI": "service/compute",
    "id": "nova-api-host-01"
  },
  "reason": {
    "reasonCode": "200",
    "reasonType": "HTTP"
  }
}

Enable Audit Middleware

Audit middleware is enabled per service. By default, all Xloud API services have audit middleware active. To verify:
Check audit middleware status
docker exec nova_api grep -i "audit" /etc/nova/nova.conf | grep -v "^#"
To enable or reconfigure audit middleware explicitly:
/etc/xavs/globals.d/_60_audit.yml
nova_audit_events: "all"
keystone_audit_events: "all"
neutron_audit_events: "all"
cinder_audit_events: "all"
glance_audit_events: "all"

Log Aggregation and Retention

Enable central logging

In XDeploy, navigate to Configuration → Global Settings and enable Central Logging. This activates Fluentd on all nodes and deploys OpenSearch as the log aggregation backend.

Configure retention policy

Navigate to XIMP → Log Management → Index Policies. Set the retention period:
Log TypeMinimum RetentionRecommended
Authentication events90 days1 year
API audit events90 days1 year
Service logs30 days90 days
Security events1 year3 years
Some compliance frameworks require specific minimum retention periods. PCI-DSS requires 1 year with 3 months immediately available. HIPAA requires 6 years for audit logs. Configure retention before collecting audit data.

Configure SIEM forwarding

To forward audit events to an external SIEM:Navigate to XIMP → Integrations → Log Forwarding and configure the SIEM endpoint, authentication, and event filter.
Events appear in the SIEM within the configured polling interval (typically 30–60 seconds).

Compliance Framework Mapping

The following table maps Xloud platform controls to requirements in major compliance frameworks.
ControlSOC 2ISO 27001HIPAAPCI-DSSGDPR
TLS for all API endpointsCC6.1A.10.1.1§ 164.312(e)4.1Art. 32
Token-based authenticationCC6.1, CC6.2A.9.4.2§ 164.312(d)8.3Art. 32
RBAC policy enforcementCC6.3A.9.4.1§ 164.312(a)7.1Art. 25
Audit logging (CADF)CC7.2A.12.4.1§ 164.312(b)10.2Art. 30
Log retention ≥ 1 yearCC7.2A.12.4.1§ 164.312(b)10.7Art. 30
Volume encryption (LUKS)CC6.7A.10.1.1§ 164.312(a)(2)(iv)3.4, 3.5Art. 32
Key management (Barbican)CC6.7A.10.1.2§ 164.312(e)(2)3.6Art. 32
Network segmentationCC6.6A.13.1.1§ 164.312(a)1.1Art. 25
Security group enforcementCC6.6A.13.1.3§ 164.312(a)1.2Art. 32
Change trackingCC8.1A.12.1.2§ 164.312(b)6.4.5Art. 30
Vulnerability scanningCC7.1A.12.6.1§ 164.308(a)(8)6.3.3Art. 32

Security Scanning and Vulnerability Management

Schedule regular vulnerability scans

Integrate Xloud with your vulnerability scanning tool (Wazuh, OpenVAS, Qualys, or similar). Scan all compute nodes and control plane hosts at minimum monthly.
Run Lynis system audit
lynis audit system --quick --report-file /var/log/lynis-report-$(date +%Y%m%d).txt

Review and triage findings

Prioritize findings by CVSS score:
SeverityCVSS RangeTarget Remediation
Critical9.0–10.024 hours
High7.0–8.97 days
Medium4.0–6.930 days
Low0.1–3.990 days

Patch and re-scan

Apply patches via the standard XOS update process and re-scan to confirm remediation.
Apply security updates on all nodes
xavs-ansible deploy --tags common --limit control,compute
Re-scan confirms the vulnerability is resolved. Update the compliance tracking document with the remediation date.

Change Tracking

All infrastructure changes made through XDeploy, xavs-ansible, and the Xloud API are recorded with timestamps, user identity, and the before/after state.
View recent deployment history
xavs-ansible facts --list-hosts all
cat /var/log/xavs/ansible.log | grep -E "PLAY|TASK|fatal" | tail -50
For platform API changes, query the audit log:
Filter audit events for a specific user
# Via OpenSearch
curl -sk -u admin:<password> \
  "https://10.0.1.71:9200/audit-*/_search" \
  -d '{"query": {"term": {"initiator.name": "admin"}}, "size": 100}'

Incident Response

Immediate actions:
  1. Revoke the compromised credential or token immediately:
    openstack user password set --password <new-strong-password> <user>
    # Revoke all active tokens for the user:
    openstack token revoke $(openstack token issue -c id -f value)
    
  2. Review audit logs for the compromised account in the 30 days prior to detection.
  3. Identify all resources created or modified with the compromised credential.
  4. Rotate any application credentials created by the affected account.
  5. File an incident report with exact timeline, affected resources, and remediation actions taken.
Investigation steps:
  1. Identify the source IP and token from the audit log.
  2. Check whether the token is still valid:
    openstack token validate <token-id>
    
  3. Revoke the token if it remains active.
  4. Review HAProxy access logs for all requests from the source IP.
  5. Determine whether a firewall block is warranted at the network perimeter.
Immediate actions:
  1. Identify all volumes and objects using the compromised key.
  2. Snapshot all affected volumes immediately.
  3. Create new encrypted volumes with a fresh key, copy data, and delete old volumes.
  4. Delete the compromised key from Xloud Key Management after verifying all data has been migrated.
  5. Document the scope of exposure and notify relevant parties per your incident response policy.

Next Steps

Hardening Guide

Pre-deployment hardening checklist to meet baseline compliance requirements

Infrastructure Security

TLS configuration for SOC 2 and PCI-DSS encryption-in-transit controls

Data Security

Volume and object encryption for data-at-rest compliance requirements

Monitoring (XIMP)

Log aggregation, alerting, and security event dashboards