[RFC] Certificate Authority

[lasley]

Alright now to another thing we're going to need as part of the ELK stack, and really just anything that needs internal authentication/encryption - a Certificate Authority.

This will be a fairly simple template, because it's all just OpenSSL. The more intricate part though, and why I'm raising this RFC, is an interface for our internal usage.

We should also possibly consider the LetsEncrypt logic that is embedded in the Proxy template. LetsEncrypt is a Cert Authority, so we should use whatever interface for this as well when generating the Proxy certs. It also breaks badly on non-public facing instances.

I didn't see any other cert logic, but we should also identify and consider if existing.

I propose the following modules:

• clouder_base_ca - Common functionality, if existing. May not be needed
• clouder_base_ca_server - Provides an abstract CA server interface, providing method layout for the creation and maintenance of the CA
• clouder_base_ca_client - Provides an abstract CA client interface, providing method layout for the generation and maintenance of certs
• clouder_template_ca_server_openssl - OpenSSL adapter/template for the CA server interface
• clouder_ca_client_openssl - OpenSSL adapter for the CA client interface
• clouder_ca_client_letsencrypt - LetsEncrypt adapter for the CA client interface

Interface definitions (WIP):

clouder_base_ca:

• __init__(

clouder_base_ca_server:

• __init__(
• create_root_pair(...) returns (str) Root pair data
• create_from_csr(str:csr, str:key, int:bits=4096, int:days=365) returns (str) Cert data

clouder_base_ca_client:

• __init__(
• install_dependencies(container) returns (bool) Pass/Fail - Installs dependencies required for CA client operation (openssl, LetsEncrypt client, etc). Required because this is not a template, but instead supposed to run on any container. Base class will always install OpenSSL, because it is needed in all instances. Children will install their specific client, if applicable
• create_private_key(int:bits=4096, str:algorithm=clouder_base_ca.RSA, str:passwd=None) returns (str) Key data Will be performed in base class directly, using OpenSSL always
• create_csr(str:country_name, str:state, str:locality, str:org_name, str:org_unit, str:common_name, str:email, str:challenge_pass=None, str:company_name=None) returns (str) CSR data Will be performed in base class directly, using OpenSSL always
• get_certificate(str:csr, str:key) returns (str) Key data from CA Base class will do nothing. Children will get cert using specific logic for backend.

[YannickB]

I agree with the design, but most of the functions shall be in the core module, and letsencrypt in proxy module. We shall not create specific module for this.

[lasley]

Why integrate most into core? We've gotten this far only having it in proxy & there's only a select set of applications that require the CA functionality, particularly in the server sense.

It does make sense to leave LetsEncrypt in proxy though, particularly with the way that the cert setup is intrinsically linked to a proxy server.

[YannickB]

Hum... If I understand your proposal, you'd like to create at least 5modules. I really believe it's too much and will confuse people looking at the module list.

Currently they see only core and then one module template for each application (except for invoicing/asynchronous/website which are pretty self explanatory). This is clear, I'd like to keep it that way.
Maybe we can add one module to manage CA, but not more IMO.

[lasley]

Ok so based on your comments and reflections on what I see already, I'm going to simplify this. The modules were all being proposed to allow an abstract set of adapters to connect to the interface. The interface modules would have been in the "Hidden" category, which hides from Apps views. The adapter ones probably wouldn't even need to be classified as apps either because they were also depends.

Everywhere else here though, there is one open source project being chosen. It doesn't make sense to create this direction right now, given the direction that we're already in.

That said, I will make two modules - both "Hidden":

• clouder_certificate_request - for creating a PK & CSR. Something like this https://hub.docker.com/r/centurylink/openssl/
• clouder_certificate_authority - for creating a cert authority. I think this looks like the best option - https://github.com/cloudflare/cfssl