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).

barbican is an OpenStack key management service offering secure storage, provisioning, and management of key data. The barbican service provides management of secrets, keys and certificates via multiple storage back-ends. The support for various back ends is provided via a plug-in mechanism, a Key Management Interoperability Protocol (KMIP) plug-in for a KMIP-compliant Hardware Secure Module (HSM) device. barbican supports symmetric and asymmetric key generation using various algorithms. cinder and nova will integrate with barbican for their encryption key generation and storage.

barbican has two types of core feature sets:

The major features of the barbican key management service are:

Warning

Do not delete the certificate container associated with your load balancer listeners before deleting the load balancers themselves. If you delete the certificate first, future operations on your load balancers and failover will stop working.

New installations of SUSE OpenStack Cloud 9:

barbican currently supports databases and KMIP as its secret store back-ends. In OpenStack upstream additional back-ends are available, such as the PKCS11 and dogtag plug-ins, but they are not tested or supported by SUSE OpenStack Cloud.

In SUSE OpenStack Cloud, by default barbican is configured to use a database as a secret (keys) storage back-end. This back-end encrypts barbican-managed keys with a project level key (KEK/Key Encryption Key) before storing it in the database. Project-level keys are encrypted using a master key. As part of the initial barbican configuration, you must generate and configure this master key.

When barbican is used with simple_crypto_plugin as its secret store back-end, its master key needs to be defined before initial deployment. If no key is specified before deployment, the default master key is used—this practice is discouraged.

Note

For a barbican deployment with a database back-end, the master key needs to be generated and configured before barbican is deployed for the first time. Once the master key is set, it must not be modified.

Note

Changing the master key can result in read errors for existing secrets as those secrets are stored in the database and are encrypted using the previous master key. Once a new master key is used, barbican will not be able to read those secrets. Also it will not be able to create new secrets within that project as the project key is encrypted using previous master key.

barbican has a KMIP plug-in to store encryption keys (called secrets in barbican service terminology) in an HSM device using the KMIP protocol. This plug-in has been tested against Micro Focus ESKM with KMIP server. To enable support for it, barbican needs to be configured with the corresponding plug-in connection details, and client certificate information needs to be defined in its configuration. The ESKM KMIP server uses a client certificate to validate a KMIP client connection established by the barbican server. As part of that KMIP configuration, playbooks provide a mechanism to upload your client certs to nodes hosting the barbican API server.

KMIP deployment instructions can be found in Section 13.1, “Configuring KMIP and ESKM”.

Note

Installation and deployment of the Micro Focus ESKM or any other HSM devices and dependent components is beyond the scope of this document. Please refer the relevant documentation for your choice of product. For example, you can get more information on Micro Focus ESKM and related Data Security and Encryption Products at https://software.microfocus.com/en-us/products/eskm-enterprise-secure-key-management/overview.

The barbican service supports auditing and uses Chapter 15, Security Audit Logs to generate auditing data in Cloud Auditing Data Federation (CADF) format. The SUSE OpenStack Cloud input model has a mechanism to enable and disable auditing on a per-service basis. When barbican auditing is enabled, it writes audit messages to an audit log file that is separate from the barbican internal logging. The base location of audit log file is driven by common auditing configuration.

The auditing of barbican events can be enabled and disabled through the barbican reconfigure playbook. As part of the configuration of barbican, its audit messages can be directed to a log or to a messaging queue. By default, messages are written to the barbican log file. Once an architecture-level decision is made with regards to the default consumer of audit events (either logging or messaging), the barbican service can be configured to use it as the default option when auditing is enabled.

Auditing can be disabled or enabled by following these steps on the Cloud Lifecycle Manager node.

When the key management service is installed, some of the keystone-related initial data is bootstrapped as part of its initial deployment. The data added is primarily related to barbican user, roles, service and endpoint definitions, and barbican role assignments.

In a production environment, you can verify your installation of the barbican key management service by running the barbican-status.yml Ansible playbook on the Cloud Lifecycle Manager node.

ansible-playbook -i hosts/verb_hosts barbican-status.yml

In any non-production environment, along with the playbook, you can also verify the service by storing and retrieving the secret from barbican.

Some barbican features and service configurations can be changed. This is done using the Cloud Lifecycle Manager Reconfigure Ansible playbook. For example, the log level can be changed from INFO to DEBUG and vice-versa. If needed, this change can be restricted to a set of nodes via the playbook's host limit option. barbican administration tasks should be performed by an admin user with a token scoped to the default domain via the keystone identity API. These settings are preconfigured in the barbican.osrc file. By default, barbican.osrc is configured with the admin endpoint. If the admin endpoint is not accessible from your network, change OS_AUTH_URL to point to the public endpoint.

The following barbican configuration settings can be changed:

You can also update the following configuration options and enable the following features. For example, you can:

Auditing of barbican key manager events can be disabled or enabled by following steps on the Cloud Lifecycle Manager node.

You can start or stop the barbican service from the Cloud Lifecycle Manager nodes by running the appropriate Ansible playbooks:

To stop the barbican service:

cd ~/scratch/ansible/next/ardana/ansible
ansible-playbook -i hosts/verb_hosts barbican-stop.yml

To start the barbican service:

cd ~/scratch/ansible/next/ardana/ansible
ansible-playbook -i hosts/verb_hosts barbican-start.yml

To change the password for the barbican administrator:

You can check the status of barbican by running the barbican-status.yml Ansible playbook on the Cloud Lifecycle Manager node.

ansible-playbook -i hosts/verb_hosts barbican-status.yml

Note

Make sure you remove/delete ~/openstack/change_credentials/private_data_metadata.yml after successfully changing the password.

All barbican logging is set to INFO by default. To change the level from the Cloud Lifecycle Manager, there are two options available

Commit the change to the local git repository:

cd ~/openstack/ardana/ansible
git add -A
git commit -m "My config"

Run the configuration-processor-run and ready-deployment playbooks, followed by the barbican-reconfigure playbook:

ansible-playbook -i hosts/localhost config-processor-run.yml
ansible-playbook -i hosts/localhost ready-deployment.yml
cd ~/scratch/ansible/next/ardana/ansible
ansible-playbook -i hosts/verb_hosts barbican-reconfigure.yml

Under the default OpenStack user policies, a user can have either member privilege or admin privilege. Admin privilege is assigned by creating a user account with the role of admin. However, the default admin role is too broad and often grants users more privilege than they need, giving them access to additional tasks and resources that they should not have.

Ideally, each user account should only be assigned privileges necessary to perform tasks they are required to perform. According to the widely accepted principle of least privilege, a user who needs to perform administrative tasks should have a user account with the privileges required to perform only those administrative tasks and no others. This prevents the granting of too much privilege while retaining the individual accountability of the user.

Service Administrator Roles is an alternative to the current one-size-fits-all admin role model and can help you institute different privileges for different administrators.

The main components of Service Administrator Roles are:

Service Administrator Roles offer the following features and benefits:

The following are the roles defined in SUSE OpenStack Cloud 9. These roles serve as a way to group common administrative needs at the OpenStack service level. Each role represents administrative privilege into each service. Multiple roles can be assigned to a user. You can assign a Service Admin Role to a user once you have determined that the user is authorized to perform administrative actions and access resources in that service.

Pre-Installed Service Admin Roles

The following service admin roles exist by default:

Here we will create an RBAC policy where a member of the project called 'demo' will share the network with members of project 'demo2'

To create the RBAC policy, run:

ardana > openstack network rbac create  --target-project DEMO2-PROJECT-ID --type network --action access_as_shared demo-net

Here is an example where the DEMO2-PROJECT-ID is 5a582af8b44b422fafcd4545bd2b7eb5

ardana > openstack network rbac create --target-tenant 5a582af8b44b422fafcd4545bd2b7eb5 \
  --type network --action access_as_shared demo-net

To list all the RBAC rules/policies, execute:

