Andrew, It looks like what you've described is already done for ssh keys [1].
[1] https://review.openstack.org/#/c/149543/ On Fri, Feb 13, 2015 at 6:12 PM, Vladimir Kuklin <vkuk...@mirantis.com> wrote: > +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 <xar...@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 <vkuk...@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 <e...@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 <vkuk...@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 <e...@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 < >>>>>> vkuk...@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 < >>>>>>> dshul...@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 <e...@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 < >>>>>>>>> adide...@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 < >>>>>>>>>> sbogat...@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 < >>>>>>>>>>> dshul...@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-requ...@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-requ...@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-requ...@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-requ...@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 >>>>>>> vkuk...@mirantis.com >>>>>>> >>>>>>> >>>>>>> __________________________________________________________________________ >>>>>>> OpenStack Development Mailing List (not for usage questions) >>>>>>> Unsubscribe: >>>>>>> openstack-dev-requ...@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-requ...@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 >>>>> vkuk...@mirantis.com >>>>> >>>>> >>>>> __________________________________________________________________________ >>>>> OpenStack Development Mailing List (not for usage questions) >>>>> Unsubscribe: >>>>> openstack-dev-requ...@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-requ...@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 >>> vkuk...@mirantis.com >>> >>> >>> __________________________________________________________________________ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: >>> openstack-dev-requ...@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-requ...@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 > vkuk...@mirantis.com > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev