Aethylred / puppet-keymaster

A Puppet module for generating, deploying, and managing public and private keys/certificates for DSA, RSA, and x509
Other
0 stars 3 forks source link

Defined $user issues #2

Closed esalberg closed 9 years ago

esalberg commented 9 years ago

I had some issues with the following when trying to generate keys for the root user:

if ! defined(User[$user]) { fail("The user '${user}' has not been defined in Puppet") }

I actually do define the root user via Hiera, but the defined call is not picking it up. Interestingly, if I define the user in the manifest, Puppet throws an error about a duplicate definition, so I get stuck between thinking that the user is not defined or is defined too much.

I found a discussion talking about parse order and why defined is best used sparingly: https://groups.google.com/forum/#!topic/puppet-users/AQP92TCnQVo

I'm working on testing out whether switching to require => User[$user] will work as well. Thoughts?

Also, looking in keymaster::openssh::deploy_pair and authorize, I had a related question. Is $user always required for every option here? I saw this one:

} elsif ( $options and $ensure ) { Keymaster::Openssh::Key::Authorized_key <<| tag == $clean_name |>> { ensure => $ensure, options => $options, }

And I could put a require => User[$user] there as well, but if the user isn't required, then that wouldn't be a good idea.

Aethylred commented 9 years ago

You're right, the root user will be a problem. I'd not recommend setting up the root user for remote passwordless login, but using root is sometimes unavoidable. I'll have to have a think about how that's handled. Have you considered using another user and granting them specific sudo privileges to do the thing that needs to be done.

I'm not happy with the use of the defined function in the first bit, so looking at revising that would be a good thing.

The second part the require => User[$user] would not work because this is run on the puppet master where the user may not exist, that user was defined on the node where the virtual Keymaster::Openssh::Key::Authorized_key resource was declared.

I'm working on a few other things at the moment, it'll be a while before I come back to this, but I do have to come and work on the X509 certificates functionality soon.

esalberg commented 9 years ago

I see your point about root - I'm trying to generate a key that will be used with Gitlab / R10k (deploy key), so that's why I'm looking at root at all. I could create a separate user, but I think that kind of defeats the purpose of the deploy key (not having to setup another local user in Gitlab). It's a decent backup option at least.

I'm glad I checked with you, because I forgot about the node/master user discrepancy. There's always documenting that you should make sure if your manifest that the user is declared for the correct server(s), but I agree that it's preferable to validate that if at all possible.

esalberg commented 9 years ago

In lieu of making a new issue - could you clarify which defines should be made where? For example, I have one master setup as a CA, so that would make a good keymaster, and other masters who need to get the new key. I think the following would go in the CA profile (keymaster itself):

include ::keymaster keymaster::openssh::key{'key_name': }

But where does the keymaster::openssh::deploy_pair define go - in the keymaster/CA profile as well, or in the profile for the other masters?

Similarly, would the keymaster::openssh::authorize define go in the keymaster profile or the profile for the node that has the authorized_keys file? For example, what if I have a single server (not the keymaster/CA) whose authorized_keys file should contain the public keys from the other servers?

Aethylred commented 9 years ago

Sorry missed this.

keymaster::openssh::deploy_pair would go to all the nodes where the key is to be deployed. So on the keymaster, and both the other nodes. Which should work reguardless on which node the key itself is defined (and should only be defined on one node).