<div dir="ltr"><div><div>Hello,<br><br></div>Thanks for the detailed email, Stanislaw. Your suggestion of deploying a CA container is really interesting. Especially for OSTF and other testing since the tools only need to know about the "root" CA.<br><br>Lets back up a bit and list the different options for Fuel users:<br></div><div>0/ The user is happy with plain HTTP.<br></div><div>=> Already supported :)<br></div><div class="gmail_extra">1/ The user wants HTTPS but doesn't want the burden associated with certificate management.<br></div><div class="gmail_extra"></div><div class="gmail_extra">=> Fuel creates and manages the SSL certificates, be them self-signed or signed by some internal CA.<br>=> Using an internal CA instead of multiple self-signed certificates is cleaner as you explained.<br>2/ The user wants HTTPS and wants to use certificates which are generated by an external source (either some internal corporate PKI or some public certificate authority)<br></div><div class="gmail_extra">=> Fuel supports certificate + key uploads<br></div><div class="gmail_extra">=> It should be possible to tell Fuel which entity (Fuel, OSt environment) uses which certificate<br>3/ The user wants HTTPS and agrees to let Fuel generating certificates on behalf of some corporate PKI.<br><div class="gmail_extra">=> Fuel supports CA + key uploads<br></div><br></div><div class="gmail_extra">I think that option 1 is the way to go for a first approach. Option 2 is definitely something that end-users would need at some point. I'm less convinced by option 3: if I were a PKI admin, I'll be reluctant to let Fuel generate certificates on its own. Also my gut feeling tells me that implementing 1 & 2 is already quite a lot of work.<br><br></div><div class="gmail_extra">I've also added some questions/comments inline.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">BR,<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Simon<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 9, 2014 at 5:53 PM, Stanislaw Bogatkin <span dir="ltr"><<a href="mailto:sbogatkin@mirantis.com" target="_blank">sbogatkin@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div>I think that if we have 3 blueprints that realises some SSL stuff around themselves then we can discuss it here.<br></div><div>My vision about SSL in Fuel split into 3 parts:<br></div><div><br></div><div>A) We need to implement [1] blueprint, cause it is only one way to generate certificates.<br></div><div>How i see that:<br></div><div> 1.0 We sync puppet-openssl from upstream, adapt it for Fuel tasks.<br></div><div> 1.1 We create docker container (we already have many, so containerized CA should work well) with OpenSSL and puppet manifests in it.<br></div><div> 1.2 When container will start first time, it will create CA that will store on master node.<br><br></div><div>Our workitems here is:<br></div><div>- Create docker container<br></div><div>- Sync upstream puppet-openssl and adapt it for Fuel<br></div><div>- Write code to create CA<br></div></div></div></blockquote><div><br>First of all I think this blueprint should be submitted to fuel-specs ;)<br>How do you see the exchanges between the CA container and the various services? For instance, how would nailgun asks for a signed certificate and get back the result?<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div></div><div><br></div><div>B) We need to implement [2] blueprint. How I see that: <br></div><div> 1.3 When CA container start first time and creates CA, then it will check for keypair for master node (Fuel UI). If that keypair will not found, then CA create it, change nginx conffile properly and restart nginx on master node.<br><br></div></div></div></blockquote><div><br></div><div>I find awkward to have the CA container restarting nginx...<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div></div><div>Our workitems here is:<br></div><div>- Write code to check if we already have generated certificate and generate new if we have not.<br></div><div><br></div><div>C) Then we need to implement [3] blueprint<br></div><div>For next step we have 2 options:<br></div><div> First:<br></div><div> 1.3 When we create new cluster then we know all information to create new keypair(s). When user press "Deploy changes" button, then we will create new keypair(s).<br>Q: Main question here is - how many keypairs we will create? One for every service or one for all?<br></div></div></div></blockquote><div><br></div><div>As a first implementation, I assume that one certificate for all OSt services is good enough.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div> 1.4 We will distribute key(s) with mcollective agent (similar to how we sync puppet manifests from master node to other nodes). After that private key(s) will deleted from master node.<br></div></div></div></blockquote><div><br></div><div>How will it work if the user modifies the configuration of the environment afterwards? Say he/she adds one controller node, how will it be able to copy the private key to the new node?<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div> 1.5 On nodes puppet will do all work. We need to write some code for that<br></div><div>Pros of that method:<br></div><div> + It's relative simple, we can create clean and lucid code that will be easy for support<br></div><div>Cons of that method:<br></div><div> - We need to send every private key over network. We can reduce this danger cause we will already have passwordless sync over network between master node and other nodes, cause we will generate ssh keys for nodes before we will distribute any data at deployment stage.<br></div><div><br></div><div> Second:<br></div><div> 1.3 When we create new cluster, we do all work same way as we do it now, but after provisioning we will create keypair on first node, make csr for every service (or for one, if we will create one certificate for all services) and send that csr to master node, where it will signed and certificate will send back.<br></div><div> 1.4 Puppet will do all work on nodes. We, obviously, need to write some code for it. But we need to sync our keys over controllers all the same (and now we don't have reliable mechanism to do this)<br></div><div>Pros of that method:<br></div><div> + I don't see any<br></div><div>Cons of that method:<br></div><div> - Code will be not so obvious<br></div><div> - To generate cert we need to rely to other service (network) and if network will unreachable then csr signing will fail and all following deployment will fail because we will not have valid certificate<br><br></div><div>Independing of choice (first or second), our workitems here is:<br></div><div>- Write code to provide functions about generating keypairs, csr's and signing them.<br><br></div><div> 1.5. When we have created CA and certs for services, we can do usual puppet apply to deploy changes.<br><br></div><div>Workitems on that stage:<br></div><div>- Sync upstream modules that already have big changes to SSL support (e.g. HAProxy) and adapt that modules to Fuel usage<br></div><div>- Rewrite some of manifests to support https support<br><br></div><div>As I see, at that phase we can say that Stage I for blueprint [3] is ready.<br></div><div>What we can do next? My thoughts is that:<br><br></div><div>2. We need to think about use case when user want to import his own certificate to Fuel or Openstack services endpoints (cause in that case users will not see warning popup in browser about not trusted certificate or cause corporate policy say to do that). I see that way:<br></div><div><br></div><div> 2.1 We can provide ability to change some keypairs (e.g. for Fuel UI and Horizon)<br></div>Q: How many keys user can change? We can provide ability to change all keys (but why we need to do that?)<br></div><div>Q: If user will replace some of keys with his own key - how we will check that it is not some malicious but valid user key? Or we will trust all keys by default?<br></div><div>To do that we will need to change:<br></div><div>- Some UI changes to provide ability to upload user keys<br></div><div>- Some Nailgun and Astute changes to operate with new keys<br></div><div>- Some puppet manifest changes to apply new keys and restart services<br></div><div>- Some changes to check basic validity of uploaded keys (expiry date, key length, key type)<br><br></div><div>3. We can give user ability to change CA keypair (if user trust certificate from that keypair then he automatically will trust all certificates that will signed with that CA, so if user company trusted CA issue cross-sertificate for Fuel then user automatically will agree that all certificates in deployed by Fuel services is trusted). For do that we need:<br>- Some UI changes to provide ability to upload user CA key<br>- Some Nailgun and Astute changes to operate with new CA keys<br></div><div>- Write some logic that allow us recreate all keys and restart corresponding services<br> </div><div><br>>So I think that we need to start on [3]. As this is required for OSt public<br>>endpoint SSL and also for Fuel SSL it can be quicker to make a first stage<br>
>where a self-signed certificate is managed from nailgun and a second stage<br>>with the docker CA...<br></div><div>So, yes, I think that it is good idea, cause it will be good base for [2] and [3]<br></div><div><div><div><br>[1] <a href="https://blueprints.launchpad.net/fuel/+spec/ca-deployment" target="_blank">https://blueprints.launchpad.net/fuel/+spec/ca-deployment</a><br>[2] <a href="https://blueprints.launchpad.net/fuel/+spec/fuel-ssl-endpoints" target="_blank">https://blueprints.launchpad.net/fuel/+spec/fuel-ssl-endpoints</a><br>[3] <a href="https://blueprints.launchpad.net/fuel/+spec/ssl-endpoints" target="_blank">https://blueprints.launchpad.net/fuel/+spec/ssl-endpoints</a><br><br></div><div>With best regards, Stanislaw<br></div></div></div></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">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></div>