Announcing SecretHub: helping developers ship safe code faster
Today, we are excited to announce the first public release of SecretHub
v0.13, a tool that helps teams ship safe code faster with a secure, automatic and reproducible secret deployment process.
Before getting to all the juicy features below, it is helpful to first explore the problem we set out to solve almost two years ago.
Secrets slow you down
All software needs secrets to access other resources: database passwords, API tokens, encryption keys. When you deploy software, these application secrets can cause problems for your DevOps teams and your business.
The shorter your software release cycle, the faster your business can react to changing demand.
To ship fast and often, developers need to ship applications and their secrets automatically. Let the machines do the work. This causes a real Catch 22 situation:
- Putting plaintext secrets in automation scripts allows you to move fast, but leaves the business critically exposed.
- Manually deploying secrets is secure, but slows you down.
To protect your business you need to move fast, but to keep it from harm you cannot move fast enough.
The end result? Unhappy DevOps teams bogged down in gruntwork and unhealthy businesses running unnoticed risks.
How many secrets do I have?
Over the past four years, we’ve spoken to hundreds of developers and asked them how they deploy software. These are the results:
In our experience, small teams with around 5 developers and under 25 instances (virtual machines, containers, etc.) tend to have around 100 secrets deployed throughout their production infrastructure.
As applications mature and teams change, this number quickly grows to 500 for medium-sized businesses (around 10 developers and 100 instances) and can reach thousands of secrets for businesses operating larger infrastructures.
Want a more in-depth answer? Drop us a line and we’ll schedule a 15 min phone call for an actionable estimate.
Happy teams and healthy businesses
DevOps teams are happiest when they can automate repetitive tasks. Businesses are healthiest when their operational assets are secure. We’ve built SecretHub to give you both.
Let’s have a look at the challenges of managing secrets and then we’ll show how SecretHub solves these problems.
Designing a secure and usable system
The protection of your deployment hinges on the secrecy of the application secrets that secure it. However, keeping those secrets secret has proven to be complex in an ever-growing application landscape.
Below we’ve defined the underlying challenges that drive the requirements of any secure and automatic secret management tool.
Nobody’s resume reads cryptography wizard
Securely storing and distributing secrets requires in-depth knowledge of cryptography tooling. When teams don’t have an in-house crypto wizard, sharing secrets across a team without exposing the secrets becomes pretty hard.
Throw in a few remote developers or replicate your application across multiple datacenters and you’ve got a mission impossible on your hands.
To empower a team to ship their software independently, any developer should be able to read and write the secrets they need to do their job without requiring any crypto knowledge whatsoever.
Secure must be the shortcut
Server failures do and will happen. When servers go down, the business goes down with it.
In that moment, email, chat, Dropbox or even a good old Excel file is often the fastest way to share a secret. Not a secure way, but one that everyone knows how to use when it really matters.
While people take shortcuts to protect the business to keep serving its customers, it leaves secrets and consequently the business itself critically exposed.
To change people’s reflexes in stressful situations, the ‘right way’ to share a secret must be the fastest and easiest way to do so.
Centralization fights secret sprawl
Secrets tend to sprawl throughout teams and infrastructures in a surprising variety of ways:
- Secrets are jotted down on Post-It notes or taped to the backside of keyboards.
- Secrets are emailed around, shared over Slack, and dropped on shared disks attached to the intranet.
- Secrets are left in home directories, temp folders or backup copies.
- Secrets are inadvertently checked into source control and hardcoded in scripts.
- Secrets are put in configuration management systems and orchestration tooling.
None of these ‘systems’ are designed to securely store, control access to and distribute secret information. A misplaced copy, forgotten file, or improperly erased disk leaves secrets likely to be exposed.
To eliminate sprawl, secrets must be encrypted and stored on a centralized platform that can be standardized across applications and infrastructures. Secrets may never be shared in plaintext and access must be controlled with a strict set of rules.
Access must be logged
When secrets are transferred ‘out-of-band’, sent over text messages or left unmonitored on hard drives, it becomes virtually impossible to say who has had access to what secrets.
Teams need to be able to track down when a secret has been accessed and by whom. Detailed audit logs keep teams informed and help them respond effectively when incidents happen.
Secret rotation should be triggered and enforced
Inevitably, incidents happen and people leave. When they do, access needs to be revoked immediately and all compromised secrets should be rotated, replacing them with a new secret.
However, rotating and redeploying secrets throughout your infrastructure can take hours or even days to accomplish, often causing secrets to be left unchanged for years.
To ensure production infrastructure stays safe when compromises happen, rotating secrets should be centrally enforced and automated as much as possible.
Secret injection must be reproducible across environments
Secrets can be injected into applications in many different ways, as a file, as a field in a configuration file, or as an environment variable. The way these secrets are injected tends to vary wildly between development and production, causing unpredictable bugs creep in.
For instance, many projects contain an
example.config file like this:
database: host: localhost port: 5432 username: "<INSERT_USERNAME_HERE>" password: "<INSERT_PASSWORD_HERE>"
When developing locally, developers fill in their development credentials in this file and run their tests.
To then ship that piece of software, developers typically copy the
example.config to production servers and edit it manually to fill in the blanks.
Over time, the production configuration grows increasingly out of whack with the development configuration. There is no central source of truth on what the configuration should look like because secrets can’t be written in those files.
Not only is manually deploying secrets to machines and editing config files a poor use of a developer’s time, it also creates snowflake servers which are virtually impossible to reproduce. Without a reproducible deployment process, re-creating a server and getting the business back online becomes impossible when the inevitable server failures do occur,
To eliminate those pesky “it worked on my machine!” problems, the way secrets are deployed to machines and injected into applications needs to be the same from development all the way to production.
SecretHub is a secret management and deployment service that is now available for everyone. SecretHub helps teams deploy secrets to any cloud with a secure, automatic and reproducible deployment process.
To help your team ship safe code faster, SecretHub is delivered as-a-Service. SecretHub stores all secrets for you in a client-side encrypted repository and makes them accessible through a Command Line Interface (CLI).
Does your business require an on-premise deployment? Contact us and we’ll schedule a 15 min phone call to see how we can help you solve your problems the fastest.
Let’s walk through the main features and see how they solve the challenges of automating secret distribution securely.
To fight secret sprawl, secrets can be stored securely in a centralized encrypted repository. A typical SecretHub repository looks a little like this:
example/ ├── production/ │ └── api-server/ │ ├── db_password │ ├── db_username │ ├── server.crt │ └── server.key └── testing/ └── api-server/ ├── db_password ├── db_username ├── server.crt └── server.key
To help you organize your secrets in any way you’d like, repositories can have any number of subdirectories to store secrets in. Secrets are versioned and can never be overwritten. This helps people avoid costly mistakes and allows users to perform rolling updates of their infrastructure.
Encryption for everyone
Any developer can read and write the secrets they need to do their job with the SecretHub CLI. No crypto knowledge is required whatsoever. Encryption, logging, and access controls are all built-in under the hood.
Commands feel like their Unix equivalent and complex functions have been reduced to straightforward commands:
# List secrets in a repository secrethub ls john/myrepo # Write a secret and encrypt it for all members secrethub write john/myrepo/db_password # Read and decrypt a secret secrethub read john/myrepo/db_password
Every secret version is individually encrypted for each SecretHub account that has access to it. We’ll publish security documentation soon with full transparency of the cryptography under the hood.
Share secrets faster
Once a secret is written to SecretHub, any members with access to a secret’s directory have instantaneous access to the secret. Secrets can be instantly shared with those team members that need them.
No email, no chat, and no Post-It notes required.
Don’t make me code
Just because you’re a developer it doesn’t mean you want to code to get your problem solved. Whether you run your own cutting-edge creation, third party or even legacy software, SecretHub works out of the box with your stack.
Nearly all software is already compatible with reading secrets from at least one of three methods:
- Reading a secret from a file
- Reading a secret from a field in a config file
- Reading a secret from an environment variable
That’s why SecretHub supports all three methods of injecting secrets into systems.
You don’t have to change your application code to let it read secrets from SecretHub.
Development = Production
SecretHub provides the same, easy workflow to inject secrets into applications regardless of the environment. It leverages a declarative template file which describes all your required secrets and their configured method of injection.
Configuration is codified in a plaintext readable file that can be checked into version control, instantly sharing knowledge throughout the team. This makes secret injection reproducible for everyone in every environment.
Straightforward access rules
SecretHub leverages a very simple centralized access control mechanism: users define access rules on a directory that give
admin permissions on the directory and all of its children.
Directories inherit permissions from their parent directories, so you can provide access both broadly and restricted depending on your needs.
Detailed audit logs
SecretHub ensures secrets are never shared in plaintext and each use is centrally logged. Detailed audit logs with every use of a secret ensure you can prove continuous compliance and help your team respond effectively in a crisis.
Revoking an account’s access happens with just one command which automatically flags all secrets that have ever been read by the account.
This immediately blocks the revoked account from accessing secrets in your repository. To ensure secrets stay secret, all affected secrets must be rotated. To help with that, SecretHub provides an actionable rotation list and support for automatic rotation is under construction.
When incidents happen, SecretHub empowers teams to rotate secrets across multi-cloud infrastructures in minutes.
SecretHub in production
SecretHub has been running in production for over a year now and has secured hundreds of secrets in private beta.
Complex processes are standardized across environments and infrastructures. Configuration is decoupled from secret content, which makes applications more secure and configuration more accessible.
Ultimately, teams end up shipping code faster while it becomes a lot safer under the hood. In time, developers won’t even realize SecretHub is there. It just works.
DevOps teams are happy and the business stays protected. Please check it out and see for yourself.
If you have any questions, reach out to the team and we’ll try to help you as quick as possible.