Open Stack

Hi Adam,

I'm not sure if understand you correctly, what do you mean by "overhead for
certificate provisioning"? We already have all the mechanisms in place in
order
to provision certificates, the point is currently with user's certificates
we work in
absolutely different way and store them in absolutely different place. And
this
way leads to huge problems.

Thanks,

On Fri, Aug 21, 2015 at 1:33 PM, Adam Heczko <aheczko at mirantis.com> wrote:

> Hi Evgeniy,
> what you've proposed is all right, although it adds some overhead for
> certificate provisioning.
> In fact, to do it right we should probably define REST API for
> provisioning certificates.
> I'm rather for simplified approach, consisting of Shell / Puppet scripts
> for certificate upload/management.
>
> Regards,
>
> A.
>
>
> On Fri, Aug 21, 2015 at 12:20 PM, Evgeniy L <eli at mirantis.com> wrote:
>
>> Hi Stanislaw,
>>
>> I agree that user's certificates mustn't be saved in Nailgun database, in
>> cluster attributes,
>> in this case it can be seen in all the logs, which is terrible security
>> problem,
>> and we already have a place where we keep auto-generated certificates and
>> ssh-keys, and those are copied to specific nodes by Astute.
>>
>> So UI should send the file to specific URL, Nginx should be configured to
>> send auth
>> request to backend, after request is authorised, Nginx should save the
>> file into predefined
>> directory, the same which we use for autogenerated certificates, in this
>> case such
>> tool as OSTF can take certificates from a single place.
>>
>> Thanks,
>>
>> On Fri, Aug 21, 2015 at 12:10 PM, Stanislaw Bogatkin <
>> sbogatkin at mirantis.com> wrote:
>>
>>> Hi folks.
>>>
>>> Today I want to discuss the way we save SSL keys for Fuel environments.
>>> As you maybe know we have 2 ways to get a key:
>>> a. Generate it by Fuel (self-signed certificate will be created in this
>>> case). In this case we will generate private key, csr and crt in a
>>> pre-deployment hook on master node and then copy keypair to the nodes which
>>> needed it.
>>>
>>> b. Get a pre-generated keypair from user. In this case user should
>>> create keypair by himself and then upload it through Fuel UI settings tab.
>>> In this case keypair will be saved in nailgun database and then will
>>> serialized into astute.yaml on cluster nodes, pulled from it by puppet and
>>> saved into a file.
>>>
>>> Second way has some flaws:
>>> 1. We already have some keys for nodes and we store them on master node.
>>> Store keys in different places is bad, cause:
>>> 1.1. User experience - user should remember that in some cases keys will
>>> be store in FS and in some other cases - in DB.
>>> 1.2. It brings problems for implementation in other different places -
>>> for example, we need to get certificate for properly run OSTF tests and now
>>> we should implement two different ways to deliver that certificate to OSTF
>>> container. The same for fuel-cli - we should somehow get certificate from
>>> DB and place it in FS to use it.
>>> 2. astute.yaml is similar for all nodes. Not all of nodes needs to have
>>> private key, but now we cannot control this.
>>> 3. If keypair data serializes into astute.yaml it means than that data
>>> automatically will be fetched when diagnostic snapshot will created. So in
>>> some cases in can lead to security vulnerability, or we will must to write
>>> another crutch to cut it out of diagnostic snapshot.
>>>
>>>
>>> So I propose to get rid of saving keypair in nailgun database and
>>> implement a way to always saving it to local FS on master node. We need to
>>> implement next items:
>>>
>>> - Change UI logic that saving keypair into DB to logic that will save it
>>> to local FS
>>> - Implement according fixes in fuel-library
>>>
>>>
>>> __________________________________________________________________________
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Adam Heczko
> Security Engineer @ Mirantis Inc.
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> 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/20150821/fdbee08a/attachment.html>