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¶
TLS Support in Kubernetes Client code
Support for generating keys in Magnum
Support creating secure Kubernetes cluster
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
