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 <sbogat...@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 <dnikis...@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 <dnikis...@mirantis.com >> > wrote: >> >>> Matthew, >>> >>> sorry, didn't mean to butcher your name :( >>> >>> On Thu, Nov 12, 2015 at 10:41 AM, Dmitry Nikishov < >>> dnikis...@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 < >>>> mmoses...@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 < >>>>> dnikis...@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 < >>>>>> sbogat...@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 < >>>>>>> dnikis...@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 < >>>>>>>> dnikis...@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 < >>>>>>>>> sbogat...@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 < >>>>>>>>>> bpiotrow...@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 < >>>>>>>>>>> ahec...@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 < >>>>>>>>>>>> dnikis...@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-requ...@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-requ...@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-requ...@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-requ...@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-requ...@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-requ...@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-requ...@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-requ...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev