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