Manage shared secrets required to interact with the infrastructure

[btlogy]

Scope

While it is preferable to avoid them wherever possible, some recent changes have been highlighting a common need: sometime, shared secrets are required to integrate with some 3rd party services (e.g. GH deploy SSH key for CircleCI or API token for Upptime).

More specifically:

• #4162: requires a dedicated Hetzner account (not an org.) to manage the DNS zone.
• #4175: requires a GH Personal Access Token which is tight to a single GH user account (not an org.)!

Like any account, those shared accounts should be protected with 2FA/MFA, likely a TOTP, which makes it more difficult to share in the first place.

SOPS (implemented in the ​infrastructure repository) already offers a solution to share some secrets (especially those consumed by the managed systems). But it lacks support for TOTP.

Today, such secrets are either treated as individual ones and not actually shared, or shared by means that are not formalized (e.g. 1Password).

This issue propose to:

• add (Docker and Nix?) support for ​pass with OTP extension,
• store the shared secrets in a new repository (public or internal?),
• use the relevant PGP keys to encrypt them.

The first step would be limited to the secrets related to the recent changes worked on by Least Authority (e.g. GitHub, Hetzner and Forgejo).

If working, the solution could be extended to cover other services described in #4142.

Value

• Avoid dependency on single member for feature used by the community
• Mitigate bus-factor to make the community more resilient and flexible

Requirements

• A group of contributors with push permissions and identified by their PGP key, should be able to MAC encrypted credentials (usernames, passwords, OTPs, ...);
• Any contributor with read permissions would be able to list the credentials and see some metadata and which group is sharing it.

[btlogy]

I've managed to make pass work using nix-shell or docker-compose run --rm pass on Vantaa (with a bit of agent forward-plumb-ing):

• ​https://github.com/tahoe-lafs/infrastructure-pass

Verifying with Flo if this works for him too...

[btlogy]

Similarly to this new ​infrastructure-pass repository, I've also added a nix-shell support for SOPS (Secret OperationS) in the ​infrastructure (as code) repository (see ​infrastructure#76

Which will allow admins to use the same PGP keys in both repository:

• with sops to share the (self-hosted) "machines" secrets with other admins in ​infrastructure (e.g. ssh private key to upload backups to BorgBase)
• with pass to share the (3rd parties) "providers" secrets with other admins in ​infrastructure-pass (e.g. password and totp for xxx-tahoe b users on GitHub)

[btlogy]

So far, whole those secrets are encrypted for 4 separated PGP entities (all using hardware tokens):

• btlogy/Ben
• hacklschorsch/Flo
• LeastAuthority (last resort key a)
• LeastAuthority (last resort key c)

We will ask the community who else should be involved in our next mailing.

[btlogy]

In addition to the bus factor concern described above, we might also consider to create a dedicated ​mailing-list to replace the current tahoe@… email used is many shared credentials (e.g. tahoe-adm).