[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