ardana > openstack network rbac list
+--------------------------------------+-------------+--------------------------------------+
| ID                                   | Object Type | Object ID                            |
+--------------------------------------+-------------+--------------------------------------+
| 0fdec7f0-9b94-42b4-a4cd-b291d04282c1 | network     | 7cd94877-4276-488d-b682-7328fc85d721 |
+--------------------------------------+-------------+--------------------------------------+

To see the attributes of a specific RBAC policy, run

ardana > openstack network rbac show POLICY-ID

For example:

ardana > openstack network rbac show 0fd89dcb-9809-4a5e-adc1-39dd676cb386

Here is the output:

+---------------+--------------------------------------+
| Field         | Value                                |
+---------------+--------------------------------------+
| action        | access_as_shared                     |
| id            | 0fd89dcb-9809-4a5e-adc1-39dd676cb386 |
| object_id     | c3d55c21-d8c9-4ee5-944b-560b7e0ea33b |
| object_type   | network                              |
| target_tenant | 5a582af8b44b422fafcd4545bd2b7eb5     |
| tenant_id     | 75eb5efae5764682bca2fede6f4d8c6f     |
+---------------+--------------------------------------+

To delete an RBAC policy, run openstack network rbac delete passing the policy id:

ardana > openstack network rbac delete POLICY-ID

For example:

ardana > openstack network rbac delete 0fd89dcb-9809-4a5e-adc1-39dd676cb386

Here is the output:

Deleted rbac_policy: 0fd89dcb-9809-4a5e-adc1-39dd676cb386

Either the administrator or the network owner can make a network shareable by all tenants.

The administrator can make a tenant's network shareable by all tenants. To make the network demo-shareall-net accessible by all tenants in the cloud:

To share a network with all tenants:

Note that the owner of the network and subnet is not the tenant named demo2. Both the network and subnet are owned by tenant demo. Demo2members cannot create subnets of the network. They also cannot modify or delete subnets owned by demo.

As the tenant demo2, you can get a list of neutron networks:

ardana > openstack network list

+--------------------------------------+-----------+--------------------------------------------------+
| id                                   | name      | subnets                                          |
+--------------------------------------+-----------+--------------------------------------------------+
| f60f3896-2854-4f20-b03f-584a0dcce7a6 | ext-net   | 50e39973-b2e3-466b-81c9-31f4d83d990b             |
| c3d55c21-d8c9-4ee5-944b-560b7e0ea33b | demo-net  | d9b765da-45eb-4543-be96-1b69a00a2556 10.0.1.0/24 |
   ...
+--------------------------------------+-----------+--------------------------------------------------+

And get a list of subnets:

ardana > openstack subnet list --network c3d55c21-d8c9-4ee5-944b-560b7e0ea33b

+--------------------------------------+---------+--------------------------------------+---------------+
| ID                                   | Name    | Network                              | Subnet        |
+--------------------------------------+---------+--------------------------------------+---------------+
| a806f28b-ad66-47f1-b280-a1caa9beb832 | ext-net | c3d55c21-d8c9-4ee5-944b-560b7e0ea33b | 10.0.1.0/24   |
+--------------------------------------+---------+--------------------------------------+---------------+

To show details of the subnet:

ardana > openstack subnet show d9b765da-45eb-4543-be96-1b69a00a2556

+-------------------+--------------------------------------------+
| Field             | Value                                      |
+-------------------+--------------------------------------------+
| allocation_pools  | {"start": "10.0.1.2", "end": "10.0.1.254"} |
| cidr              | 10.0.1.0/24                                |
| dns_nameservers   |                                            |
| enable_dhcp       | True                                       |
| gateway_ip        | 10.0.1.1                                   |
| host_routes       |                                            |
| id                | d9b765da-45eb-4543-be96-1b69a00a2556       |
| ip_version        | 4                                          |
| ipv6_address_mode |                                            |
| ipv6_ra_mode      |                                            |
| name              | sb-demo-net                                |
| network_id        | c3d55c21-d8c9-4ee5-944b-560b7e0ea33b       |
| subnetpool_id     |                                            |
| tenant_id         | 75eb5efae5764682bca2fede6f4d8c6f           |
+-------------------+--------------------------------------------+

