[tahoe-lafs-trac-stream] [Tahoe-LAFS] #4177: Manage shared secrets required to interact with the infrastructure

[Tahoe-LAFS]

#4177: Manage shared secrets required to interact with the infrastructure
------------------------------------+-----------------------
     Reporter:  btlogy              |      Owner:
         Type:  enhancement         |     Status:  new
     Priority:  normal              |  Milestone:  undecided
    Component:  dev-infrastructure  |    Version:  n/a
   Resolution:                      |   Keywords:
Launchpad Bug:                      |
------------------------------------+-----------------------
Description changed by btlogy:

Old description:

> ==== 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 [https://github.com/tahoe-lafs/infrastructure
> 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 [https://www.passwordstore.org/ 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
> (e.g. breaking CI when an individual key expires)
> - Mitigate bus-factor to make the community more resilient and flexible -
> see
>
> ==== 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.

New description:

 ==== 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 [https://github.com/tahoe-lafs/infrastructure
 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 [https://www.passwordstore.org/ 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.

--

--
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/4177#comment:2>
Tahoe-LAFS <https://Tahoe-LAFS.org>
secure decentralized storage