Open Stack

Sorry in understood incorrectly - using HTTP/Web IMO usually makes kind of
overhead if designed from the beginning.
If there are some HTTP authentication/CSR request/key management mechanisms
already in place, of course there is no overhead.

Regards,

A.

On Fri, Aug 21, 2015 at 12:43 PM, Evgeniy L <eli at mirantis.com> wrote:

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