Re: [openstack-dev] [Fuel] Distribution of keys for environments

2015-02-18 Thread Evgeniy L
Vladimir, What Andrew is saying is we should copy some specific keys to some specific roles, and it's easy to do even now, just create several role specific tasks and copy required keys. Deployment engineer who knows which keys are required for which roles can do that. What you are saying is we

Re: [openstack-dev] [Fuel] Distribution of keys for environments

2015-02-18 Thread Vladimir Kuklin
Andrew +1 to it - I provided these concerns to guys that we should not ship data to tasks that do not need it. It will make us able to increase security for pluggable architecture On Fri, Feb 13, 2015 at 9:57 PM, Andrew Woodward xar...@gmail.com wrote: Cool, You guys read my mind o.O RE: the

Re: [openstack-dev] [Fuel] Distribution of keys for environments

2015-02-13 Thread Vladimir Kuklin
+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

Re: [openstack-dev] [Fuel] Distribution of keys for environments

2015-02-13 Thread Evgeniy L
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

Re: [openstack-dev] [Fuel] Distribution of keys for environments

2015-02-13 Thread Andrew Woodward
Cool, You guys read my mind o.O RE: the review. We need to avoid copying the secrets to nodes that don't require them. I think it might be too soon to be able to make granular tasks based for this, but we need to move that way. Also, how are the astute tasks read into the environment? Same as

Re: [openstack-dev] [Fuel] Distribution of keys for environments

2015-02-10 Thread Andrew Woodward
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

Re: [openstack-dev] [Fuel] Distribution of keys for environments

2015-01-29 Thread Vladimir Kuklin
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,

Re: [openstack-dev] [Fuel] Distribution of keys for environments

2015-01-29 Thread Vladimir Kuklin
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.

Re: [openstack-dev] [Fuel] Distribution of keys for environments

2015-01-29 Thread Evgeniy L
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

Re: [openstack-dev] [Fuel] Distribution of keys for environments

2015-01-29 Thread Evgeniy L
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

Re: [openstack-dev] [Fuel] Distribution of keys for environments

2015-01-29 Thread Vladimir Kuklin
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

Re: [openstack-dev] [Fuel] Distribution of keys for environments

2015-01-28 Thread Evgeniy L
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

Re: [openstack-dev] [Fuel] Distribution of keys for environments

2015-01-28 Thread Dmitriy Shulyak
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

Re: [openstack-dev] [Fuel] Distribution of keys for environments

2015-01-28 Thread Stanislaw Bogatkin
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

Re: [openstack-dev] [Fuel] Distribution of keys for environments

2015-01-28 Thread Aleksandr Didenko
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