1 SUSE® OpenStack Cloud: Security Planning and Features #

SUSE® OpenStack Cloud is a complex system that has many options which affect the security of the system and the workloads running within it. Careful planning is required to ensure the correct options and features are chosen for your particular environment. You should read Security Boundaries and Threats to understand how OpenStack defines security domains. Ensure that the network layout you choose for your deployment provides adequate network separation for your specific requirements. Carefully examine the other chapters in the OpenStack Security Guide for further information. Take advantage of the security features described below in this section.

OpenStack services by design run some commands with root privileges in order to provide functionality. Although services run as a non-root user they can escalate privilege to root to perform certain operations. If a service process is compromised to the extent that an attacker can execute arbitrary code as the service user, then it is likely that the attacker can elevate privilege to root and take over the system on which the service is running. When planning the security controls for an OpenStack deployment, you should consider the services to be running as root when deciding which security controls are appropriate for your environment. Timely installation of security patches is essential. Other controls such as Intrusion Prevention Systems and Web Application Firewalls are recommended.

Enterprises need protection against security breaches, insider threats, and operational issues that increase the risk to sensitive data. SUSE OpenStack Cloud 9 provides capabilities that help you protect your data at rest and in transit, enable centralized key management, and meet compliance requirements.

In SUSE OpenStack Cloud 9, a number of security features are available to strengthen and harden your cloud deployment. Below is an overview of some of the features and brief descriptions. Follow the links to the relevant topics for instructions on setup, configuration, and use of these security features.

The RBAC feature for neutron networks enables better security as administrators can control who has access to specific networks. This is a significant improvement over the all-or-nothing approach to shared networks. This is beneficial from a security standpoint as some projects (or tenants) have stricter security policies. For example, a finance department must run workloads in isolation from other departments, and thus cannot share their neutron network resources. RBAC enables cloud admins to create granular security policies for sharing neutron resources with one or more tenants or projects using the standard CRUD (Create, Read, Update, Delete) model. More information can be found in Chapter 5, Role-Based Access Control in neutron.

Security logging and auditing provides the ability to discover and manage activities related to security in a cloud installation. Logging is a service plug-in for SUSE OpenStack Cloud that captures events for relevant resources such as security groups and firewalls. With this information, an administrator can investigate and take whatever remedial actions are necessary to maintain a secure system. For more information about enabling and managing Network Security Group logging, see Chapter 6, Enabling Network Security Group Logging.

Each OpenStack service account has an optional role available to restrict the OpenStack functions each account can access. This feature enables cloud administrators to apply service-specific role-based, administration-level access to a specific UserID, with the ability to audit administration-level actions. This functionality provides better security by not only providing full visibility into administration-level activities via audit logs, but also by fulfilling compliance requirements. More information can be found in Section 4.1, “Overview”.

You can conveniently change the inter-service passwords used for authenticating communications between services in your SUSE OpenStack Cloud deployment, promoting better compliance with your organization’s security policies. The inter-service passwords that can be changed include (but are not limited to) keystone, MariaDB, RabbitMQ, Cloud Lifecycle Manager, monasca and barbican. Administrators can implement this feature by running the configuration processor to generate new passwords followed by Ansible playbook commands to change the credentials.

With SUSE OpenStack Cloud 9, data transmission between internal API endpoints is encrypted using TLS v 1.2 to protect sensitive data against unauthorized disclosure and modification (spoofing and tampering attacks). Additionally, you can configure TLS using your own certificates, from a Certificate Authority of your choice, providing deployment flexibility. More information can be found in Section 8.2, “TLS Configuration”.

You can encrypt sensitive data-at-rest on per tenant or project basis, while storing and managing keys externally and centrally using Enterprise Secure Key Manager (ESKM). This capability requires the barbican API and OASIS KMIP (Key Management Interoperability Protocol) plug-ins for integration, and supports encryption of cinder block storage with SUSE OpenStack Cloud 9. More information can be found in Chapter 13, Data at Rest Encryption.

Security audit logs for critical services such as keystone, nova, cinder, glance, heat, neutron, and barbican are available in a standard CADF (Cloud Audit Data Federation) format. These logs contain information on events such as unauthorized logins, administration level access, unsuccessful login attempts, and anomalous deletion of VMs that are critical from a security threat monitoring standpoint. Audit logs are useful as a tool for risk mitigation, identifying suspicious or anomalous activity, and for fulfilling compliance requirements. For more information see Chapter 15, Security Audit Logs.

No limits are enforced within the glance service for both v1 and v2/images API POST method for authenticated users, resulting in possible denial of service through database table saturation. Further explanation and instructions for adding a rate-limiter are in Chapter 14, glance-API Rate Limit (CVE-2016-8611).