Host password management in foreman (random passwords)

Currently i have to define the (root) password for a host. After this it is not possible anymore to see the password in the UI (or i have not found it yet).

I am missing a option to create a host with a random password and the possibility to read the (root) password of a host.

In my believe it’s bad practice to use the same password. Have the option to random generate it would improve that part. The downside is that you have to make the password accessible.

Maybe this is a bit part of taste. But i was wondering if this is already possible in foreman.

I believe @ananace’s plugin is intended to solve this but I have no personal experience with it.

Well, Foreman itself never stores any un-hashed passwords anywhere, except for the global setting. In fact the code ensures that any password written to database is done so in a hashed form.

My plugin is designed then to let an external password manager - in our case passwordstate - completely take over the generation and the storage of all those root/admin passwords, leaving Foreman with only API access to query the passwords as necessary.
The same design should work for other password storage systems as well, possibly even with Foreman itself doing the storage by using facets with encrypted fields - though I don’t really like the security implications of that.

Thanks for your insight ananace. Ill have a look at the plugin. Too bad passwordstate is not open source :smiley:

@ananace, I’m going to have to seriously look at your plugin. My client uses PasswordState, and I have a Perl script that uses the REST API to manage periodic password change requirements (400 hosts in a couple of minutes.)

I’m not familiar with Ruby, etc. Is all of the plugin administration controlled through Administration/Settings?

The plugin currently adds a a Passwordstate Server object that controls the links to passwordstate itself. Those objects do all the authentication and orchestration work - still lacking proper taxonomy support on them though as that part was a bit broken on our then 1.16 install, and I haven’t had time to redo those parts yet after our major upgrade.
The server object currently doesn’t support filtering out password lists either, so if you’re using the winapi to access it then I definitely recommend using a service-specific user that can only access the password lists you want Foreman to manage.
It’s probably also best to only let Foreman manage passwords in there, as I’m using a suffixed string to denote which passwords are part of which host, to let me search them out without requiring dedicating specific custom values for Foreman - nor requiring the use of the hosts module.

The only other thing the plugin adds apart from passwordstate servers is a field on hosts where you can select a passwordstate server for the host, and if one is chosen then the root password field is replaced with a password list selection. That’s all the configuration it has.

It also includes a new tab on all hosts that shows a list of passwords managed for said host, as well as ENC data that indicates that the host is managed by passwordstate - which we’re using to automatically apply root password changes.

Feel free to throw me a message on IRC (I’m in the foreman rooms as ananace), an issue on GitHub, or an email if you want help to test it out.

Hrrrm. One of the things I’ve been sort of wanting to solve for years has been random password creation on kickstart. After the fact, I have a mandatory 30 day change requirement. So, unless this plugin can accommodate that 2nd requirement, I may be better off continuing with what I have.

More analysis…

Well, the plugin leaves literally all the password handling up to Passwordstate, so if you set up automatic password rotation on there then that will also apply to Foreman - and through ENC optionally also to every managed host.
Additionally, the plugin currently generates new passwords on every host rebuild, due to being linked to the build events.

While PasswordState is usable in a lot of cases (not necessarily the manner by which I’m required to use it, but I digress,) I’ve ran into enough goofy behavior that I’m leery about a lot of the automatic activity.

TBD.

Can’t you just randomize the host password in a (kickstart) template? If a password is set to default value, then overwrite it with a random one:

if @host.root_pass == "$5$fMlvUgvTYC2nWFU6$kSZaBpRwhmQv76kTjSIlrpRrh1Zfafn0YrVkIYupkDB"
  pass = SecureRandom.base64
  @host.root_pass = pass
  @host.comment = "Root pass is: #{pass}"
  @host.save!
[10] pry(main)* end  

Granted this is probably bad idea and terrible thing to do, but in your OP you ask to “possibility to read the password” which is also a bad idea. Foreman never stores root password in clear or even encrypted form, the moment the value is saved a hash is created according to the Operating System root pasword policy value. The global setting must be also set to salted hash, so Foreman is not a good data source for this.

You could however create some password policy generation based off hostname + salt -> hash that could be used. Then you only need to know one “master” salt token to generate root password on the fly. You could do this in a template too.

I like they way of placing the password in the comment field (i did not think about the option to save it in the kickstart script). Thanks!
I do understand that in most cases this is not recommended. But the password will be changed anyway.

When would the update be executed (and could it override another password/executed multiple times)?

After a second look i guess the compare check is to prevent this.

1 Like

Yes, that was the idea to set some “default” password that would be overwritten. You will probably need to turn off safemode in order to call some methods which are not allowed by default, e.g. SecureRandom.