[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-bugs] #32914 [Internal Services/Tor Sysadmin Team]: review the puppet bootstrapping process

#32914: review the puppet bootstrapping process
-------------------------------------------------+-------------------------
 Reporter:  anarcat                              |          Owner:  anarcat
     Type:  task                                 |         Status:
                                                 |  accepted
 Priority:  Medium                               |      Milestone:
Component:  Internal Services/Tor Sysadmin Team  |        Version:
 Severity:  Minor                                |     Resolution:
 Keywords:                                       |  Actual Points:
Parent ID:  #31239                               |         Points:
 Reviewer:                                       |        Sponsor:
-------------------------------------------------+-------------------------
Changes (by anarcat):

 * status:  assigned => accepted


Comment:

 i looked here and there. i found a "bootstrap" bolt script here:

 https://forge.puppet.com/puppetlabs/bootstrap

 but that requires bolt, and from what i understand, it's just this awful
 `curl | bash` shell scripts that sucks in something from the central
 puppetmaster:

 https://github.com/puppetlabs/puppetlabs-
 bootstrap/blob/master/tasks/linux.sh

 so not really useful.

 there's something called "autosigning" in Puppet, which tells the puppet
 master to just sign the new nodes automatically:

 https://puppet.com/docs/puppet/latest/ssl_autosign.html

 some people do Naive autosigning in development, but manually verify new
 nodes before signing them. it's basically what we do: the copy-paste
 script we have does that, somehow.

 a possible improvement on that is "policy autosigning" where the
 puppetmaster delegates to an external program the task of verifying the
 certificate. the external program gets the CSR and succeeds or fails the
 verification. presumably the CSR could include some magic secret that the
 master could verify, but i don't see how this could be used by us.

 i think the best way to improve the script would be two-fold:

  1. include the Puppetmaster CA in the install process
  2. install the Puppet package in the install process
  3. add a tpa-puppet-node-add script that takes a sha256 as an argument
 (or prompt) and signs it after verification on the master
  4. configure puppet to configure itself to run as a cron job instead of a
 daemon (instead of doing this by hand during the install)

 This has a few implications:

  * the puppetmaster is a special snowflake that needs manual
 reconfiguration of the install process when rebuilt from scratch (already
 the case)
  * no manual step is required on the new nodes to configure Puppet, as the
 CA is setup automatically during install
  * Puppet first runs as a daemon, but then needs to configure itself to
 run as a cron job (or timer) - this is done that way so that we don't have
 to run puppet by hand during the install
  * the install process *must* communicate the checksum of the agent cert
 reliably and securely as part of the install process

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/32914#comment:1>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online

_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs