Tighten the security of your OpenStack Clouds

OpenStack is by its nature a complex project, consisting of many independent sub projects. As OpenStack continues to gain momentum and while it matures, security is top priority for production.

In addition, new features are introduced every six months, carrying brand new vulnerabilities that are as yet undiscovered.Recently identified vulnerabilities in glibc and OpenSSL show that even a single component can render a whole system vulnerable. Taking into consideration the number of standard and new components in OpenStack, the attack surface can be quite extensive if the cloud is not deployed and maintained in the correct manner.

At the same time there are best practices and tools that can make the OpenStack cloud secure and compliant with industry regulations . We will begin by discussing the most common security threats to an OpenStack cloud. Then we will discuss threat mitigation tools and techniques, based on security best practices and recommendations to improve the security of an OpenStack cloud.

Security threats for an OpenStack cloud

To suggest mitigation tools and techniques we need to identify potential security threats and define possible attack vectors. Focusing specifically on software, it is common to define the following classes of security threats:

Spoofing - Pretending to be something or someone other than one's true identity. Tampering - Modifying something on disk, network or in memory. Repudiation - Claiming that someone didnít do something, or was not responsible. Information disclosure - Providing information to someone not authorized to see it. Denial of service - Absorbing resources needed to provide a service. Escalation of privileges - Allowing someone to do something they are not authorized to do.

Threats may come from outside, from a cloud provider or from another tenant, attacking both the cloud tenant and the cloud provider's infrastructure. Here are the most common threats:

External threats - Attacker can use a vulnerability in the user's VM to take a control of it, then move laterally to other VMs in the cloud until the attacker puts their hand on the crown jewels. Threats from a cloud provider - Attacker can use a cloud misconfiguration for escalation of privileges or information disclosure. For example, an attacker can launch a new VM, and attach a volume that was used by a previously running user VM to access sensitive user data. Threats from another tenant - Attacker can, for example, run an escalation of privileges to escape their VM and take a control over the host and/or other tenants. Attacker can also get access to shared resources, such as storage or network resources. Threat mitigation for OpenStack: General recommendations

Here is a recommended checklist to mitigate common security threats:

Spoofing mitigation : Use public keys infrastructure ( PKI ) for authentication. Use SSL/TLS for HTTP session protection, with trusted certificates. Change the vendor's default passwords in the node's installation and for the cloud's users. Use OpenStack Keystone integration with LDAP / Active Directory for secure authentication, password policies and account security policies. Tampering mitigation : Use digital signatures for data integrity. OpenStack Glance supports image signing, but Liberty still uses insecure the hash algorithm . It will be fixed inMitaka. Use mandatory access control (MAC) and role based access control (RBAC) to protect OpenStack services. Repudiation mitigation : Use logging and security audit. Use centralized secure log management, send all of the log events as close to real-time as possible to the secure remote highly available SIEM system. Monitor tenant networks for anomalies. The best practice is to use network-based Intrusion Detection and Prevention Systems (IDS/IPS) for known vulnerabilities and sandboxing systems for zero-day vulnerabilities. Information disclosure mitigation : Use storage encryption ( OpenStack Cinder and libvirt both support volume encryption). Use OpenStack permission, domains, tenants and groups to implement MAC/RBAC for user workloads. Denial of service (DoS) mitigation : Use quotas per domain, project and per user and implement OpenStack high availability best practices . HA architecture assumes redundancy, so you can safely isolate or shut down the affected instance and the remaining instances should be able to function normally. Use OpenStack availability zones for physical isolation or redundancy. HTTP reverse proxies for REST API endpoints and HTTP applications in the DMZ that can be used to isolate OpenStack services from a direct access. Each reverse proxy can be a linux server with a minimal set of packages. Such a proxy can be easily maintained and also can be used as HTTP load balancer, HTTP accelerator (for encrypted connections) and security gateway to efficiently mitigate DoS/DDoS attacks. Escalation of privileges mitigation : Use SELinux/AppArmor to implement MAC/RBAC for hypervisors and OpenStack services. Place OpenStack services into the DMZ, allowing access to API endpoints only. Cloud tenant threat mitigation : Use separated clouds for tenants, if necessary. Use storage encryption per VM or per tenant.