A Better Way to Deploy Secrets to the Cloud

James Bowes
manifoldco
Published in
4 min readNov 30, 2016

At Manifold, we’ve been building Torus to help everyone easily and securely share their secrets among team members and deployments.

The traditional ways of shipping secrets (API keys, database passwords, etc) from the fingers of a human all the way to your production systems are either bad or complex.

The bad ways, such as checking your secrets into source control, can result in severe consequences. The complex solutions are more secure but they require specialized knowledge (of the software and cryptography) as well as dedicated infrastructure to operate them, and yet they still don’t solve the whole problem.

Our latest release is the first step towards solving a problem you’re all too familiar with:

Managing application secrets in production environments.

Machines

Wherever our applications are deployed they need access to secrets but giving them the same access as users doesn’t follow the principle of least privilege.

Machines not exactly as illustrated.

A machine, under the hood, is a special class of user that can only perform read operations on secrets which they have explicitly been given access to.

Starting with zero access you are able grant fine-grained access to only the secrets that your application requires, instead of exposing all of your configuration.

There are three main steps to using Torus machines:

  1. Create a machine and assign it a role
  2. Grant read access to your machine’s role
  3. Add your machine token id and secret to your instance

Install Torus and begin experimenting with machines using our newly expanded documentation, or read on for a detailed getting started guide.

Getting Started

Install Torus using our RPM or deb packages

We’re shipping all new releases of Torus in RPM and deb packages with a SystemD service definition which is tailored for use with Machines. Our RPMs are built targeting RHEL/CentOS 7 and Fedora 24+, though they should work on any recent RPM-based Linux distribution. Our debs are built for Ubuntu 16.04+ and Debian 8.

You can find installation instructions for your Linux flavour of choice in our install page

Create a machine using your user account

On your local machine (with Torus installed) you can create a new machine using the torus machines create command.

You will be asked to provide a role name (e.g api), and a unique name.

$ torus machines create
✔ Org name: very-important
✔ Create a new role: api-servers
✔ Enter machine name: api-servers-rkzwcxe1
Machine role api-servers created for org very-important.Creating machine “api-servers-rkzwcxe1”Generating machine token
Generating token keypairs
Uploading token keypairs
Creating keyring memberships for token
Uploading keyring memberships
Machine created
You will only be shown the secret once, please keep it safe.Machine ID: 04bgp2qpv0c3fdx54uu7w16c6y7dg
Machine Token ID: 04 — — — — — — — — — — — yk4
Machine Token Secret: FVtV — — — — — — — -6hoP

Deploy the token ID and Secret to your machine

The output from the torus machines create command includes a Token ID and Token Secret. The token secret is the randomly generated private portion of an asymmetric key, used to authenticated the machine. Make sure not to lose it!

Place the token ID and Secret in the established /etc/torus/token.environment file.

Configure Torus to start on system boot, and start it

We need to configure Torus to run on system boot, and manually start it for the first time. You can do this using systemctl:

sudo systemctl enable torus.service
sudo systemctl start torus

At startup the Torus service will log in using the token you’ve configured.

Run your application

To securely operate your application with Torus you will need do two things.

You need to run your application with a user in the torus group. This ensures that your application processes can securely communicate with the Torus daemon.

You also need to set the TORUS_ROOT environment variable to /var/run/torus. This enables the Torus CLI to communicate with the daemon through the daemon’s socket.

Your application will have access to the decrypted secrets it needs through the daemon’s exposed socket, but not to the token credentials used to decrypt the secrets.

Through this, should your application be compromised, a nefarious party won’t be able to access the credentials used to communicate with Torus.

Interested in a free t-shirt and stickers?

Artist rendition of free swag

Fill out our feedback survey about your infrastructure and current config management practices and we’ll send you a limited edition Torus Beta t-shirt along with some stickers.

We’d also love to have your input on machines as they grow.
Join us on GitHub and share your thoughts and experiences.

--

--

James Bowes
manifoldco

Principal Architect at Snyk. literal cat herder.