Merge "Add TLS support in Magnum."
This commit is contained in:
Jenkins
Gerrit Code Review
commit
60d065ace2
225
specs/tls-support-magnum.rst
Normal file
225
specs/tls-support-magnum.rst
Normal file
@ -0,0 +1,225 @@
|
||||
=====================
|
||||
TLS support in Magnum
|
||||
=====================
|
||||
|
||||
Launchpad blueprint:
|
||||
|
||||
https://blueprints.launchpad.net/magnum/+spec/secure-kubernetes
|
||||
|
||||
Currently there is no authentication in Magnum to provide access control to
|
||||
limit communication between the Magnum service and the Kubernetes service so
|
||||
that Kubernetes can not be controlled by a third party. This implementation
|
||||
closes this security loophole by using TLS as an access control mechanism.
|
||||
Only the Magnum server will have the key to communicate with any given
|
||||
Kubernetes API service under its control. An additional benefit of this
|
||||
approach is that communication over the network will be encrypted, reducing
|
||||
the chance of eavesdropping on the communication stream.
|
||||
|
||||
Problem Description
|
||||
-------------------
|
||||
|
||||
Magnum currently controls Kubernetes API services using unauthenticated HTTP.
|
||||
If an attacker knows the api_address of a Kubernetes Bay, (s)he can control
|
||||
the cluster without any access control.
|
||||
|
||||
Use Cases
|
||||
---------
|
||||
|
||||
1. Operators expect system level control to be protected by access control that
|
||||
is consistent with industry best practices. Lack of this feature may result in
|
||||
rejection of Magnum as an option for hosting containerized workloads.
|
||||
|
||||
Proposed Changes
|
||||
----------------
|
||||
|
||||
The complete implementation of TLS support in Magnum can be further decomposed
|
||||
into below smaller implementations.
|
||||
|
||||
1. TLS support in Kubernetes Client Code.
|
||||
-----------------------------------------
|
||||
|
||||
The current implementation of Kubernetes Client code doesn't have any
|
||||
authentication. So this implementation will change the client code to
|
||||
provide authentication using TLS.
|
||||
|
||||
Launchpad blueprint:
|
||||
|
||||
https://blueprints.launchpad.net/magnum/+spec/tls-pythonk8sclient
|
||||
|
||||
2. Generating certificates
|
||||
----------------------------
|
||||
|
||||
This task is mainly on how certificates for both client(magnum-conductor)
|
||||
and server(kube-apiserver) will be generated and who will be the certificate
|
||||
authority(CA).
|
||||
|
||||
These files can be generated in two ways:
|
||||
|
||||
2.1. Magnum script
|
||||
-------------------
|
||||
|
||||
This implementation will use standard tool to generate certificates and
|
||||
keys. This script will be registered on Kubernetes master node while creating
|
||||
bay. This script will generate certificates, start the secure kube-apiserver
|
||||
and then register the client certificates at Magnum.
|
||||
|
||||
2.2. Using Barbican
|
||||
-------------------
|
||||
|
||||
Barbican can also be used as a CA using Dogtag. This implementation will use
|
||||
Barbican to generate certificates.
|
||||
|
||||
3. TLS Support in Magnum code
|
||||
------------------------------
|
||||
|
||||
This work mainly involves deploying a secure bay and supporting the use of
|
||||
certificates in Magnum to call Kubernetes API. This implementation can be
|
||||
decomposed into smaller tasks.
|
||||
|
||||
3.1. Create secure bay
|
||||
----------------------
|
||||
|
||||
This implementation will deploy a secure kube-apiserver running on Kubernetes
|
||||
master node. To do so following things needs to be done:
|
||||
|
||||
* Generate certificates
|
||||
* Copy certificates
|
||||
* Start a secure kube-apiserver
|
||||
|
||||
3.1.1. Generate certificates
|
||||
----------------------------
|
||||
|
||||
The certificates will be generated using any of the above implementation in
|
||||
section 2.
|
||||
|
||||
3.1.2. Copy certificates
|
||||
------------------------
|
||||
|
||||
This depends on how cert and key is generated, the implementation will differ
|
||||
with each case.
|
||||
|
||||
3.1.2.1. Using Magnum script
|
||||
----------------------------
|
||||
|
||||
This script will generate both server and client certificates on Kubernetes master
|
||||
node. Hence only client certificates needs to be copied to magnum host node.
|
||||
To copy these files, the script will make a call to magnum-api to store files.
|
||||
|
||||
3.1.2.2. Using Barbican
|
||||
-----------------------
|
||||
|
||||
When using Barbican, the cert and key will be generated and stored in Barbican
|
||||
itself. Either magnum-conductor can fetch the certificates from Barbican and
|
||||
copy on Kubernetes master node or it can be fetched from Kubernetes master node
|
||||
also.
|
||||
|
||||
3.1.3. Start a secure kube-apiserver
|
||||
------------------------------------
|
||||
|
||||
Above generated certificates will be used to start a secure kube-apiserver
|
||||
running on Kubernetes master node.
|
||||
|
||||
Now that we have a secure Kubernetes cluster running, any API call to
|
||||
Kubernetes will be secure.
|
||||
|
||||
|
||||
3.2. Support https
|
||||
------------------
|
||||
|
||||
While running any Kubernetes resource related APIs, magnum-conductor will
|
||||
fetch certificate from magnum database or Barbican and use it to make secure
|
||||
API call.
|
||||
|
||||
4. Barbican support to store certificates securely
|
||||
----------------------------------------------------
|
||||
|
||||
Barbican is a REST API designed for the secure storage, provisioning and
|
||||
management of secrets. The client cert and key must be stored securely. This
|
||||
implementation will support Barbican in Magnum to store the sensitive data.
|
||||
|
||||
Data model impact
|
||||
-----------------
|
||||
|
||||
New table 'cert' will be introduced to store the certificates.
|
||||
|
||||
REST API impact
|
||||
---------------
|
||||
|
||||
New API /certs will be introduced to store the certificates.
|
||||
|
||||
Security impact
|
||||
---------------
|
||||
|
||||
After this support, Magnum will be secure to be used in actual production
|
||||
environment. Now all the communication to Kubernetes master node will be
|
||||
secure.
|
||||
The certificates will be generated by Barbican or standard tool signed by
|
||||
trusted CAs.
|
||||
The certificates will be stored safely in Barbican when the Barbican cert
|
||||
storage option is selected by the administrator.
|
||||
|
||||
Notifications impact
|
||||
--------------------
|
||||
|
||||
None
|
||||
|
||||
Other end user impact
|
||||
---------------------
|
||||
|
||||
None
|
||||
|
||||
Performance impact
|
||||
------------------
|
||||
|
||||
None
|
||||
|
||||
Other deployer impact
|
||||
---------------------
|
||||
|
||||
Deployer will need to install Barbican to store certificates.
|
||||
|
||||
Developer impact
|
||||
----------------
|
||||
|
||||
None
|
||||
|
||||
Implementation
|
||||
--------------
|
||||
|
||||
Assignee(s)
|
||||
-----------
|
||||
|
||||
Primary assignee
|
||||
madhuri(Madhuri Kumari)
|
||||
yuanying(Motohiro Otsuka)
|
||||
|
||||
Work Items
|
||||
----------
|
||||
|
||||
1. TLS Support in Kubernetes Client code
|
||||
2. Support for generating keys in Magnum
|
||||
3. Support creating secure Kubernetes cluster
|
||||
4. Support Barbican in Magnum to store certificates
|
||||
|
||||
Dependencies
|
||||
------------
|
||||
|
||||
Barbican(optional)
|
||||
|
||||
Testing
|
||||
-------
|
||||
|
||||
Each commit will be accompanied with unit tests. There will also be functional
|
||||
test to test both good and bad certificates.
|
||||
|
||||
Documentation Impact
|
||||
--------------------
|
||||
|
||||
Add a document explaining how TLS cert and keys can be generated and guide
|
||||
updated with how to use the secure model of bays.
|
||||
|
||||
|
||||
References
|
||||
----------
|
||||
|
||||
None
|
||||
Loading…
Reference in New Issue
Block a user