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

Stanislaw Bogatkin sbogatkin at mirantis.com
Fri Nov 20 07:07:56 UTC 2015


Dmitry, I mean whole feature.
Btw, why do you want to grant capabilities via puppet? It should be done by
post-install package section, I believe.

Also I doesn't know if supervisord can bound process capabilities like
systemd can - we could use this opportunity too.

On Thu, Nov 19, 2015 at 7:44 PM, Dmitry Nikishov <dnikishov at mirantis.com>
wrote:

> 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.
>
> __________________________________________________________________________
> 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/20151120/6df73cc2/attachment.html>


More information about the OpenStack-dev mailing list