The owner of the port is demo2. Members of the network owner project (demo) will not see this port.

Running the following command:

ardana > openstack port create c3d55c21-d8c9-4ee5-944b-560b7e0ea33b

Creates a new port:

+-----------------------+-----------------------------------------------------------------------------------------------------+
| Field                 | Value                                                                                               |
+-----------------------+-----------------------------------------------------------------------------------------------------+
| admin_state_up        | True                                                                                                |
| allowed_address_pairs |                                                                                                     |
| binding:vnic_type     | normal                                                                                              |
| device_id             |                                                                                                     |
| device_owner          |                                                                                                     |
| dns_assignment        | {"hostname": "host-10-0-1-10", "ip_address": "10.0.1.10", "fqdn": "host-10-0-1-10.openstacklocal."} |
| dns_name              |                                                                                                     |
| fixed_ips             | {"subnet_id": "d9b765da-45eb-4543-be96-1b69a00a2556", "ip_address": "10.0.1.10"}                    |
| id                    | 03ef2dce-20dc-47e5-9160-942320b4e503                                                                |
| mac_address           | fa:16:3e:27:8d:ca                                                                                   |
| name                  |                                                                                                     |
| network_id            | c3d55c21-d8c9-4ee5-944b-560b7e0ea33b                                                                |
| security_groups       | 275802d0-33cb-4796-9e57-03d8ddd29b94                                                                |
| status                | DOWN                                                                                                |
| tenant_id             | 5a582af8b44b422fafcd4545bd2b7eb5                                                                    |
+-----------------------+-----------------------------------------------------------------------------------------------------+

Here the tenant demo2 boots a VM that uses the demo-net shared network:

ardana > openstack server create --flavor 1 --image $OS_IMAGE --nic net-id=c3d55c21-d8c9-4ee5-944b-560b7e0ea33b demo2-vm-using-demo-net-nic

+--------------------------------------+------------------------------------------------+
| Property                             | Value                                          |
+--------------------------------------+------------------------------------------------+
| OS-EXT-AZ:availability_zone          |                                                |
| OS-EXT-STS:power_state               | 0                                              |
| OS-EXT-STS:task_state                | scheduling                                     |
| OS-EXT-STS:vm_state                  | building                                       |
| OS-SRV-USG:launched_at               | -                                              |
| OS-SRV-USG:terminated_at             | -                                              |
| accessIPv4                           |                                                |
| accessIPv6                           |                                                |
| adminPass                            | sS9uSv9PT79F                                   |
| config_drive                         |                                                |
| created                              | 2016-01-04T19:23:24Z                           |
| flavor                               | m1.tiny (1)                                    |
| hostId                               |                                                |
| id                                   | 3a4dc44a-027b-45e9-acf8-054a7c2dca2a           |
| image                                | cirros-0.3.3-x86_64 (6ae23432-8636-4e...1efc5) |
| key_name                             | -                                              |
| metadata                             | {}                                             |
| name                                 | demo2-vm-using-demo-net-nic                    |
| os-extended-volumes:volumes_attached | []                                             |
| progress                             | 0                                              |
| security_groups                      | default                                        |
| status                               | BUILD                                          |
| tenant_id                            | 5a582af8b44b422fafcd4545bd2b7eb5               |
| updated                              | 2016-01-04T19:23:24Z                           |
| user_id                              | a0e6427b036344fdb47162987cb0cee5               |
+--------------------------------------+------------------------------------------------+

Run openstack server list:

ardana > openstack server list

See the VM running:

+-------------------+-----------------------------+--------+------------+-------------+--------------------+
| ID                | Name                        | Status | Task State | Power State | Networks           |
+-------------------+-----------------------------+--------+------------+-------------+--------------------+
| 3a4dc...a7c2dca2a | demo2-vm-using-demo-net-nic | ACTIVE | -          | Running     | demo-net=10.0.1.11 |
+-------------------+-----------------------------+--------+------------+-------------+--------------------+

Run openstack port list:

ardana > openstask port list --device-id 3a4dc44a-027b-45e9-acf8-054a7c2dca2a

View the subnet:

+---------------------+------+-------------------+-------------------------------------------------------------------+
| id                  | name | mac_address       | fixed_ips                                                         |
+---------------------+------+-------------------+-------------------------------------------------------------------+
| 7d14ef8b-9...80348f |      | fa:16:3e:75:32:8e | {"subnet_id": "d9b765da-45...00a2556", "ip_address": "10.0.1.11"} |
+---------------------+------+-------------------+-------------------------------------------------------------------+

Run openstack port show:

ardana > openstack port show 7d14ef8b-9d48-4310-8c02-00c74d80348f

+-----------------------+-----------------------------------------------------------------------------------------------------+
| Field                 | Value                                                                                               |
+-----------------------+-----------------------------------------------------------------------------------------------------+
| admin_state_up        | True                                                                                                |
| allowed_address_pairs |                                                                                                     |
| binding:vnic_type     | normal                                                                                              |
| device_id             | 3a4dc44a-027b-45e9-acf8-054a7c2dca2a                                                                |
| device_owner          | compute:None                                                                                        |
| dns_assignment        | {"hostname": "host-10-0-1-11", "ip_address": "10.0.1.11", "fqdn": "host-10-0-1-11.openstacklocal."} |
| dns_name              |                                                                                                     |
| extra_dhcp_opts       |                                                                                                     |
| fixed_ips             | {"subnet_id": "d9b765da-45eb-4543-be96-1b69a00a2556", "ip_address": "10.0.1.11"}                    |
| id                    | 7d14ef8b-9d48-4310-8c02-00c74d80348f                                                                |
| mac_address           | fa:16:3e:75:32:8e                                                                                   |
| name                  |                                                                                                     |
| network_id            | c3d55c21-d8c9-4ee5-944b-560b7e0ea33b                                                                |
| security_groups       | 275802d0-33cb-4796-9e57-03d8ddd29b94                                                                |
| status                | ACTIVE                                                                                              |
| tenant_id             | 5a582af8b44b422fafcd4545bd2b7eb5                                                                    |
+-----------------------+-----------------------------------------------------------------------------------------------------+

Note the following limitations of RBAC in neutron.

To configure and enable X.509 SSL authentication and authorization support for the keystone service, perform the following steps.

Because of the experimental nature of the HAProxy feature, it is important to minimize the risk of impacting other services. If you have implemented, or wish to implement the HAProxy feature alongside client SSL certificate login to the horizon dashboard in your cloud, please complete the following steps to make the necessary manual configuration changes.

Note

You must perform the keystone configuration steps in the previous section before performing the following HAProxy configuration changes.

An X.509 client certificate can be issued from any certificate authority (CA). You can use the openssl command-line tool to generate certificate signing requests (CSRs). Once a CA has signed your CSR, the CA will return a signed certificate that you can use to authenticate to horizon.

Read more about openssl here: https://www.openssl.org/

Note

Your cloud's load balancer will reject any self-signed client SSL certificates. Ensure that all client certificates are signed by a certificate authority that your cloud recognizes.

Complete the following steps to configure horizon to support SSL certificate authorization and authentication.

To enable your web browser to present a certificate to the horizon dashboard upon login, you first need to import the certificate. The steps to complete this action will vary from browser to browser. Please refer to your browser's documentation for specific instructions.

For the keystone service to use X.509 certificates to grant users access to horizon, there must be a keystone user account associated with each certificate. keystone associates user accounts with certificates by matching the common name (CN) and organization (O) of a presented certificate with the username and domain of an existing keystone user.

When an X.509 certificate is presented to horizon for authentication/authorization, horizon passes the certificate information along to the keystone service. keystone attempts to match the CN and O of the certificate with the username and domain of an existing local user account. For this operation to be successful, there must be a keystone user account and domain that match the CN and O of the certificate.

For example, if a user named Sam presents a certificate to horizon with the following information,

Then there must be an existing keystone user account with the following values,

Further, Sam's client certificate must have been issued by one of the certificate issuers listed in the any_one_of field in the x509auth_mapping.json file.

Also, when creating a local keystone user, you must assign the user account a project scope. Without a project scope, the authorization portion of the sign-on process will fail.

The following steps illustrate how to use the CLI to create a domain, create and manage a user, and assign a permissions role to the new user.

The SSL authentication and authorization process is detailed in the following steps.

Clean install: all TLS-encrypted services are already listed under tls-components in network_groups.yml

You just have to:

Upgrade: you do not have TLS enabled already on the internal endpoints so you need to

For information on enabling and disabling TLS, see Section 8.2, “TLS Configuration”.

For instructions on installing certificates, see Section 8.2, “TLS Configuration”.

In SUSE OpenStack Cloud 9, you can provide your own certificate authority and certificates for internal and public virtual IP addresses (VIPs), and you should do so for any production cloud. The certificates automatically generated by SUSE OpenStack Cloud are useful for testing and setup, but you should always install your own for production use. For further information, see Book “Deployment Guide using Cloud Lifecycle Manager”, Chapter 41 “Configuring Transport Layer Security (TLS)”

MySQL traffic can be encrypted using TLS. For completely new SUSE OpenStack Cloud deployments using the supplied input model example files, you will have to uncomment the commented entries for tls-component-endpoints:. For upgrades from a previous version, you will have to add the entries to your input model files if you have not already done so. This topic explains how to do both.

8.3.2 MySQL replication over TLS #

  

MySQL replication over TLS is disabled. This is true even if you followed the instruction to turn on Mysql TLS in the previous section. Those steps turn on the service interactions to the database.

Turning on MySQL replication over TLS

Note

Using TLS connections for MySQL replication will incur a performance cost.

You should have already enabled TLS for MySQL client interactions in the previous section. If not, read Section 8.3.1, “Enabling TLS on the database server for client access”.

TLS for MySQL replication is not turned on by default. Therefore, you will need to follow a manual process. Again, the steps are different for new systems and upgrades.

RabbitMQ traffic can be encrypted using TLS. To enable it, you will have to add entries for tls-component-endpoints: in your input model files if you have not already done so. This topic explains how.

$ sudo rabbitmqctl -q list_connections ssl state ssl_protocol user name

Listing connections ...

rmq_barbican_user       false

Other protected data:

However, if a user wants to change the encryption keys then that can be done for all categories of password and secret-keys listed below, and the processes are documented.

The SSH private key passphrase needs to be entered once before any Ansible plays are run against the cloud.

The configuration processor encryption key will be prompted for when the relevant Ansible play is run. Once the configuration processor output has been encrypted, all subsequent Ansible plays need to have --ask-ansible-pass added to the command line to ensure that the encryption key which is needed by Ansible is prompted for.

Finally, if user-supplied passwords have been encrypted (this process uses the OpenSSL library) then the environment variable ARDANA_USER_PASSWORD_ENCRYPT_KEY must contain the key used to encrypt those passwords.

In the case where the ARDANA_USER_PASSWORD_ENCRYPT_KEY environment variable is either null, the empty string, or not defined, then no encryption will be performed on your passwords when using the ardanaencrypt.py script.

The generated passwords are stored in Ansible inputs generated by the configuration processor and also in the persistent state information maintained by the configuration processor.

There are a number of mechanisms that can be used to protect sensitive data such as passwords, some Ansible inputs, and the SSH key used by Ansible on the Cloud Lifecycle Manager. See the installation documents for details. Please remember the need to guard against exposure of your environment variables, which may happen through observation over the shoulder.

There are instructions included in the installation documents that show how to encrypt your data using the ardanaencrypt.py script. You may want to change the encryption keys used to protect your sensitive data in the future and this shows you how:

