Dmitry, I mean, currently shotgun fetches services' configuration along with astute.yaml. These files contain passwords, keys, tokens. I beleive, these should be sanitized. Or, better yet, there should be an option to sanitize sensitive data from fetched files.
Aleksandr, Currently Fuel has a service non-root account with passwordless sudo enabled. This may change in the future (the passwordless part), however, now I don't see an issue there. Additionally, it is possible for users to configure sudo for the user-facing account however they like. In regards to have this tool to use a non-root accounts, there are 2 items: - execute commands, that require elevated privileges (the easy part -- user has to be able to execute these commands with sudo and without password) - copy files, that this user doesn't have read privileges for. For the second item, there are 2 possible solutions: 1. Give the non-root user read privileges for these files. Pros: - More straightforward, generally acceptable way Cons: - Requires additional implementation to give permissions to the user - (?) Not very extensible: to allow copying a new file, we'd have to first add it to the tool's config, and somehow implement adding read permissions 2. Somehow allow to copy these files with sudo. Pros: - More simple implementation: we'll just need to make sure that the user can do passwordless sudo - Extensible: to add more files, it's enough to just specify them in the tool's configuration. Cons: - Non-obvious, obscure way - Relies on having to be able to do something like "sudo cat /path/to/file", which is not much better that just giving the user read privileges. In fact, the only difference between this and giving the user the read rights is that it is possible to allow "sudo cat" for files, that don't yet exist, whereas giving permissions requires that these files already are on the filesystem. What way do you think is more appropriate? On Wed, Apr 20, 2016 at 5:28 AM, Aleksandr Dobdin <adob...@mirantis.com> wrote: > Dmitry, > > You can create a non-root user account without root privileges but you > need to add it to appropriate groups and configure sudo permissions (even > though you add this user to root group, it will fail with iptables command > for example) to get config files and launch requested commands.I suppose > that it is possible to note this possibility in the documentation and > provide a customer with detailed instructions on how to setup this user > account.There are some logs that will also be missing from the snapshot > with the message permission denied (only the root user has access to some > files with 0600 mask) > This user account could be specified into config.yaml (ssh -> opts option) > > Sincerely yours, > Aleksandr Dobdin > Senior Operations 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 > > -- 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