Hello, 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.
Lets back up a bit and list the different options for Fuel users: 0/ The user is happy with plain HTTP. => Already supported :) 1/ The user wants HTTPS but doesn't want the burden associated with certificate management. => Fuel creates and manages the SSL certificates, be them self-signed or signed by some internal CA. => Using an internal CA instead of multiple self-signed certificates is cleaner as you explained. 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) => Fuel supports certificate + key uploads => It should be possible to tell Fuel which entity (Fuel, OSt environment) uses which certificate 3/ The user wants HTTPS and agrees to let Fuel generating certificates on behalf of some corporate PKI. => Fuel supports CA + key uploads 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. I've also added some questions/comments inline. BR, Simon On Tue, Sep 9, 2014 at 5:53 PM, Stanislaw Bogatkin <sbogat...@mirantis.com> wrote: > I think that if we have 3 blueprints that realises some SSL stuff around > themselves then we can discuss it here. > My vision about SSL in Fuel split into 3 parts: > > A) We need to implement [1] blueprint, cause it is only one way to > generate certificates. > How i see that: > 1.0 We sync puppet-openssl from upstream, adapt it for Fuel tasks. > 1.1 We create docker container (we already have many, so containerized > CA should work well) with OpenSSL and puppet manifests in it. > 1.2 When container will start first time, it will create CA that will > store on master node. > > Our workitems here is: > - Create docker container > - Sync upstream puppet-openssl and adapt it for Fuel > - Write code to create CA > First of all I think this blueprint should be submitted to fuel-specs ;) 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? > > B) We need to implement [2] blueprint. How I see that: > 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. > > I find awkward to have the CA container restarting nginx... > Our workitems here is: > - Write code to check if we already have generated certificate and > generate new if we have not. > > C) Then we need to implement [3] blueprint > For next step we have 2 options: > First: > 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). > Q: Main question here is - how many keypairs we will create? One for every > service or one for all? > As a first implementation, I assume that one certificate for all OSt services is good enough. > 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. > 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? > 1.5 On nodes puppet will do all work. We need to write some code for > that > Pros of that method: > + It's relative simple, we can create clean and lucid code that > will be easy for support > Cons of that method: > - 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. > > Second: > 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. > 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) > Pros of that method: > + I don't see any > Cons of that method: > - Code will be not so obvious > - 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 > > Independing of choice (first or second), our workitems here is: > - Write code to provide functions about generating keypairs, csr's and > signing them. > > 1.5. When we have created CA and certs for services, we can do usual > puppet apply to deploy changes. > > Workitems on that stage: > - Sync upstream modules that already have big changes to SSL support (e.g. > HAProxy) and adapt that modules to Fuel usage > - Rewrite some of manifests to support https support > > As I see, at that phase we can say that Stage I for blueprint [3] is ready. > What we can do next? My thoughts is that: > > 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: > > 2.1 We can provide ability to change some keypairs (e.g. for Fuel UI > and Horizon) > Q: How many keys user can change? We can provide ability to change all > keys (but why we need to do that?) > 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? > To do that we will need to change: > - Some UI changes to provide ability to upload user keys > - Some Nailgun and Astute changes to operate with new keys > - Some puppet manifest changes to apply new keys and restart services > - Some changes to check basic validity of uploaded keys (expiry date, key > length, key type) > > 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: > - Some UI changes to provide ability to upload user CA key > - Some Nailgun and Astute changes to operate with new CA keys > - Write some logic that allow us recreate all keys and restart > corresponding services > > >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... > So, yes, I think that it is good idea, cause it will be good base for [2] > and [3] > > [1] https://blueprints.launchpad.net/fuel/+spec/ca-deployment > [2] https://blueprints.launchpad.net/fuel/+spec/fuel-ssl-endpoints > [3] https://blueprints.launchpad.net/fuel/+spec/ssl-endpoints > > With best regards, Stanislaw > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev