Checks

OpenStack block storage snapshot metadata is evaluated to detect sensitive data such as passwords, API keys, secrets, and private keys. Snapshot metadata is accessible via the OpenStack API to any user with access to the project. Storing secrets in metadata exposes them to unauthorized access through the API.

OpenStack block storage snapshots are evaluated to verify they reference existing volumes. Orphaned snapshots (whose source volumes have been deleted) may contain stale data, incur unnecessary storage costs, and can be overlooked during security reviews. They may also contain sensitive data from deleted volumes that is no longer being managed.

OpenStack block storage volumes are evaluated to verify that at least one backup exists. Volume backups provide disaster recovery capability by storing volume data in a separate storage backend (e.g., Swift or Ceph). Without backups, data loss from volume corruption, accidental deletion, or infrastructure failure is irrecoverable.

OpenStack block storage volumes (Cinder) are evaluated to verify that encryption is enabled. Volume encryption protects data at rest by encrypting the entire volume using a key managed by the OpenStack Key Manager (Barbican). Without encryption, data stored on volumes is vulnerable to unauthorized access if the underlying storage is compromised.

OpenStack block storage volume metadata is evaluated to detect sensitive data such as passwords, API keys, secrets, and private keys. Volume metadata is accessible via the OpenStack API to any user with access to the project. Storing secrets in metadata exposes them to unauthorized access through the API.

OpenStack block storage volumes are evaluated to verify that multi-attach is not enabled. Multi-attach allows a volume to be attached to multiple instances simultaneously, increasing the attack surface and potentially leading to data corruption or unauthorized access from compromised instances.

OpenStack block storage volumes are evaluated to verify they are attached to at least one instance. Unattached volumes may indicate orphaned resources that are no longer in use but continue to incur storage costs and may contain sensitive data without active monitoring or access controls.

OpenStack compute instances (VMs) are evaluated to verify that config drive is enabled. Config drive provides metadata and user data via a virtual CD-ROM device instead of the metadata service (169.254.169.254). This improves security by eliminating network-based metadata access, which can be vulnerable to SSRF attacks and metadata service exploitation.

OpenStack compute instances (VMs) are evaluated to verify network isolation by ensuring they have private IP addresses without mixed public/private exposure. Proper network segmentation requires instances to be deployed in private networks and accessed via controlled entry points (bastion hosts, VPN, load balancers) rather than direct public exposure.

OpenStack compute instances (VMs) are evaluated to verify that SSH key-based authentication is configured by checking for an assigned keypair. Password-based authentication is vulnerable to brute-force attacks, credential stuffing, and phishing. SSH keys provide cryptographic authentication resistant to these attacks.

OpenStack compute instances (VMs) are evaluated to verify that locked status is enabled. Locking an instance prevents unauthorized administrative operations (delete, resize, rebuild, etc.) without first unlocking it. This provides an additional layer of protection against accidental or malicious modifications.

OpenStack compute instance metadata is evaluated to detect sensitive data such as passwords, API keys, secrets, and private keys. Instance metadata is accessible via the metadata service (169.254.169.254) to any process inside the instance. Storing secrets in metadata exposes them to SSRF attacks, compromised applications, and unauthorized access.

OpenStack compute instances are evaluated to verify they are not exposed to the internet via public IPs (floating IPs or access IPs). Instances with public IPs are directly reachable from the internet, increasing attack surface. Best practices recommend using bastion hosts, VPN gateways, or load balancers instead.

OpenStack compute instances (VMs) are evaluated to verify that at least one security group is attached. Security groups act as virtual firewalls, controlling ingress and egress traffic. Instances without security groups may have unrestricted network access, violating defense-in-depth principles.

OpenStack compute instances (VMs) are evaluated to verify that trusted image certificates are configured. Trusted image certificates enable cryptographic validation of image signatures using Glance image signing (OpenStack Image Signature Verification). This ensures instances are launched from verified, untampered images signed by trusted authorities.

OpenStack images are evaluated to verify that the hw_mem_encryption property is set to True. Hardware memory encryption (AMD SEV) protects guest memory from host-level attacks by encrypting it with a per-VM key managed by the CPU. Best practices recommend enabling memory encryption for workloads processing sensitive data in shared infrastructure.

OpenStack images are evaluated to verify that visibility is not set to 'public'. Public images are accessible to all tenants in the cloud, potentially exposing operating system configurations, embedded credentials, proprietary software, and security hardening details. Best practices recommend keeping images private or shared only with specific trusted projects.

OpenStack images are evaluated to verify that shared images do not exceed a configurable member threshold (default: 5 accepted members). Images shared with many projects amplify the blast radius of any vulnerability found in the image, as all consuming projects would be affected. Best practices recommend limiting image sharing to the minimum set of projects required.

OpenStack images are evaluated to verify that the protected flag is set to True. Protected images cannot be deleted, preventing accidental or malicious removal of base images that dependent workloads rely on. Best practices recommend enabling deletion protection on all production images.

OpenStack images are evaluated to verify that the os_secure_boot property is set to 'required'. Secure Boot ensures that only signed and trusted bootloaders and firmware execute during the boot process, protecting against bootkits, rootkits, and firmware-level attacks. Best practices recommend requiring Secure Boot for all production workloads.

OpenStack images are evaluated to verify that all four signature properties are configured: img_signature, img_signature_hash_method, img_signature_key_type, and img_signature_certificate_uuid. Signed images allow Nova to verify integrity before booting, detecting tampering or corruption.

OpenStack networks are evaluated to verify that admin_state_up is True (administratively enabled). Networks with admin_state_up=False cannot carry traffic and are typically disabled temporarily during maintenance or troubleshooting. Best practices recommend re-enabling networks promptly after maintenance to prevent service outages from forgotten disabled networks.

OpenStack networks and ports are evaluated to verify that port security is enabled (port_security_enabled=True). Port security prevents MAC and IP spoofing by enforcing anti-spoofing rules. When disabled, instances can forge source addresses, bypass network isolation, and enable man-in-the-middle attacks. Disabling is sometimes required for NFV/SR-IOV use cases.

OpenStack security groups are evaluated to verify that no rule allows all ingress traffic (any protocol, any port) from the Internet (0.0.0.0/0 or ::/0). A rule with no protocol and no port restriction is effectively a "permit any" firewall rule, completely bypassing network-level access controls. This is the most permissive possible configuration and should never be used in production.