Once you have enabled encryption in your environment you may have a need to interact with these encrypted files at a later time. This section will show you how.

ardanaencrypt.py script password encryption

If you used the ardanaencrypt.py script to encrypt your IPMI or other passwords and have a need to view them later, you can do so with these steps.

You will want to ensure that the ARDANA_USER_PASSWORD_ENCRYPT_KEY environment variable is set prior to running these commands:

export ARDANA_USER_PASSWORD_ENCRYPT_KEY="<encryption_key>"

To view an encrypted password, you can use this command below which will promot you for the encrypted password value. It will then output the decrypted value:

./ardanaencrypt.py -d

Configuration processor encryption key

If you have used the encryption options available with the configuration processor, which uses Ansible vault, you can do so with these commands. Each of these commands will prompt you for the password you used when setting the encryption initially.

To view an encrypted file in read-only mode, use this command:

ansible-vault view <filename>

To edit an encrypted file, use this command. This allows you to edit a decrypted version of the file without the need to decrypt and re-encrypt it:

ansible-vault edit <filename>

For other available commands, use the help file:

ansible-vault -h

Before deploying the Compute nodes you will need to change the disk configuration to create a new volume-group which will be used for your ephemeral disks. To do this, following these steps:

At this time, AppArmor is not enabled by default in SUSE OpenStack Cloud 9. However, we recommend enabling it for key virtualization processes on compute nodes. For more information, see the https://documentation.suse.com/sles/15-SP1/single-html/SLES-security/#part-apparmor.

The data-at-rest encryption model in SUSE OpenStack Cloud provides support for encrypting cinder volumes (Volume Encryption). These encrypted volumes are protected with an encryption key that can be stored in an HSM appliance.

Assuming barbican and cinder services have been installed, you can configure a cinder volume type for encryption. Doing so will create a new cinder volume type, "LUKS," that can be selected when creating a new volume. Such volumes will be encrypted using a 256bit AES key:

source  ~/service.osrc
openstack role add --user admin --project admin cinder_admin
openstack volume type create LUKS
openstack volume type create \
  --cipher aes-xts-plain64 --key_size 256 --control_location \
  front-end LUKS nova.volume.encryptors.luks.LuksEncryptor

+--------------------------------------+-------------------------------------------+-----------------+----------+------------------+
|            Volume Type ID            |                  Provider                 |      Cipher     | Key Size | Control Location |
+--------------------------------------+-------------------------------------------+-----------------+----------+------------------+
| 99ed804b-7ed9-41a5-9c5e-e2002e9f9bb4 | nova.volume.encryptors.luks.LuksEncryptor | aes-xts-plain64 |   256    |    front-end     |
+--------------------------------------+-------------------------------------------+-----------------+----------+------------------+

You should now be able to create a new volume with the type LUKS, which will request a new key from barbican. Once created, you can attach the new volume to an instance:

 openstack volume create --display-name testVolumeEncrypted --volume-type LUKS --availability-zone nova 1

The volume list (openstack volume show with the volume ID) should now show that you have a new volume and that it is encrypted.

openstack volume show 2ebf610b-98bf-4914-aee1-9b866d7b1897
    +---------------------------------------+--------------------------------------+
    |                Property               |                Value                 |
    +---------------------------------------+--------------------------------------+
    |              attachments              |                  []                  |
    |           availability_zone           |                 nova                 |
    |                bootable               |                false                 |
    |          consistencygroup_id          |                 None                 |
    |               created_at              |      2016-03-04T00:17:45.000000      |
    |              description              |                 None                 |
    |               encrypted               |                 True                 |
    |                   id                  | 2ebf610b-98bf-4914-aee1-9b866d7b1897 |
    |                metadata               |                  {}                  |
    |            migration_status           |                 None                 |
    |              multiattach              |                False                 |
    |                  name                 |         testVolumeEncrypted          |
    |         os-vol-host-attr:host         |  ha-volume-manager@lvm-1#LVM_iSCSI   |
    |     os-vol-mig-status-attr:migstat    |                 None                 |
    |     os-vol-mig-status-attr:name_id    |                 None                 |
    |      os-vol-tenant-attr:tenant_id     |   5f3b093c603f4dc8bc377d04e5385d42   |
    |   os-volume-replication:driver_data   |                 None                 |
    | os-volume-replication:extended_status |                 None                 |
    |           replication_status          |               disabled               |
    |                  size                 |                  1                   |
    |              snapshot_id              |                 None                 |
    |              source_volid             |                 None                 |
    |                 status                |              available               |
    |                user_id                |   3bdde5491e174a8aafcbc5a88e01cac7   |
    |              volume_type              |                 LUKS                 |
    +---------------------------------------+--------------------------------------+

