This is Gentoo's testing wiki. It is a non-operational environment and its textual content is outdated.

Please visit our production wiki at https://wiki.gentoo.org

Project:Infrastructure/Secrets v2

From Gentoo Wiki (test)
Jump to:navigation Jump to:search

Infrastructure: Secret storage v2

The Infrastructure team and the foundation trustees have need of a secure means to store and use "secrets".

From the Vault documentation:

A secret is anything that you want to tightly control access to, such as API keys, passwords, certificates, and more.

v1: what we have now

What we have now is a set of OpenPGP-encrypted files, using pwstore, pass or manual equivilents, possibly stored in version-controlled repositories.

This does not provide any audit trail for access or usage of secrets, and allows anybody in the set to change the secret

Examples of Secrets

  • Server root passwords
    • Needs regular rotation, easy to automate
    • Generally valid for any single infra member to GET secret
    • May be shared with a sponsor during the process of debugging system problems (eg hardware failure), should be rotated thereafter
  • Credentials to Sponsor support systems
    • Rotation requires manual intervention (lots of custom web UIs)
  • Service SSL keys
    • Rotation has knock-on implications, manual preferred
    • Should be fetched by systems, not humans
  • Service/Process OpenPGP keys, automated
    • Eg: Weekly automated stages, rsync Metamanifest, Tree snapshot for websync
    • Rotation requires changing external software & long-timeframe
    • Used for signing but not encryption, consider signing-as-a-service usage
  • Service/Process OpenPGP keys, non-automated
    • EG: The LiveDVD release process uses the non-automated OpenPGP key, also used for older non-automated releases.
    • Rotation requires changing external software & long-timeframe
    • Used for signing but not encryption, consider signing-as-a-service usage
  • Cloud services: service/role/user keys
    • Normal usage keys for AWS, Rackspace, OpenStack
  • Cloud services: master keys
    • Special usage keys for AWS, Rackspace, OpenStack
    • Should be possible to require multi-party agreement to access the secret (eg 2 infra members)
  • Backup Keys
    • Should be easy to get a public key to encrypt to
    • Decryption may require multi-party agreement (SSSS)

Requirements & anti-requirements

  • MUST be open-source
  • MUST allow difference access levels / assignments of secrets to users/groups
  • MUST NOT require being run on a Cloud
  • MUST NOT depend on any non-open components (eg AWS KMS)
  • Disconnected/offline operation NOT required.

Nice to have features

  • SSSS of individual secrets (very hard to implement within the system, consider doing it as an overlay)

Threat modeling

TODO

Known software