Open Stack

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 <sbogatkin at 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140910/d814d0e0/attachment.html>