Open Stack

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