re Feature #3272: Separate internal admin account from user admin accounts - Foreman
I'm looking at issues around the default "admin" account that currently
gets added automatically by migratons/User model etc and want to get
some thoughts on how this should work. Today the account is used for
internal processes (like report uploads), by users and it can't be
deleted or disabled.
The main features I want out of rewriting this are:
- all internal actions to happen under an account that isn't used by a
real user so the auditing can't be confused
- a more secure out-of-the-box setup both from packages and the
installer, either without a well-known password or at least being forced
to change it immediately
- allow the first admin account to be replaced by a user's own account
- OAuth API still to work when user mapping is off, either via the
internal account or an anonymous API user account
(1) and (3) are relatively easy, but I'm undecided about how to set up
the first user account (2).
For background, I looked through docs for various RH products to see how
others tackle it. Usually it was an interactive prompt during
installation and optionally an answers file. One stored a token in a
file which was used with a CLI tool to set up the first account and
another had auth only via Apache so the admin could use htpasswd to
create an account. Katello's installer required either a command line
argument or the password to be in the answers file, which created the
user via the DB seed.
Another approach I saw in gluster-deploy was for the command line tool
to print out an access key, which the user could copy + paste into their
browser to get into a first-time setup wizard in the UI. While I like
this, a non-interactive CLI alternative would be required - same if say,
we were to keep a default password and force the user to change it on
first login.
What I'm thinking so far is:
- create the first user via the installer, either via a foreman_api
resource (like the proxy) or DB seeding, but expose the user + pass as
class parameters
- add support to kafo to prompt for the password even in
non-interactive mode if it's not specified (via args or answer file)
- optionally add an argument to foreman-installer to randomise the
password instead and print it out after install
- update rake permissions:reset to do what it does now but with a
random password
- if the installer used DB seeding, we could have the seed script
randomly generate a password and print/store it somewhere for the user
to retrieve if the installer wasn't used (i.e. package/source installs),
else the reset rake task would have to be used I think
Some other thoughts/alternatives:
- we enable hammer to use OAuth rather than account details so users can
create the first account via "hammer user create" out of the box
- DB seeding would be slightly more reliable than an installer API-based
resource in our experience, but I dislike coupling of the installer +
seed script with shared data
Thoughts?
···
--
Dominic Cleal
Red Hat Engineering
Mostly I think I agree with this however:
- add support to kafo to prompt for the password even in
> non-interactive mode if it's not specified (via args or answer file)
> 3. optionally add an argument to foreman-installer to randomise the
> password instead and print it out after install
>
(2) isn't Kafo's job, IMO - it's a library to interact with Puppet modules.
The correct place for this is in the foreman-installer binary, ensuring the
option is set (or prompting for it) before executing Kafo. This may
require patches to Kafo to allow proper pre-execution introspction of the
class parameters, but that's a useful feature for any Kafo-based installer.
In general, though, I'd drop (2) and always do (3). So long as the password
is clearly displayed for end users, and displayed and/or stored in a
format/place consumable by test deployment tools, then I think we're fine.
Adding prompts is extra work I don't think we need.
Tangent-based-on-(5): Could we enchance rake permissions:reset to create an
account if one does not exist, and then use that everywhere? The packages
could call it and print the result, ditto the installer (after the puppet
run, in the foreman-installer binary). That would save you changing the
puppet modules at all…
Greg
Hi,
> 2. a more secure out-of-the-box setup both from packages and the
> installer, either without a well-known password or at least being forced
> to change it immediately
It might be useful to have this feature in general, where an admin
can check a box to force a user to change their password on first
login.
> 3. optionally add an argument to foreman-installer to randomise the
> password instead and print it out after install
I would say the default is generate a random password, and setting
the change password on first login flag I mentioned above.
Ideally the installer should spit out at the end the random
password AND a link to get started right away.
Foreman is installed, and a default administrator has
been created:
User: admin
Password: kk24t8b84
Click here to get started:
https://<fqdn>/?first=kk24t8b84
And of course clicking that link takes you to the change password
screen.
If a user specifies a password in the answer file, then probably
shouldn't do any of the above.
···
On Dec 11, 2013, at 3:31 PM, Dominic Cleal wrote:
–
Stephen Benjamin
stephen@bitbin.de
> Mostly I think I agree with this however:
>
> 2. add support to kafo to prompt for the password even in
> non-interactive mode if it's not specified (via args or answer file)
> 3. optionally add an argument to foreman-installer to randomise the
> password instead and print it out after install
>
>
> (2) isn't Kafo's job, IMO - it's a library to interact with Puppet
> modules. The correct place for this is in the foreman-installer binary,
> ensuring the option is set (or prompting for it) before executing Kafo.
> This may require patches to Kafo to allow proper pre-execution
> introspction of the class parameters, but that's a useful feature for
> any Kafo-based installer.
Sure, ok.
> In general, though, I'd drop (2) and always do (3). So long as the
> password is clearly displayed for end users, and displayed and/or stored
> in a format/place consumable by test deployment tools, then I think
> we're fine. Adding prompts is extra work I don't think we need.
(where "2" was password prompting and "3" was add a randomise argument)
I would like to keep an option for users to enter a password of their
own, and even better if we can keep it from being persisted on disk (via
an answers file or shell history).
> Tangent-based-on-(5): Could we enchance rake permissions:reset to create
> an account if one does not exist, and then use that everywhere? The
> packages could call it and print the result, ditto the installer (after
> the puppet run, in the foreman-installer binary). That would save you
> changing the puppet modules at all…
I think it'd be a shame if the modules couldn't complete this very last
step to make a usable Foreman install, I'd rather not move this logic
into the external script.
···
On 11/12/13 14:51, Greg Sutcliffe wrote:
–
Dominic Cleal
Red Hat Engineering
Ok, thanks for the feedback all; this seems to be the consensus. I'll
get started.
Dominic Cleal
Red Hat Engineering
···
On 11/12/13 15:19, Stephen Benjamin wrote:
> Hi,
>
>
> On Dec 11, 2013, at 3:31 PM, Dominic Cleal > wrote:
>
>> 2. a more secure out-of-the-box setup both from packages and the
>> installer, either without a well-known password or at least being
>> forced to change it immediately
>
> It might be useful to have this feature in general, where an admin
> can check a box to force a user to change their password on first
> login.
>
>> 3. optionally add an argument to foreman-installer to randomise
>> the password instead and print it out after install
>
> I would say the default is generate a random password, and setting
> the change password on first login flag I mentioned above.
>
> Ideally the installer should spit out at the end the random
> password AND a link to get started right away.
>
> Foreman is installed, and a default administrator has been
> created:
>
> User: admin Password: kk24t8b84
>
> Click here to get started:
>
> https:///?first=kk24t8b84
>
> And of course clicking that link takes you to the change password
> screen.
>
> If a user specifies a password in the answer file, then probably
> shouldn't do any of the above.
>> Mostly I think I agree with this however:
>>
>> 2. add support to kafo to prompt for the password even in
>> non-interactive mode if it's not specified (via args or answer file)
>> 3. optionally add an argument to foreman-installer to randomise the
>> password instead and print it out after install
>>
>>
>> (2) isn't Kafo's job, IMO - it's a library to interact with Puppet
>> modules. The correct place for this is in the foreman-installer binary,
>> ensuring the option is set (or prompting for it) before executing Kafo.
>> This may require patches to Kafo to allow proper pre-execution
>> introspction of the class parameters, but that's a useful feature for
>> any Kafo-based installer.
>
> Sure, ok.
>
>> In general, though, I'd drop (2) and always do (3). So long as the
>> password is clearly displayed for end users, and displayed and/or stored
>> in a format/place consumable by test deployment tools, then I think
>> we're fine. Adding prompts is extra work I don't think we need.
>
> (where "2" was password prompting and "3" was add a randomise argument)
>
> I would like to keep an option for users to enter a password of their
> own, and even better if we can keep it from being persisted on disk (via
> an answers file or shell history).
>
+1 to being able to enter and not have to interpret it after the fact is
much easier on the end user as well as automation. We have this now in
katello-configure and I'd greatly prefer it if we didn't regress and
lose this ability.
I don't think we need the prompt if not specified, I'm fine with "if
password not specified then randomize" but we should have the ability to
set it to a specific value.
>> Tangent-based-on-(5): Could we enchance rake permissions:reset to create
>> an account if one does not exist, and then use that everywhere? The
>> packages could call it and print the result, ditto the installer (after
>> the puppet run, in the foreman-installer binary). That would save you
>> changing the puppet modules at all…
>
> I think it'd be a shame if the modules couldn't complete this very last
> step to make a usable Foreman install, I'd rather not move this logic
> into the external script.
>
seems like a good goal to have the modules be re-usable as much as
possible outside the scope of the external script.
Mike
···
On 12/11/2013 07:07 AM, Dominic Cleal wrote:
> On 11/12/13 14:51, Greg Sutcliffe wrote:
--
Mike McCune
mmccune AT redhat.com
Red Hat Engineering | Portland, OR
Systems Management | 650-254-4248
Some thoughts:
We could enhance existing kafo password system [1]. Although I'm against
prompting in non-interactive mode if you find it necessary we could make kafo
asking for every parameter that is type:password. Note that even without this
prompt user can set his password by specifying as installer parameters (stored
in .$SHELL_history), in answer file or via interactive mode so I don't a reason
to add 4th way just for passwords…
Hopefully we'll have some kind of answer file generator in future where user
can easily enter password. Also when someone (who understands all puppet class
parameters) will separate parameters into groups, interactive mode becomes
more usable and password configuration can remain in some top-level menu.
Obvious disadvantage of kafo password mechanism is that it's not working
without kafo module. However kafo puppet module should be usable without kafo
gem.
From user perspective I think generating random passwords, printing them on
STDOUT with force to change after first login as Stephen suggested is the best
way. User still can preset password in wizard mode or by answer file easily.
Using kafo password mechanism, it doesn't have to be stored as plaintext in
answer file.
[1] https://github.com/theforeman/kafo#password-arguments
···
On Wednesday 11 of December 2013 15:07:52 Dominic Cleal wrote:
> On 11/12/13 14:51, Greg Sutcliffe wrote:
> > Mostly I think I agree with this however:
> > 2. add support to kafo to prompt for the password even in
> > non-interactive mode if it's not specified (via args or answer file)
> > 3. optionally add an argument to foreman-installer to randomise the
> > password instead and print it out after install
> >
> > (2) isn't Kafo's job, IMO - it's a library to interact with Puppet
> > modules. The correct place for this is in the foreman-installer binary,
> > ensuring the option is set (or prompting for it) before executing Kafo.
> > This *may* require patches to Kafo to allow proper pre-execution
> > introspction of the class parameters, but that's a useful feature for
> > any Kafo-based installer.
>
> Sure, ok.
>
> > In general, though, I'd drop (2) and always do (3). So long as the
> > password is clearly displayed for end users, and displayed and/or stored
> > in a format/place consumable by test deployment tools, then I think
> > we're fine. Adding prompts is extra work I don't think we need.
>
> (where "2" was password prompting and "3" was add a randomise argument)
>
> I would like to keep an option for users to enter a password of their
> own, and even better if we can keep it from being persisted on disk (via
> an answers file or shell history).
–
Marek
Tangent-based-on-(5): Could we enchance rake permissions:reset to create
an account if one does not exist, and then use that everywhere? The
packages could call it and print the result, ditto the installer (after
the puppet run, in the foreman-installer binary). That would save you
changing the puppet modules at all…
I think it’d be a shame if the modules couldn’t complete this very last
step to make a usable Foreman install, I’d rather not move this logic
into the external script.
