Developers are familiar with using secrets within their code and during development work. Secrets typically take the form of:

  • User credentials
  • API keys
  • Access tokens
  • SSH keys
  • pem files, etc

One of the primary uses of secrets is to secure access to systems, but they’re also used to sign cookies, encrypt data, protect the network, and more. And as organizations move to the cloud, implement microservices-based architectures, and adopt DevOps, the number of secrets a developer needs to work with proliferate.

Problems with Sharing Secrets

While a single developer can manage their own secrets fairly well, sharing secrets between development team members has always been problematic. When confronted with the choice of sharing secrets securely via difficult-to-use tools versus employing a simple, non-secure alternative, developers will often err on the side of ease of use. In fact, there are numerous examples of developers turning to Slack, email, wikis and even Github repos to share their secrets. Unfortunately, all of these easy alternatives ultimately defeat the purpose of creating a secret, namely security. To work around the problem, dev teams have:

  • Kludged together their own in-house solution
  • Deployed open source software, like Hashicorp’s Vault
  • Purchased commercial products, like Thales’ nSheild Hardware Security Module (HSM)

ActiveState’s State Tool

ActiveState is taking a different tack. After all, if a solution is too hard to use, developers are unlikely to use it. But what if sharing secrets was as quick and easy as Slack or email, but far more secure? That’s where the ActiveState Platform CLI, the State Tool, comes in.

Using the State Tool, you can simply issue the following command to create a secret:

state secrets set project.secret-name secret-value

The above command results in a secret named secret-name with an RSA-encrypted value of secret-value that is securely stored on the ActiveState platform, and associated with your project.

If you want to define a secret that isn’t shared (meaning only you have access to it) you can instead define it as a “user” secret with the following command:

state secrets set user.secret-name secret-value

Any team member can view all of the project’s secrets by running the state secrets command. This will produce a concise list of secrets, their “scope” (user or project) as well as a usage example (e.g., what you would use to set or retrieve their value).

To retrieve the value of a specific secret, any team member on your project can issue the following command:

state secrets get project.secret-name

Scripts and Secrets

But secrets by themselves are of limited value. The real value comes from using secrets in scripts. Scripts in the State tool can be compared to scripts in NPM, or build targets in a Makefile. You can define a script and then run it whenever you need to. Let’s start with something simple:

scripts:
 - name: hello
   value: echo Hello World

This will register a script with the alias “hello”. You can run this script at any time with the command state run hello.

Scripts can also use constants. For example, you could instead use the following value:

value: echo $constants.HELLO

This also works for secrets, so instead of the above command you could run echo $secrets.user.HELLO. It gets more interesting though, because the State Tool can treat EVERYTHING as a “variable.” As a result, you could create another command that references our first command:

scripts:
 - name: log-hello
   value: $scripts.hello > /tmp/hello.txt

You can see how, given some thought, this feature could quickly become very powerful. The main use-case for scripts is to kick off builds, run tests, etc, but really the sky’s the limit.

Next Steps

Secrets management is a complex problem. While ActiveState’s State Tool doesn’t address all of the features large enterprise might require, it does go a long way toward enabling Dev teams to incorporate security into their dev practices as simply and easily as just slacking a password. And that’s a big step forward towards improving security practices for all developers.

Want to learn more about the State Tool?