[openstack-dev] [Fuel] Running Fuel node as non-superuser

Dmitry Nikishov dnikishov at mirantis.com
Thu Nov 19 16:44:38 UTC 2015


My main concern with using linux capabilities/acls on files is actually
puppet support or, actually, the lack of it. ACLs are possible AFAIK, but
we'd need to write a custom type/provider for capabilities. I suggest to
wait with capabilities support till systemd support.

On Tue, Nov 17, 2015 at 9:15 AM, Dmitry Nikishov <dnikishov at mirantis.com>
wrote:

> 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.
>



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


More information about the OpenStack-dev mailing list