Project:Infrastructure/Secrets v2

From Gentoo Wiki
Jump to: navigation, 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

  • PassBolt
    • Open Source
    • Still in early development
  • Hashicorp Vault
  • Square KeyWhiz
  • Amazon KMS
  • pass
    • Author is Gentoo dev (zx2c4 )
    • Offline operation
    • No audit trail of access
    • No SSSS of secrets
    • No ACL granularity
  • pwstore
    • Used internally by Debian
    • Offline operation
    • No audit trail of access
    • No SSSS of secrets
    • ACLs by group, with signed ACLs to prevent attacker introduction
  • syspass
    • ACLs
    • No SSSS of secrets (global master password)
    • Online only
    • No access logs (only change logs)
  • Confidant
    • AWS-specific
  • secretary
    • Both AWS & local options
    • Need to review audit trail