Announcing Credential Broker

tl;dr: The utility is open-source, you can download, contribute or learn more on github here.

A credential broker service stores all sensitive information and has a command-line client which can act as a streaming pre-hook to initialize environment variables upon an application at runtime that does not store anything to disk. The broker service itself stores everything in encrypted format with the broker client having a key to unlock the data, provided the user is authenticated and has been authorized for the data requested. The server mimics an SSH authentication using Diffie-Hellman to establish encryption of traffic, performing a challenge to validate a user owns the private OpenPGP key to their account and a 2FA request at a configurable time period to ensure the user hasn't been compromised. SSL should be configured on the server to help prevent man-in the middle.

Users can also be applications. A broker scope itself can be tied to an application such that an app server would use their private PGP key to match with the broker services stored public key to access all the variables stored under that applications scope while starting. Applications don't require two-factor authentication as they're trusted.

# Asks for secret value, hiding the input & then establishes the secret on the specified scope
broker add $scopeName $secretName

# Deletes a secret from specified scope
broker del $scopeName $secretName

# Asks for secret value, hiding the input & then changes a secret on the specified scope
broker mod $scopeName $secretName

# Establish all environment variables based on scope if authentication is successful
broker get $scopeName

Benefits & Reasoning

• Security should be more robust than vaulting or holding data behind a VPN, all without sacrificing speed of access
• Devops shouldn't implicitly have access to all secrets
  • Just because an employee has access to the infrastructure doesn't mean they have a need-to-know. To view access types, you can jump to the types of access section
• You can attach TTL's to secrets if it's mission critical from them to disappear after a certain point
• Just because a user has access to one application doesn't mean they have access to all it's data
  • Data can be scoped to a need-to-know
• No knowledge of a language or configuration structure is required, just a few intuitive commands
• Adding, removing and changing secrets should be faster than unvaulting & editing playbooks
• The responsibility of adding and removing secrets can be managed by organizational structure
  • Just because a developer has access to the secrets to run an application doesn't mean they have access to changing, adding or removing additional secrets
• The system can be used to store non-sensitive information
• There are default strategies in place to ever prevent data loss or access issues when employees leave.
  • For more information on the strategies you can jump to the abandonment section.