Open Stack

Stanislaw, do you mean the whole feature, or just a user? Since feature
would require actually changing puppet code.

On Tue, Nov 17, 2015 at 5:08 AM, Stanislaw Bogatkin <sbogatkin at mirantis.com>
wrote:

> Dmitry, I believe it should be done via package spec as a part of
> installation.
>
> On Mon, Nov 16, 2015 at 8:04 PM, Dmitry Nikishov <dnikishov at mirantis.com>
> wrote:
>
>> Hello folks,
>>
>> I have updated the spec, please review and share your thoughts on it:
>> https://review.openstack.org/#/c/243340/
>>
>> Thanks.
>>
>> On Thu, Nov 12, 2015 at 10:42 AM, Dmitry Nikishov <dnikishov at mirantis.com
>> > wrote:
>>
>>> Matthew,
>>>
>>> sorry, didn't mean to butcher your name :(
>>>
>>> On Thu, Nov 12, 2015 at 10:41 AM, Dmitry Nikishov <
>>> dnikishov at mirantis.com> wrote:
>>>
>>>> Matther,
>>>>
>>>> I totally agree that each daemon should have it's own user which should
>>>> be created during installation of the relevant package. Probably I didn't
>>>> state this clear enough in the spec.
>>>>
>>>> However, there are security requirements in place that root should not
>>>> be used at all. This means that there should be a some kind of maintenance
>>>> or system user ('fueladmin'), which would have enough privileges to
>>>> configure and manage Fuel node (e.g. run "sudo puppet apply" without
>>>> password, create mirrors etc). This also means that certain fuel- packages
>>>> would be required to have their files accessible to that user. That's the
>>>> idea behind having a package which would create 'fueladmin' user and
>>>> including it into other fuel- packages requirements lists.
>>>>
>>>> So this part of the feature comes down to having a non-root user with
>>>> sudo privileges and passwordless sudo for certain commands (like 'puppet
>>>> apply <path-to-host-only.pp>') for scripting.
>>>>
>>>> On Thu, Nov 12, 2015 at 9:52 AM, Matthew Mosesohn <
>>>> mmosesohn at mirantis.com> wrote:
>>>>
>>>>> Dmitry,
>>>>>
>>>>> We really shouldn't put "user" creation into a single package and then
>>>>> depend on it for daemons. If we want nailgun service to run as nailgun
>>>>> user, it should be created in the fuel-nailgun package.
>>>>> I think it makes the most sense to create multiple users, one for each
>>>>> service.
>>>>>
>>>>> Lastly, it makes a lot of sense to tie a "fuel" CLI user to
>>>>> python-fuelclient package.
>>>>>
>>>>> On Thu, Nov 12, 2015 at 6:42 PM, Dmitry Nikishov <
>>>>> dnikishov at mirantis.com> wrote:
>>>>>
>>>>>> Stanislaw,
>>>>>>
>>>>>> I agree that this approch would work well. However, does Puppet allow
>>>>>> managing capabilities and/or file ACLs? Or can they be easily set up when
>>>>>> installing RPM package? (is there a way to specify capabilities/ACLs in the
>>>>>> RPM spec file?) This doesn't seem to be supported out of the box.
>>>>>>
>>>>>> I'm going to research if it is possible to manage capabilities and
>>>>>>  ACLs with what we have out of the box (RPM, Puppet).
>>>>>>
>>>>>> On Wed, Nov 11, 2015 at 4:29 AM, Stanislaw Bogatkin <
>>>>>> sbogatkin at mirantis.com> wrote:
>>>>>>
>>>>>>> Dmitry, I propose to give needed linux capabilities
>>>>>>> (like CAP_NET_BIND_SERVICE) to processes (services) which needs them and
>>>>>>> then start these processes from non-privileged user. It will give you
>>>>>>> ability to run each process without 'sudo' at all with well fine-grained
>>>>>>> permissions.
>>>>>>>
>>>>>>> On Tue, Nov 10, 2015 at 11:06 PM, Dmitry Nikishov <
>>>>>>> dnikishov at mirantis.com> wrote:
>>>>>>>
>>>>>>>> Stanislaw,
>>>>>>>>
>>>>>>>> I've been experimenting with 'capsh' on the 6.1 master node and it
>>>>>>>> doesn't seem to preserve any capabilities when setting SECURE_NOROOT bit,
>>>>>>>> even if explicitely told to do so (via either --keep=1 or
>>>>>>>> "SECURE_KEEP_CAPS" bit).
>>>>>>>>
>>>>>>>> On Tue, Nov 10, 2015 at 11:20 AM, Dmitry Nikishov <
>>>>>>>> dnikishov at mirantis.com> wrote:
>>>>>>>>
>>>>>>>>> Bartolomiej, Adam,
>>>>>>>>> Stanislaw is correct. And this is going to be ported to master.
>>>>>>>>> The goal currently is to reach an agreement on the implementation so that
>>>>>>>>> there's going to be a some kinf of compatibility during upgrades.
>>>>>>>>>
>>>>>>>>> Stanislaw,
>>>>>>>>> Do I understand correctly that you propose using something like
>>>>>>>>> sucap to launch from root, switch to a different user and then drop
>>>>>>>>> capabilities which are not required?
>>>>>>>>>
>>>>>>>>> On Tue, Nov 10, 2015 at 3:11 AM, Stanislaw Bogatkin <
>>>>>>>>> sbogatkin at mirantis.com> wrote:
>>>>>>>>>
>>>>>>>>>> Bartolomiej, it's customer-related patches, they, I think, have
>>>>>>>>>> to be done for 6.1 prior to 8+ release.
>>>>>>>>>>
>>>>>>>>>> Dmitry, it's nice to hear about it. Did you consider to use linux
>>>>>>>>>> capabilities on fuel-related processes instead of just using non-extended
>>>>>>>>>> POSIX privileged/non-privileged permission checks?
>>>>>>>>>>
>>>>>>>>>> On Tue, Nov 10, 2015 at 10:11 AM, Bartlomiej Piotrowski <
>>>>>>>>>> bpiotrowski at mirantis.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> We don't develop features for already released versions… It
>>>>>>>>>>> should be done for master instead.
>>>>>>>>>>>
>>>>>>>>>>> BP
>>>>>>>>>>>
>>>>>>>>>>> On Tue, Nov 10, 2015 at 7:02 AM, Adam Heczko <
>>>>>>>>>>> aheczko at mirantis.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Dmitry,
>>>>>>>>>>>> +1
>>>>>>>>>>>>
>>>>>>>>>>>> Do you plan to port your patchset to future Fuel releases?
>>>>>>>>>>>>
>>>>>>>>>>>> A.
>>>>>>>>>>>>
>>>>>>>>>>>> On Tue, Nov 10, 2015 at 12:14 AM, Dmitry Nikishov <
>>>>>>>>>>>> dnikishov at mirantis.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Hey guys.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I've been working on making Fuel not to rely on superuser
>>>>>>>>>>>>> privileges
>>>>>>>>>>>>> at least for day-to-day operations. These include:
>>>>>>>>>>>>> a) running Fuel services (nailgun, astute etc)
>>>>>>>>>>>>> b) user operations (create env, deploy, update, log in)
>>>>>>>>>>>>>
>>>>>>>>>>>>> The reason for this is that many security policies simply do
>>>>>>>>>>>>> not
>>>>>>>>>>>>> allow root access (especially remote) to servers/environments.
>>>>>>>>>>>>>
>>>>>>>>>>>>> This feature/enhancement means that anything that currently is
>>>>>>>>>>>>> being
>>>>>>>>>>>>> run under root, will be evaluated and, if possible, put under
>>>>>>>>>>>>> a non-privileged
>>>>>>>>>>>>> user. This also means that remote root access will be disabled.
>>>>>>>>>>>>> Instead, users will have to log in with "fueladmin" user.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Together with Omar <gomarivera> we've put together a
>>>>>>>>>>>>> blueprint[0] and a
>>>>>>>>>>>>> spec[1] for this feature. I've been developing this for Fuel
>>>>>>>>>>>>> 6.1, so there
>>>>>>>>>>>>> are two patches into fuel-main[2] and fuel-library[3] that can
>>>>>>>>>>>>> give you an
>>>>>>>>>>>>> impression of current approach.
>>>>>>>>>>>>>
>>>>>>>>>>>>> These patches do following:
>>>>>>>>>>>>> - Add fuel-admin-user package, which creates 'fueladmin'
>>>>>>>>>>>>> - Make all other fuel-* packages depend on fuel-admin-user
>>>>>>>>>>>>> - Put supervisord under 'fueladmin' user.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Please review the spec/patches and let's have a discussion on
>>>>>>>>>>>>> the approach to
>>>>>>>>>>>>> this feature.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thank you.
>>>>>>>>>>>>>
>>>>>>>>>>>>> [0]
>>>>>>>>>>>>> https://blueprints.launchpad.net/fuel/+spec/fuel-nonsuperuser
>>>>>>>>>>>>> [1] https://review.openstack.org/243340
>>>>>>>>>>>>> [2] https://review.openstack.org/243337
>>>>>>>>>>>>> [3] https://review.openstack.org/243313
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Dmitry Nikishov,
>>>>>>>>>>>>> Deployment 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
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> 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
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> __________________________________________________________________________
>>>>>>>>>> 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
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Dmitry Nikishov,
>>>>>>>>> Deployment Engineer,
>>>>>>>>> Mirantis, Inc.
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Dmitry Nikishov,
>>>>>>>> Deployment 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
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Dmitry Nikishov,
>>>>>> Deployment 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
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Dmitry Nikishov,
>>>> Deployment Engineer,
>>>> Mirantis, Inc.
>>>>
>>>
>>>
>>>
>>> --
>>> Dmitry Nikishov,
>>> Deployment Engineer,
>>> Mirantis, Inc.
>>>
>>
>>
>>
>> --
>> Dmitry Nikishov,
>> Deployment 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
>
>


-- 
Dmitry Nikishov,
Deployment Engineer,
Mirantis, Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151117/75c0fe84/attachment.html>