Add Root CA spec
Change-Id: Ib8d8274ea930c48be1fbb81206461c9ff221affc
This commit is contained in:
parent
de94cbb648
commit
8df6a58bd3
|
@ -12,6 +12,15 @@ Spec Templates
|
||||||
|
|
||||||
specs/templates/*
|
specs/templates/*
|
||||||
|
|
||||||
|
Wallaby Specifications
|
||||||
|
---------------------
|
||||||
|
|
||||||
|
.. toctree::
|
||||||
|
:glob:
|
||||||
|
:maxdepth: 1
|
||||||
|
|
||||||
|
specs/wallaby/*
|
||||||
|
|
||||||
Rocky Specifications
|
Rocky Specifications
|
||||||
---------------------
|
---------------------
|
||||||
|
|
||||||
|
|
|
@ -0,0 +1,203 @@
|
||||||
|
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 provide deployoers options how to cover public
|
||||||
|
and internal endpoints with SSL certificates and allows to generate and
|
||||||
|
use self-signed certificates. However we can make these certificates
|
||||||
|
"verified" by usage of the root CA, which will be distrivuted across all
|
||||||
|
containers and services. This will encrease security as users will be
|
||||||
|
alerted in case of the certificate mismatch, since certificate verification
|
||||||
|
will be enabled.
|
||||||
|
|
||||||
|
Problem description
|
||||||
|
===================
|
||||||
|
|
||||||
|
At the moment bunch of roles do create self-singed certificates their own way
|
||||||
|
which does not provide any consistency and 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 laerted, and ecrypted data might
|
||||||
|
be not secure anymore.
|
||||||
|
Futhermore, for mysql SSL usage, it is required to place Root CA on
|
||||||
|
the containers for mysqlclient to reach DB, while at the moment we
|
||||||
|
have only server side encryption covered, while Root CA distribution lies on
|
||||||
|
the deployer shoulders.
|
||||||
|
Another good example is nova, where in order to disable tunneling for the
|
||||||
|
live migrations and use block migrations, we need to secure connection with
|
||||||
|
"self-signed" 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 existance 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
|
||||||
|
|
||||||
|
|
||||||
|
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/
|
||||||
|
|
||||||
|
|
||||||
|
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
|
Loading…
Reference in New Issue