Open Stack

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

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.

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?
    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.
    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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140909/a554d0be/attachment.html>