2009/5/6 Ryan Dooley <ryan.doo...@gmail.com>: > > Chad Huneycutt wrote: >> I am not sure everyone is on the same page: >> >> 1. you don't want to have the root password (encrypted or not) showing >> up in the process listing of your clients. > > Well, this is a policy/philosophy issue. The question is "what is an > acceptable risk for your environment?" Is it okay to have the root > password managed by puppet? Should puppet manage any users password? > > If the answer to that question is "puppet should in no way manage a > password" because that password is stored on disk and potentially > displayed in the process list or in a yaml file, then really you've > deleted this thread and moved on :)
I would argue that displaying the password in the process list is in a separate class from having it stored locally on the disk, since even unprivileged users could trivially capture it, which was really my only point. Just good practice to avoid that as there are lots of possible alternatives. > > I absolutely agree there are other and better ways to manage the root > password. Heck disable the root account in its entirety and create a > proper process and policy to grant access if an SA or data center > support individual who might need access. Or build your environment > with enough redundancy so that if a machine begins to fail it is easier > to just completely reinstall instead of diagnosing a dead machine and > never login as root. I really considered this. Why even have a root password? We can reboot into a rescue environment in the worst case. In the end, the most compelling argument for keeping the root password was to be able to do forensics on a live, compromised box without having to reboot (open, academic environment here, so it happens). Convenience (for problems during boot, etc.) came in a close second, though :) >> 2. even if you are generating the password on the master, it is going >> to show up in the yaml on the client, and if that is the case, it >> would seem to me that puppet's "user" type would be a much more >> logical and explicit place to set it. > > Doesn't the users password still exist under the user type params in > localconfig.yaml? Not really that more secure. Indeed. My point was not that it was more secure, just that it was more "logical and explicit". As long as the string is going to be in the yaml anyway, might as well do it the "puppet way". -- Chad M. Huneycutt --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
