<div dir="ltr">Hi,<div><br></div><div>We definitely need a person who will help with design for the feature.</div><div><br></div><div>Here is the list of open questions:</div><div><br></div><div>1. UI design for certificates uploading</div><div>2. CLI</div><div>3. diagnostic snapshot sanitising</div><div>4. REST API/DB design</div><div>5. background tasks for nailgun (?)</div><div>6. do we need separate container to certificates signing? I don't think that we need if it's</div><div>    not separate service. If it command line tool, it can be installed in nailgun container, in</div><div>    case if we implement background tasks for nailgun, or in mcollective container.</div><div><br></div><div>Thanks,</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 9, 2014 at 2:09 PM, Guillaume Thouvenin <span dir="ltr"><<a href="mailto:thouveng@gmail.com" target="_blank">thouveng@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div><div>I think that the management of certificates should be discussed in the ca-deployment blueprint [3]<br><br></div>We had some discussions and it seems that one idea is to use a docker container as the root authority. By doing this we should be able to sign certificate from Nailgun and distribute the certificate to the corresponding controllers. So one way to see this is:<br><br></div>1) a new environment is created<br></div><div>2) Nailgun generates a key pair that will be used for the new env. <br></div>3) Nailgun sends a CSR that contains the VIP used by the new environment and signed by the newly created private key to the docker "root CA".<br></div>4) the docker "CA" will send back a signed certificate.<br></div>5) Nailgun distribute this signed certificate and the env private key to the corresponding controller through mcollective.<br><br></div><div>It's not clear to me how Nailgun will interact with docker CA and I aslo have some concerns about the storage of different private key of environments but it is the idea...<br></div>If needed I can start to fill the ca-deployment according to this scenario but I guess that we need to approve the BP [3].<br><div><div><div><div><div><div><div><div><br></div><div>So I think that we need to start on [3]. As this is required for OSt public endpoint SSL and also for Fuel SSL it can be quicker to make a first stage where a self-signed certificate is managed from nailgun and a second stage with the docker CA... <br></div><div><br>Best regards,<br>Guillaume<br><br>[3] <a href="https://blueprints.launchpad.net/fuel/+spec/ca-deployment" target="_blank">https://blueprints.launchpad.net/fuel/+spec/ca-deployment</a></div></div></div></div></div></div></div></div></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>