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

Tor Bug Tracker & Wiki blackhole at torproject.org
Mon Feb 10 21:58:28 UTC 2020


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

 * status:  accepted => needs_review


Comment:

 I have deployed changes in the wiki, tsa-misc and Puppet to improve on
 this.

 The gist of the changes are as follows:

  1. there are now two scripts, one for the client, one for the master,
 which need to be called at about the same time and do approximately what
 we were doing in the wiki before, except...
  2. instead of copy-pasting commands from the master to the client, we
 only need to copy-paste the checksum from the client to the master, the
 remaining commands are hardcoded in the client script
  3. we assume the client cert doesn't need to be copy-pasted from the
 server back to the client
  4. we inject the Puppet CA *before* we run puppet, which reduces our
 exposure to MITM attacks

 Now, regarding our concerns:

 > the puppetmaster is a special snowflake that needs manual
 reconfiguration of the install process when rebuilt from scratch (already
 the case)

 That's still the case. The Puppetmaster CA is valid until 2039 so we're
 good for 20 years with this setup. We explicitly warn about expiry in the
 install script as well, although that warning might eventually get lost in
 the future of course...

 > no manual step is required on the new nodes to configure Puppet, as the
 CA is setup automatically during install

 that is *mostly* the case with the caveat that we do "--waitforcert" on
 the client which might hang the installer for two minutes of the operator
 doesn't approve the certificate fast enough.

 >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

 i believe i have fixed that by masking the puppet service before
 installing the package, but this requires testing.

 > the install process *must* communicate the checksum of the agent cert
 reliably and securely as part of the install process

 this is still the case, and assumes the operator is interacting with both
 the puppet client and server during the install. the idea here is that
 this *could* eventually be automated by an operator using Ansible or
 Fabric or some external orchestration that can talk to both the client and
 puppetmaster at the same time.

 i haven't figured out how to use autosigning meaningfully. it seems the
 puppetmaster-side script is simple enough to be easier to maintain than an
 autosigning hook. and it's deployed through puppet so that should also be
 maintainable in the future.

 next step is to test this on the next new server we create.

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


More information about the tor-bugs mailing list