Add Root CA spec
Change-Id: Ib8d8274ea930c48be1fbb81206461c9ff221affc
This commit is contained in:
Dmitriy Rabotyagov
parent
de94cbb648
commit
8df6a58bd3
|
|
@ -12,6 +12,15 @@ Spec Templates
|
|||
|
||||
specs/templates/*
|
||||
|
||||
Wallaby Specifications
|
||||
---------------------
|
||||
|
||||
.. toctree::
|
||||
:glob:
|
||||
:maxdepth: 1
|
||||
|
||||
specs/wallaby/*
|
||||
|
||||
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