As part of an ongoing series, we’re taking a deep dive into the structure, use, and benefits of various crypto tools for devops.
Four of the biggest challenges facing any project development team are caching, sharing passwords, and off-by-one errors. While today’s post won’t address all these, sharing credentials is a challenge we particularly care about and want to make easier.
Credstash uses Amazon’s KMS platform to generate encryption keys on demand for secrets that need to be stored. When you add a item to Credstash, it generates a unique encryption key (itself encrypted with a general master key) for that item. The system then uses this encryption key to encrypt the item and stores it, along with its redundantly-encrypted key, in Amazon DynamoDB for later retrieval.
The advantage of using Amazon is that you can leverage the platform’s Identity and Access Management (IAM) system to control access. Individual developers can be granted access on a case-by-case access. Individual deployment environments can be issued individual credentials to access both KMS and DynamoDB.
Credstash also permits the versioning of credentials within the system. Since credentials can be retrieved independently, this versioning mechanism provides an efficient way to share updates with disparate parties when changes need to be made.
DevOps Use Case
Most applications need access to some form of sensitive information when running in production. How exactly to retrieve that information is a contested point of debate among many developers. Getting developers to agree that application configuration belongs in the environment is relatively easy. Getting that configuration into the environment is relatively difficult.
Credstash can make this easier by integrating directly with tools like Ansible while provisioning environments:
- Engineers provision credentials locally and store them in Credstash
- Credstash encrypts the credentials (thanks to KMS) and stores them online
- Engineers then use a lookup in an Ansible playbook to pull data back out of Credstash while setting up the environment
Ansible can pass these credentials into the runtime environment for use while:
- Generating configuration files
- Configuring the runtime environment for scalable systems like Amazon Elastic Beanstalk
- Setting up secrets in container orchestration tools like Rancher
The Good and the Bad
Credstash is a fantastic tool that allows sharing secrets (passwords, credentials, and keys) both between developers and servers and among development teams. If you manage multiple Amazon accounts, you can also configure multiple profiles and segregate secrets in different accounts or regions. This is incredibly useful when working with more than one client from a single machine.
The biggest downside in working with Credstash presents itself when actually building an environment. If a production server has access to Credstash to dynamically read data, it can potentially also write data (and overwrite credentials). Managing atomic permissions, using IAM roles and policy rules, is possible. It’s just very involved and, if done poorly, can compromise the security of your system.
Our best approach is to give a protected, dedicated build server access to Credstash. That server then configures a Rancher environment via the API; credentials on the exposed, production server are never written statically to disk. It’s a workaround, but allows us to leverage the power of Ansible for building a server, the Rancher API for configuring and orchestrating a production cloud, and Credstash for protecting secrets every step of the way.
While we want to illustrate the utility of the tool, its documentation goes into much greater detail about the construction and use of the system.
Credstash integrates well with Fugue’s cloud management system, letting you programmatically define your entire infrastructure and mange your secrets in one place. Both the open source tool and the infrastructure as a service platform are built by the same team.
Next week, we’ll move beyond Credstash to a tool that can encrypt and share secrets independent of a third party database (i.e. no KMS/DynamoDB integration): Git-crypt.