Is it possible to alter the SSH user on a role basis within Foreman?
We have a situation where the granularity of control provided by Foreman
doesn't quite fit our requirements. We would like to be able to use a
'read-only' SSH user for executing some commands, then a more privileged
user for executing commands that will change the system.
e.g.
read-only SSH user used to run a yum list command as this doesn't change
the system
ops SSH user used to run yum update commands as these are part of general
patching requirements
admin SSH user used to run yum install/remove commands as these shouldn't
be required as part of normal daily running or patching cycles.
When we change our Foreman-wide SSH User, we then have to craft sudo rules
to allow escalation of yum as that user. But we don't have the ability to
then separate out the read-only, update, and install/remove functions of
yum to different users.
I've looked at trying to do this by changing the effective_user for the
job, but this leaves us having to create sudo rules that allow the
escalation of the "/remote_working_dir/foreman-ssh-cmd-{UUID}/script"
command, which then covers all types of remote execution.
Ideally our Foreman users would be mapped to a different SSH user, or our
jobs should be able to select the SSH user and not just the effective sudo
user at the client side.
Duncan
Hello,
you can change SSH user too by modifying the remote_execution_ssh_user
parameter as mentioned at [1]. The granularity is per host/host
group/subnet/domain/os/organization/location. Unfortunately it's impossible to
configure it per job template (command) right now. The reason for this design
was that specifying arbitrary user would not work until his/her SSH key is
installed on target. That's why we prefer changing effective user using sudo on
target host. Maybe a puppet module that would configure sudoers based on some
policy would be good solution.
We could also improve this on host side where we could have a Foreman script
that would handle the authorization. There were some discussion on this topic,
but there's no clear roadmap.
[1]
https://theforeman.org/plugins/foreman_remote_execution/0.3/index.html#2.2RemoteHostsConfiguration
Hope this helps
···
--
Marek
On Wednesday 12 of October 2016 02:09:15 Duncan Innes wrote:
Is it possible to alter the SSH user on a role basis within Foreman?
We have a situation where the granularity of control provided by Foreman
doesn’t quite fit our requirements. We would like to be able to use a
’read-only’ SSH user for executing some commands, then a more privileged
user for executing commands that will change the system.
e.g.
read-only SSH user used to run a yum list command as this doesn’t change
the system
ops SSH user used to run yum update commands as these are part of general
patching requirements
admin SSH user used to run yum install/remove commands as these shouldn’t
be required as part of normal daily running or patching cycles.
When we change our Foreman-wide SSH User, we then have to craft sudo rules
to allow escalation of yum as that user. But we don’t have the ability to
then separate out the read-only, update, and install/remove functions of
yum to different users.
I’ve looked at trying to do this by changing the effective_user for the
job, but this leaves us having to create sudo rules that allow the
escalation of the "/remote_working_dir/foreman-ssh-cmd-{UUID}/script"
command, which then covers all types of remote execution.
Ideally our Foreman users would be mapped to a different SSH user, or our
jobs should be able to select the SSH user and not just the effective sudo
user at the client side.
Duncan
Yes, I'd seen the parameter override for host or hostgroup. Unfortunately
this still leaves us with a single SSH user for a host and therefore a
single set of sudo rules to control privilege escalation.
We're also one of those places where Puppet is allowed to run once at
deployment time, and then has to be noop from then on. Our sudoers file is
a complex beast and controls all types of user elevation. It is controlled
by a different team and proposed changes to the sudoers must go through a
tortuous process before being permitted.
I can understand that a user-based SSH user may lead to problems if the
relevant SSH users aren't created on the host, but the same can be said for
the current remote_execution_ssh_user (and also the
remote_execution_effective_user) surely? We already need to ensure the
remote_execution_ssh_user exists on the client and the SSH keys are
distributed accordingly. It wouldn't be a great step for us to ensure more
than 1 SSH user was configured on relevant hosts.
Our team is permitted access to 3 users on each box; read-only user, ops
user, privileged user. These each have slightly more privilege than the
previous. I can see a way of using the effective user as a middle-man for
our escalations, but would still require the ability to restrict Roles to a
specific sets of effective users. Otherwise we still end up with all
Foreman users able to select any effective user for the job.
D
···
On Thursday, 13 October 2016 07:05:31 UTC+1, Marek Hulán wrote:
>
> Hello,
>
> you can change SSH user too by modifying the remote_execution_ssh_user
> parameter as mentioned at [1]. The granularity is per host/host
> group/subnet/domain/os/organization/location. Unfortunately it's
> impossible to
> configure it per job template (command) right now. The reason for this
> design
> was that specifying arbitrary user would not work until his/her SSH key is
> installed on target. That's why we prefer changing effective user using
> sudo on
> target host. Maybe a puppet module that would configure sudoers based on
> some
> policy would be good solution.
>
> We could also improve this on host side where we could have a Foreman
> script
> that would handle the authorization. There were some discussion on this
> topic,
> but there's no clear roadmap.
>
> [1]
>
> https://theforeman.org/plugins/foreman_remote_execution/0.3/index.html#2.2RemoteHostsConfiguration
>
> Hope this helps
>
> --
> Marek
>
>
> On Wednesday 12 of October 2016 02:09:15 Duncan Innes wrote:
> > Is it possible to alter the SSH user on a role basis within Foreman?
> >
> > We have a situation where the granularity of control provided by Foreman
> > doesn't quite fit our requirements. We would like to be able to use a
> > 'read-only' SSH user for executing some commands, then a more privileged
> > user for executing commands that will change the system.
> >
> > e.g.
> >
> > read-only SSH user used to run a yum list command as this doesn't change
> > the system
> > ops SSH user used to run yum update commands as these are part of
> general
> > patching requirements
> > admin SSH user used to run yum install/remove commands as these
> shouldn't
> > be required as part of normal daily running or patching cycles.
> >
> > When we change our Foreman-wide SSH User, we then have to craft sudo
> rules
> > to allow escalation of yum as that user. But we don't have the ability
> to
> > then separate out the read-only, update, and install/remove functions of
> > yum to different users.
> >
> > I've looked at trying to do this by changing the effective_user for the
> > job, but this leaves us having to create sudo rules that allow the
> > escalation of the "/remote_working_dir/foreman-ssh-cmd-{UUID}/script"
> > command, which then covers all types of remote execution.
> >
> > Ideally our Foreman users would be mapped to a different SSH user, or
> our
> > jobs should be able to select the SSH user and not just the effective
> sudo
> > user at the client side.
> >
> > Duncan
>
>
I have a similar requirement, but to specify ssh user per job (not per job template).
The explanation of the specified user must be properly installed to target hosts in advance is untenable.
I agree with @Duncan_Innes, if the user is not in place, setting the remote_execution_ssh_user is useless anyway.
In our environment, a common user to login to all hosts is not allowed. Therefore the same job which is ran by different administrator will require to use their own ssh account.
the current work around is to change remote_execution_ssh_user to his/her own user name, in every time who wants to run a job. But if there are 2 or more people want to run jobs at the same time, it will have conflict.