When using an ESKM appliance as the back end, you can also confirm that key operations are going to your HSM via its admin portal.

UUID                                    Owner             Object Type      State       Creation Date
8d54f41d-91dd-4f5e-bcfe-964af8213a8c        barbican     SymmetricKey     PreActive   2016-03-02 13:58:58

For more information on data at rest security with ESKM, see Data Security Protection for SUSE OpenStack Cloud.

Enterprises need the ability to audit and monitor workflows and data in accordance with their strict corporate, industry or governmental policies and compliance requirements such as FIPS-140-2, PCI-DSS, HIPAA, SOX, or ISO. To meet this need, SUSE OpenStack Cloud supports CADF (Cloud Auditing Data Federation)-compliant security audit logs that can easily be integrated with your organization's Security Information and Event Management (SIEM) tools. Such auditing is valuable not only to meet regulatory compliance requirements, but also for correlating threat forensics.

Note that logs from existing OpenStack services can also be used for auditing purposes, even though they are not in a consistent audit friendly CADF format today. All logs can easily be integrated with a SIEM tool such as ArcSight, Splunk etc.

Audit middleware is python middleware logic that addresses the aforementioned logging shortcomings. Audit middleware constructs audit event data in easily consumed CADF format. This data can be mined to answer critical questions about activities over REST resources such as who made the request, when, why, and so forth.

Audit middleware supports delivery of audit data via the Oslo messaging notifier feature. Each service is configured to route data to an audit-specific log file.

The following are key aspects of auditing support in SUSE OpenStack Cloud 9:

In SUSE OpenStack Cloud, all auditing configuration is centrally managed and controlled via input model YAML files on the Cloud Lifecycle Manager node. The settings are configured in the file ~/openstack/my_cloud/definition/cloudConfig.yml in an audit-settings section shown below the following table.

Audit settings in cloudConfig.yml with default set to disabled and services selectively enabled:

product:
    version: 2
    cloud:
    ....
    ....
    # Disc space needs to be allocated to the audit directory before enabling
    # auditing.
    # keystone and nova has auditing enabled
    # cinder, ceilometer, glance, neutron, heat, barbican have auditing disabled
    audit-settings:
    audit-dir: /var/audit
    default: disabled
    enabled-services:
    - keystone
    - nova
    disabled-services:
    - cinder
    - ceilometer

Audit setting in cloudConfig.yml with default set to enabled and services selectively disabled:

product:
    version: 2
    cloud:
    ....
    ....
    # Disc space needs to be allocated to the audit directory before enabling
    # auditing.
    # keystone, nova, glance, neutron, heat, barbican has auditing enabled
    # cinder, ceilometer has auditing disabled
    audit-settings:
    audit-dir: /var/audit
    default: enabled
    enabled-services:
    - keystone
    - nova
    disabled-services:
    - cinder
    - ceilometer

Because auditing is disabled by default, you will need to follow the steps below to enable it:

For instructions on backing up and restoring audit logs, see: Book “Operations Guide CLM”, Chapter 17 “Backup and Restore”, Section 17.3 “Manual Backup and Restore Procedures”, Section 17.3.4 “Audit Log Backup and Restore” .