-
Notifications
You must be signed in to change notification settings - Fork 130
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update Salt Master configuration template #839
base: master
Are you sure you want to change the base?
Update Salt Master configuration template #839
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've often wondered if we shouldn't have code to fully manage the whole salt server, just like we can set up and manage the the configuration.
What I mean by that is to simplify the procedure. https://docs.theforeman.org/nightly/Managing_Configurations_Salt/index-katello.html now documents a lot of manual steps and that's generally not something we want.
For example, https://docs.theforeman.org/nightly/Managing_Configurations_Salt/index-katello.html#Authenticating_Salt_Minions_Using_Host_Names_managing-configurations-salt tells you to add foreman-proxy
to the root
group. IMHO that's extremely dangerous.
https://docs.theforeman.org/nightly/Managing_Configurations_Salt/index-katello.html#Configuring_the_Salt_API_managing-configurations-salt is also completely wrong because it must use installer options to persist.
I wrote up https://github.com/theforeman/puppet-foreman_proxy/blob/master/examples/salt.pp and https://github.com/theforeman/puppet-foreman_proxy/blob/master/spec/acceptance/salt_spec.rb as end-to-end testing, but as you can see it's still extremely basic. It would be nice if we actually had testing that verified some end-to-end workflow.
@maximiliankolb tagging you in because the Salt documentation must be reviewed. It can't be right.
Thanks for the ping. Making sure that the docs work after we've merged this is definitely on my plate! @sbernhard Is there any use case to configure the interfaces? Or are these two simply required to make Salt+Foreman work? |
@sbernhard Friendly reminder. |
80e1218
to
fd10309
Compare
Coming back to this, thanks @ekohl for the review and feedback! I totally agree, we should re-think the user management and I think since Salt switches to a non-root user we can take this as reason to update ours too. However, for this PR, I'd just update the master configuration. I'm currently testing which default config we should apply for netapi to guarantee that the salt-api works for Foreman. |
6ec9558
to
f574639
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
* Set user for running Salt Master service due to 3006 changes https://docs.saltproject.io/en/3006/topics/releases/3006.0.html#linux-packaging-salt-master-salt-user-and-group Salt API * Add netapi_enable_clients explicitly due to 3006 changes https://docs.saltproject.io/en/master/topics/netapi/netapi-enable-clients.html#select-client-interfaces-to-enable * Add api_interfaces parameter to enable configuration of API accessibility. However, smart_proxy_salt utilizes only the "runner" API interface.
f574639
to
8482827
Compare
@ekohl I've rebased to latest master, I assume the failing Ubuntu tests are unrelated. I'm addressing some of your concerns on how we should manage the salt service in my RFC: https://community.theforeman.org/t/rfc-running-salt-as-non-root-user/39820 From my side, this seems ready to be merged? |
→ This is more of an pro-active change. I don't quite know where exactly we run into an issue with cherrypy-API permissions. So, I need a second opinion on this.
→ This is motivated by the following change:
Since 3006, Salt installs with an explicit user that runs the Salt Master daemon in order to limit the daemon permissions. If that users differs from the user that we execute the
salt ...
commands with (when triggering Salt from Smart Proxy), we get some permission issues. More specifically,sudo -u foreman-proxy salt '*' test.ping
runs into the following error:When executing
salt '*' test.ping
, that comand wants to connect to the Salt Master whose PID is stored in/var/run/salt/master/*
. But, with the 3006-explicit-user update, they limit access to the/var/run/salt
folder to the same user which runs the Salt Master daemon.Therefore, I see two options:
A) Make the Salt Master daemon run with the same user that we execute the
salt ...
commands with (currently implemented in this PR)B) Take care that the foreman-proxy user has the necessary permissions/adapt the folder permissions that the foreman-proxy user can execute
salt ...
even if the daemon is started by a different user.