<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><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>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> 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> 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">https://blueprints.launchpad.net/fuel/+spec/ca-deployment</a><br>[2] <a href="https://blueprints.launchpad.net/fuel/+spec/fuel-ssl-endpoints">https://blueprints.launchpad.net/fuel/+spec/fuel-ssl-endpoints</a><br>[3] <a href="https://blueprints.launchpad.net/fuel/+spec/ssl-endpoints">https://blueprints.launchpad.net/fuel/+spec/ssl-endpoints</a><br><br></div><div>With best regards, Stanislaw<br></div></div></div></div>