4 ms·
Installing secrets on disk exposes them to potential leakage through backups. This is a major issue, since much less attention is typically paid to access manag
by kgilpin 12y ago
Installing secrets on disk exposes them to potential leakage through backups. This is a major issue, since much less attention is typically paid to access management for backups than to production servers. Therefore I support the approach of providing secrets through the environment.
Once an application has been written to get its secrets from the environment, there is a question of how the secrets are obtained. They can be sourced from a file in an init script, but today we are seeing a lot of momentum towards containerized architecture, and the use of service discovery and configuration systems like etcd, zookeeper and consul.
However, secrets require much more attention to security concerns than the data that these tools are designed to handle. Least privilege, separation of duties, encryption, and comprehensive audit are all necessary when dealing with secrets material. To this end, we have written a dedicated product which provides management and access for secrets and other infrastructure resources (e.g. SSH, LDAP, HTTP web services). The deployment model is similar to the HA systems provided by etcd, consul, SaltStack, etc. It's called Conjur (conjur.net).
- mreinsch 12y agoThis is indeed an issue, though with a modern cloud based infrastructure and management systems there is no longer a need to create backups from your production servers. They can be automatically recreated and no important data is stored on them.
- kgilpin 12y agoYes, thanks for this observation. Although inevitably, some "pets" remain...
- mreinsch 12y agoThis is indeed an issue, though with a modern cloud based infrastructure and management systems there is no longer a need to create backups from your production servers. They can be automatically recreated and no important data is stored on them.
- switch007 12y agoLooks interesting. However, isn't the conjur API key stored in .netrc just another secret that can be easily leaked? On the distribution as a virtual appliance: is it a black box? How do I back it up? How do I upgrade it? How do I check the integrity of the secrets database?
- kgilpin 12y agoRegarding the API key, from an operational perspective it's an improvement. The reason is it creates a separation of duties between management of the API key (responsibility of opsec), and the application credentials (responsibility of the broader ops team and in some cases the developers themselves). There is no way for the application credentials to be accidentally leaked or mis-deployed, because the policies created by opsec are always enforced. In addition, the security team can make decisions about the management of the API key, such as: * It can be kept off physical media (e.g.in /dev/shm) * The process(es) by which the API keys are created and placed on the machines can be carefully managed * A dedicated reaper/deprovisioner process can be used to retire (de-authorize) API keys once they go out of service. Regarding the virtual appliance: * Is it a black box? Essentially yes, although there are specific maintenance scripts on the machine (e.g. backup / restore) that you may occasionally run. For normal operation, only ports 443 and 636 (LDAPS) are open. * How do I back it up? A standby master and read-only followers can be used to keep live copies of the database. A backup script can be used to capture full GPG-encrypted backups. A restore script will restore a backup onto a new appliance. * How do I upgrade it? You create a standby master and followers of the new upgraded version of the appliance, and connect them to your current master. Once the standby master and followers are current with the data stream, they are promoted via DNS and serve the subsequent requests. * How do I check the integrity of the secrets database? We have written an open-source Ruby interface to OpenSSL called Slosilo (https://github.com/conjurinc/slosilo https://github.com/conjurinc/slosilo) and subjected this library to a professional crypto audit. On the advice of the auditors, Slosilo encryption employs message authentication (cipher mode AES-256-GCM) which ensures the integrity of the secrets. Nevertheless, the Conjur appliances must obviously be afforded the highest level of protection. Unlike a multi-master system, Conjur's read-only "followers" contain only read-only copies of the secrets. So compromise of a follower cannot be used to modify secrets or authorization policies, or to confuse a master election scheme.
- switch007 12y agoLooks interesting. However, isn't the conjur API key stored in .netrc just another secret that can be easily leaked? On the distribution as a virtual appliance: is it a black box? How do I back it up? How do I upgrade it? How do I check the integrity of the secrets database?
- mreinsch 12y agoThis is indeed an issue, though with a modern cloud based infrastructure and management systems there is no longer a need to create backups from your production servers. They can be automatically recreated and no important data is stored on them.