Open Stack

+1 to Andrew

This is actually what we want to do with SSL keys.

On Wed, Feb 11, 2015 at 3:26 AM, Andrew Woodward <xarses at gmail.com> wrote:

> We need to be highly security conscious here doing this in an insecure
> manner is a HUGE risk so rsync over ssh from the master node is usually (or
> scp) OK but rsync protocol from the node in the cluster will not be BAD (it
> leaves the certs exposed on an weak service.)
>
> I could see this being implemented as some additional task type that can
> instead be run on the fuel master nodes instead of a target node. This
> could also be useful for plugin writers that may need to access some
> external API as part of their task graph. We'd need some way to make the
> generate task run once for the env, vs the push certs which runs for each
> role that has a cert requirement.
>
> we'd end up with some like
> generate_certs:
>   runs_from: master_once
>   provider: <whatever>
> push_certs:
>   runs_from: master
>   provider: bash
>   role: [*]
>
> On Thu, Jan 29, 2015 at 2:07 PM, Vladimir Kuklin <vkuklin at mirantis.com>
> wrote:
>
>> Evgeniy,
>>
>> I am not suggesting to go to Nailgun DB directly. There obviously should
>> be some layer between a serializier and DB.
>>
>> On Thu, Jan 29, 2015 at 9:07 PM, Evgeniy L <eli at mirantis.com> wrote:
>>
>>> Vladimir,
>>>
>>> >> 1) Nailgun DB
>>>
>>> Just a small note, we should not provide access to the database, this
>>> approach
>>> has serious issues, what we can do is to provide this information for
>>> example
>>> via REST API.
>>>
>>> What you are saying is already implemented in any deployment tool for
>>> example
>>> lets take a look at Ansible [1].
>>>
>>> What you can do there is to create a task which stores the result of
>>> executed
>>> shell command in some variable.
>>> And you can reuse it in any other task. I think we should use this
>>> approach.
>>>
>>> [1]
>>> http://docs.ansible.com/playbooks_variables.html#registered-variables
>>>
>>> On Thu, Jan 29, 2015 at 2:47 PM, Vladimir Kuklin <vkuklin at mirantis.com>
>>> wrote:
>>>
>>>> Evgeniy
>>>>
>>>> This is not about layers - it is about how we get data. And we need to
>>>> separate data sources from the way we manipulate it. Thus, sources may be:
>>>> 1) Nailgun DB 2) Users inventory system 3) Opendata like, list of Google
>>>> DNS Servers. Then all this data is aggregated and transformed somehow.
>>>> After that it is shipped to the deployment layer. That's how I see it.
>>>>
>>>> On Thu, Jan 29, 2015 at 2:18 PM, Evgeniy L <eli at mirantis.com> wrote:
>>>>
>>>>> Vladimir,
>>>>>
>>>>> It's no clear how it's going to help. You can generate keys with one
>>>>> tasks and then upload them with another task, why do we need
>>>>> another layer/entity here?
>>>>>
>>>>> Thanks,
>>>>>
>>>>> On Thu, Jan 29, 2015 at 11:54 AM, Vladimir Kuklin <
>>>>> vkuklin at mirantis.com> wrote:
>>>>>
>>>>>> Dmitry, Evgeniy
>>>>>>
>>>>>> This is exactly what I was talking about when I mentioned serializers
>>>>>> for tasks - taking data from 3rd party sources if user wants. In this case
>>>>>> user will be able to generate some data somewhere and fetch it using this
>>>>>> code that we import.
>>>>>>
>>>>>> On Thu, Jan 29, 2015 at 12:08 AM, Dmitriy Shulyak <
>>>>>> dshulyak at mirantis.com> wrote:
>>>>>>
>>>>>>> Thank you guys for quick response.
>>>>>>> Than, if there is no better option we will follow with second
>>>>>>> approach.
>>>>>>>
>>>>>>> On Wed, Jan 28, 2015 at 7:08 PM, Evgeniy L <eli at mirantis.com> wrote:
>>>>>>>
>>>>>>>> Hi Dmitry,
>>>>>>>>
>>>>>>>> I'm not sure if we should user approach when task executor reads
>>>>>>>> some data from the file system, ideally Nailgun should push
>>>>>>>> all of the required data to Astute.
>>>>>>>> But it can be tricky to implement, so I vote for 2nd approach.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> On Wed, Jan 28, 2015 at 7:08 PM, Aleksandr Didenko <
>>>>>>>> adidenko at mirantis.com> wrote:
>>>>>>>>
>>>>>>>>> 3rd option is about using rsyncd that we run under xinetd on
>>>>>>>>> primary controller. And yes, the main concern here is security.
>>>>>>>>>
>>>>>>>>> On Wed, Jan 28, 2015 at 6:04 PM, Stanislaw Bogatkin <
>>>>>>>>> sbogatkin at mirantis.com> wrote:
>>>>>>>>>
>>>>>>>>>> Hi.
>>>>>>>>>> I'm vote for second option, cause if we will want to implement
>>>>>>>>>> some unified hierarchy (like Fuel as CA for keys on controllers for
>>>>>>>>>> different env's) then it will fit better than other options. If we
>>>>>>>>>> implement 3rd option then we will reinvent the wheel with SSL in future.
>>>>>>>>>> Bare rsync as storage for private keys sounds pretty uncomfortable for me.
>>>>>>>>>>
>>>>>>>>>> On Wed, Jan 28, 2015 at 6:44 PM, Dmitriy Shulyak <
>>>>>>>>>> dshulyak at mirantis.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi folks,
>>>>>>>>>>>
>>>>>>>>>>> I want to discuss the way we are working with generated keys for
>>>>>>>>>>> nova/ceph/mongo and something else.
>>>>>>>>>>>
>>>>>>>>>>> Right now we are generating keys on master itself, and then
>>>>>>>>>>> distributing them by mcollective
>>>>>>>>>>> transport to all nodes. As you may know we are in the process of
>>>>>>>>>>> making this process described as
>>>>>>>>>>> task.
>>>>>>>>>>>
>>>>>>>>>>> There is a couple of options:
>>>>>>>>>>> 1. Expose keys in rsync server on master, in folder
>>>>>>>>>>> /etc/fuel/keys, and then copy them with rsync task (but it feels not very
>>>>>>>>>>> secure)
>>>>>>>>>>> 2. Copy keys from /etc/fuel/keys on master, to /var/lib/astute
>>>>>>>>>>> on target nodes. It will require additional
>>>>>>>>>>> hook in astute, smth like copy_file, which will copy data from
>>>>>>>>>>> file on master and put it on the node.
>>>>>>>>>>>
>>>>>>>>>>> Also there is 3rd option to generate keys right on
>>>>>>>>>>> primary-controller and then distribute them on all other nodes, and i guess
>>>>>>>>>>> it will be responsibility of controller to store current keys that are
>>>>>>>>>>> valid for cluster. Alex please provide more details about 3rd approach.
>>>>>>>>>>>
>>>>>>>>>>> Maybe there is more options?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> __________________________________________________________________________
>>>>>>>>>>> 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
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> __________________________________________________________________________
>>>>>>>> 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
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Yours Faithfully,
>>>>>> Vladimir Kuklin,
>>>>>> Fuel Library Tech Lead,
>>>>>> Mirantis, Inc.
>>>>>> +7 (495) 640-49-04
>>>>>> +7 (926) 702-39-68
>>>>>> Skype kuklinvv
>>>>>> 45bk3, Vorontsovskaya Str.
>>>>>> Moscow, Russia,
>>>>>> www.mirantis.com <http://www.mirantis.ru/>
>>>>>> www.mirantis.ru
>>>>>> vkuklin at mirantis.com
>>>>>>
>>>>>>
>>>>>> __________________________________________________________________________
>>>>>> 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
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Yours Faithfully,
>>>> Vladimir Kuklin,
>>>> Fuel Library Tech Lead,
>>>> Mirantis, Inc.
>>>> +7 (495) 640-49-04
>>>> +7 (926) 702-39-68
>>>> Skype kuklinvv
>>>> 45bk3, Vorontsovskaya Str.
>>>> Moscow, Russia,
>>>> www.mirantis.com <http://www.mirantis.ru/>
>>>> www.mirantis.ru
>>>> vkuklin at mirantis.com
>>>>
>>>>
>>>> __________________________________________________________________________
>>>> 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
>>>
>>>
>>
>>
>> --
>> Yours Faithfully,
>> Vladimir Kuklin,
>> Fuel Library Tech Lead,
>> Mirantis, Inc.
>> +7 (495) 640-49-04
>> +7 (926) 702-39-68
>> Skype kuklinvv
>> 45bk3, Vorontsovskaya Str.
>> Moscow, Russia,
>> www.mirantis.com <http://www.mirantis.ru/>
>> www.mirantis.ru
>> vkuklin at mirantis.com
>>
>> __________________________________________________________________________
>> 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
>>
>>
>
>
> --
> Andrew
> Mirantis
> Fuel community ambassador
> Ceph community
>
> __________________________________________________________________________
> 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
>
>


-- 
Yours Faithfully,
Vladimir Kuklin,
Fuel Library Tech Lead,
Mirantis, Inc.
+7 (495) 640-49-04
+7 (926) 702-39-68
Skype kuklinvv
45bk3, Vorontsovskaya Str.
Moscow, Russia,
www.mirantis.com <http://www.mirantis.ru/>
www.mirantis.ru
vkuklin at mirantis.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150213/d346eb5c/attachment.html>