Issue #7244 has been updated by Daniel Pittman.
> Issue #7244 has been updated by Jeff McCune. > >> Nigel Kersten wrote: >> >> Given the API access around all the SSL infrastructure we’ve added, is there >> any way you can use that instead? >> >> It looks to me that what you really want is to be able to get your certs >> signed and deployed as part of the provisioning process via API calls rather >> than this intermediate token. > > Yes, I think there’s a bit of confusion here though. Talking with lots of > different people about this, I’d like to propose framing the problem in the > following way: > > A certificate signing request itself should be authenticated. I think we’re > all on the same page here. Where a lot of contention comes in is on the > question of the certname itself being sufficient authentication or not. > > I propose the answer is no. The certname itself is not sufficient > authentication because it requires some action to be carried out either on > the Puppet Master or on the Puppet Agent to massage the certname into an > “authenticated” pattern. Correct me if I am wrong, but wouldn't setting the additional "token" also require some action to be taken on the Agent and/or the Master to "massage the token into an 'authenticated' pattern"? > The goal we should be striving for is that new systems can come online > without any human interaction with the system at large in an authenticated > manner. For the certname to be the authenticator, complex machinery would > need to be added to replace the human interaction. > > I think a simple string passed along with (but not inside) the CSR in the > API call combined with a server side system call passing the string in the > argument vector is an easy and robust solution to this problem. I think we would be much better, as a strategy for this, drawing up the proposed security model and giving it a thorough review. I still can't see how this extra token is either less work, or more secure, than using the certname would be. Both are just as verifiable, since they are literally the same data, passed in different places. The only benefit I can see is that the *pair* of values might, in theory, be more secure, *if* you have some out of band key used to secure the token against the certname. ---------------------------------------- Feature #7244: Autosign should allow for an external approver https://projects.puppetlabs.com/issues/7244 Author: Matt Wise Status: Needs More Information Priority: Normal Assignee: Nigel Kersten Category: Target version: 2.7.x Affected Puppet version: Keywords: Branch: Puppet should allow for the autosign code to point to an external script, instead of the autosign.conf file itself for approval in signing a end-clients cert. This method should allow the client to supply a unique bit of "auth" data that is passed to the exec script on the master, and validated. If return 0, sign the code. If not, do not sign. In this way, I can pass an arbitrary "token" (say its 12345) through the puppet agent to the puppet ca master. The puppet ca master can then run "myauthscript.sh -arg 12345". if that script returns 0, puppet c an then sign the certificate. If not, puppet fails to sign the certificate. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
