diff --git a/doc/source/index.rst b/doc/source/index.rst index 7a792f2..a1433a9 100644 --- a/doc/source/index.rst +++ b/doc/source/index.rst @@ -12,8 +12,17 @@ Spec Templates specs/templates/* +Wallaby Specifications +---------------------- + +.. toctree:: + :glob: + :maxdepth: 1 + + specs/wallaby/* + Rocky Specifications ---------------------- +-------------------- .. toctree:: :glob: diff --git a/specs/wallaby/ssl-root-ca.rst b/specs/wallaby/ssl-root-ca.rst new file mode 100644 index 0000000..9e7904d --- /dev/null +++ b/specs/wallaby/ssl-root-ca.rst @@ -0,0 +1,217 @@ +SSL Root Certificate Authority +############################## +:date: 2020-10-19 14:00 +:tags: ssl, haproxy, nova, galera, infra + +Blueprint on Launchpad: + * https://blueprints.launchpad.net/openstack-ansible/+spec/ssl-root-ca + +Having SSL encryption is a vital part of every service in the modern world. +OpenStack-Ansible already provides deployers options how to cover public +and internal endpoints with SSL certificates and allows the generation and +use self-signed certificates. However we can make these certificates +"verified" by usage of the root CA, which will be distributed across all +containers and services. This will increase security as users will be +alerted in case of the certificate verification failure, since certificate +verification will be enabled. + +Problem description +=================== + +At the moment several openstack-ansible roles do create self-signed certificates +their own way which does not provide any consistency and is pretty hard to +maintain. Moreover, +these certificates are self-signed ones, which means that certificate +verification has to be disabled for such certificates. So in case of the +certificate "impersonation" you won't be alerted, and encrypted data might +be not secure anymore. +Futhermore, for mysql SSL usage, it is required to place Root CA on +the client containers for mysqlclient to reach the database, while at the moment we +have only server side encryption covered, but Root CA distribution remains the responsibility of the deployer. +Another good example is nova, where in order to disable tunneling for the +live migrations and to use block device migrations, we should be securing the connection with +mutually verifiable certificates. + +To resolve all of the problems above we need: + + * Root CA certificate (and corresponding key which may not be available) + * An intermediate signing certificate and key + +Proposed change +=============== + +In order to resolve issue we need to create a root certificate authority on +the deploy host, which will be used for the futher creation of the +certificates. + +We need this for (but not limited to): + * Creating a self-signed certificate for HAProxy in CI + * Creating ssh signed certs to replace ssh keys in nova and keystone roles + * To use TLS for live migration + * To use TLS for galera and other infrastructure services + * To use TLS for connection between HAProxy and uwsgi + +Implementation +-------------- + +Create role in separate repo which would consist from 2 parts (galera way) which +would be included wherever needed: + + # Create or verify existing provided CA on the deploy host. + Included in openstack_hosts, to distribute CA to certificate storage + # Create or verify existing key and certificate, which would be also stored + on the deploy host. Will be included in required roles during their runtime + Each instance of each component uses a unique certificate. + # Decide what we 'call' the internal VIP if it's needed to verify the dns name + against subject name in an SSL certificate + # Create a signed ssh key which can be validated against the CA certificate + to avoid needing to distribute all keys to all hosts. + +Roles/service impact +==================== + +For all hosts/containers +------------------------ + +The Root CA is installed into the system trust store +Consider pointing REQUESTS_CA_BUNDLE to the system trust store rather than certifi bundle + +For HAproxy +----------- + +We will have the following user scenarios: + * The user supplies their own cert and key and points variables to the files + * Letsencrypt creates the certificate + * A self signed certificate and key is created at deploy time by the OSA role + * Disable SSL certificate usage + +.. note:: + + Self signed cert is required to bootstrap LE for the first run + +For Galera (or other infrastructure service) +-------------------------------------------- + +We will have the following user scenarios: + + * The user supplies their own cert and key and points variables to the files + + * A self signed certificate and key is created on the deploy host at deploy + time by the OSA role (stored in a well known location on the deploy host). + The existing ansible roles pick these up + + * Disable SSL certificate usage + + +For service components such as Nova and Octavia which can use TLS +----------------------------------------------------------------- + +We will have the following user scenarios: + + * The user supplies their own cert and key and points variables to the files + + * A self signed certificate and key is created on the deploy host at deploy + time by the OSA role (stored in a well known location on the deploy host) + The existing ansible roles pick these up + + * Disable SSL certificate usage + +To replace ssh keys +------------------- + + * Signed ssh certificates are created on the deploy host and copied to the + relevant .ssh user directories. The signing CA is installed into the relevant + ssh_config file in /etc/ + * The deployer may already be using signed ssh keys for access to hosts so any + implementation should work alongside existing configuration. It + may be necessary to investigate supporting more than one trusted CA in + the ssh_config file. + + +Upgrade impact +-------------- + +By default self-singed alternatives will be used for all types of services. +In case deployer would like to omit that, he will need to explicitly disable +that behaviour before upgrade. +No other impact for upgrades is planned at the moment. + + +Security impact +--------------- + +Realization of this blueprint should make systems more secure because +of the SSL usage for most of the interactions and enabling SSL verification +even for the self-singed sertificates. + + +Performance impact +------------------ + +This may decrease performance slightly because SSL encryption requires several +extra CPU cycles and TLS handshake to be performed, however this drawdown can +be neglected. + + +End user impact +--------------- + +No end user impact + + +Deployer impact +--------------- + +The deployer will be able to provide: + * Root CA + * An intermediate cert and key + +Also we should leave possible to disable SSL usage for services. + + +Developer impact +---------------- + +This blueprint will ease maintenance of the roles, because all SSL-specific +parts will be moved to the standalone role. So in case of the need to change +specific task it would be done in a single place rather than in each role. + + + +Implementation +============== + +Assignee(s) +----------- + + +Primary assignee: + noonedeadpunk + +Other contributors: + jrosser + + +Work items +---------- + +TBD + + +Testing +======= + +We will enable self-singed certificates usage in CI + + +Documentation impact +==================== + +Documentation of the added options and architecture should be added at the +end of the day, as well as release notes. + + +References +========== + + * Etherpad discussion: https://etherpad.opendev.org/p/osa-certificates-refactor