James Cammarata wrote:
So, an idea occurred to me the other night for a possible feature
that I
think is a must-have: secure encrypted storage of password fields,
specifically the one used for power management.
My original idea, is for a new set of commands: "cobbler lock/unlock".
This would set a stored password in cobblerd that would be used for
encrypting/decrypting fields. The basis for this idea is the ssh-agent
functionality, where an admin unlocks a key for use allowing non-admins to
use it. Basically, after starting up cobblerd, an admin with privilege
would have to type in the password to make things work correctly.
An alternate idea proposed by Rob Lazzurs is to use public/private crypto
(namely gpg), but for additional security an unlock command would still be
needed to give a pass phrase to unlock the private key to cobblerd. In
this use case, people could still manage objects, but cobbler would not be
able to execute some actions until the pass phrase for the private key was
entered.
Whichever method we used, it would be transparent for users of cobbler,
which would still be controlled via the ownership and ACLs methodology.
The burden would be on the admin to make sure cobblerd was unlocked
Having this secure storage feature would also allow for the use of
per-system and per-profile root passwords to be stored, which would be
extremely useful and a killer feature I think.
Thoughts?
This would be interesting. Mainly it would be useful to me in that we
wouldn't be surfacing that information over the (public) API.
Speaking of passwords for root access in kickstart though, this
information is also exposed in the kickstart templates (once rendered).
This however could be solved by clever Apache and/or iptables
configuration (you're on your own to set this up), in which case they
would only be surfaced to the proper networks.
It would also probably be nice to be able to enter this information in
plaintext rather than to have to copy/paste the crypted info. (Securely
store the plaintext as something else, decode it, render it crypted for
good measure?)
I don't really want to see this done as a set of extra commands though.
Ultimately maybe this is because I see the security interest in being
able to protect that information from the XMLRPC API, and that the rest
can be controlled reasonably well with file permissions and limiting
access to the web application.
--Michael