Project:Infrastructure/Secrets v2

= 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 GPG-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 GPG 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 GPG keys, non-automated
 * EG: The LiveDVD release process uses the non-automated GPG 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 NOT require being run on a Cloud
 * MUST NOT depend on any non-open components (eg AWS KMS)
 * Disconnected/offline operation NOT required.

Threat Modeling
TODO

Known Software

 * Hashicorp Vault
 * Includes a comparison to other software: https://www.vaultproject.io/intro/vs/index.html
 * Square KeyWhiz
 * Amazon KMS
 * pass
 * Author is Gentoo dev [User: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