We need to be explicit about how our SSL PKI works. Outlining how we can fit into existing PKI's and how we will auto generate keys for developers. There is also a patch which outlines some of the initial changes in os-cloud-config I4d65cceee9e15ce0ca8ef309127a587135355810. Change-Id: I32473fe797a4c1e28d14c3b82c8892c7c59a4e55
5.4 KiB
SSL PKI
https://blueprints.launchpad.net/tripleo/+spec/tripleo-juno-ssl-pki
Each of our clouds require multiple ssl certificates to operate. We need to support generating these certificates in devtest in a manner which will closely resemble the needs of an actual deployment. We also need to support interfacing with the PKI (Public Key Infrastructure) of existing organizations. This spec outlines the ways we will address these needs.
Problem Description
We have a handful of services which require SSL certificates:
- Keystone
- Public APIs
- Galera replication
- RabbitMQ replication
Developers need to have these certificates generated automatically for them, while organizations will likely want to make use of their existing PKI. We have not made clear at what level we will manage these certificates and/or their CA(s) and at what level the user will be responsible for them. This is further complicated by the Public API's likely having a different CA than the internal-only facing services.
Proposed Change
Each of these services will accept their SSL certificate, key, and CA via environment JSON (heat templates for over/undercloud, config.json for seed).
At the most granular level, a user can specify these values by editing the over/undercloud-env.json or config.json files. If a certificate and key is specified for a service then we will not attempt to automatically generate one for that service. If only a certificate or key is specified it is considered an error.
If no certificate and key is specified for a service, we will attempt to generate a certificate and key, and sign the certificate with a self-signed CA we generate. Both the undercloud and seed will share a self-signed CA in this scenario, and each overcloud will have a separate self-signed CA. We will also add this self-signed CA to the chain of trust for hosts which use services of the cloud being created.
The use of a custom CA for signing the automatically generated certificates will be solved in a future iteration.
Alternatives
None presented thus far.
Security Impact
This change has high security impact as it affects our PKI. We currently do not have any SSL support, and implementing this should therefore improve our security. We should ensure all key files we create in this change have file permissions of 0600 and that the directories they reside in have permissions of 0700.
There are many security implications for SSL key generation (including entropy availability) and we defer to the OpenStack Security Guide[1] for this.
Other End User Impact
Users can interact with this feature by editing the under/overcloud-env.json files and the seed config.json file. Additionally, the current properties which are used for specifying the keystone CA and certificate will be changed to support a more general naming scheme.
Performance Impact
We will be performing key generation which can require a reasonable amount of resources, including entropy sources.
Other Deployer Impact
None
Developer Impact
More SSL keys will be generated for developers. Debugging via monitoring network traffic can also be more difficult once SSL is adopted. Production environments will also require SSL unwrapping to debug network traffic, so this will allow us to closer emulate production (developers can now spot missing SSL wrapping).
Implementation
The code behind generate-keystone-pki in os-cloud-config will be generalized to support creation of a CA and certificates separately, and support creation of multiple certificates using a single CA. A new script will be created named 'generate-ssl-cert' which accepts a heat environment JSON file and a service name. This will add ssl.certificate and ssl.certificate_key properties under the servicename property (an example is below). If no ssl.ca_certificate and ssl.ca_certificate_key properties are defined then this script will perform generation of the self-signed certificate.
Example heat environment output:
{
"ssl": {
"ca_certificate": "<PEM Data>",
"ca_key": "<PEM Data>"
},
"horizon" {
"ssl": {
"ca_certificate": "<PEM Data>",
"ca_certificate_key": "<PEM Data>"
},
...
},
...
}
Assignee(s)
- Primary assignee:
-
greghaynes
Work Items
- Generalize CA/certificate creation in os-cloud-config.
- Add detection logic for certificate key pairs in -env.json files to devtest
- Make devtest scripts call CA/cert creation scripts if no cert is found for a service
Dependencies
The services listed above are not all set up to use SSL certificates yet. This is required before we can add detection logic for user specified certificates for all services.
Testing
Tests for new functionality will be made to os-cloud-config. The default behavior for devtest is designed to closely mimic a production setup, allowing us to best make use of our CI.
Documentation Impact
We will need to document the new interfaces described in 'Other End User Impact'.
References
- Openstack Security Guide: http://docs.openstack.org/security-guide/content/