This is Gentoo's testing wiki. It is a non-operational environment and its textual content is outdated.
Please visit our production wiki at -{R
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
- 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