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

Infra has a secrets repo with git + pass that we use to manage secrets.

This does not provide any audit trail for access or usage of secrets, and allows anybody in the set to change the secret (albeit with a git audit trail.)

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 ( Jason A. Donenfeld (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
• sops
  • Open Source (by Mozilla)
  • allows different access/key groups
  • uses Shamir's Secret Sharing to split the data key
  • supports AWS KMS, GCP KMS, Azure Key Vault and PGP
  • can run completely without any KMS using only PGP
  • inspired by hiera-eyaml, credstash , sneaker and password store
  • supports auditing (access logs)