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.