The State Tool has a secret management solution built in for managing any confidential values required by your coding project.

Setting secrets

To define a secret you use the command line tool, not the activestate.yaml. This is because secrets live on the ActiveState Platform (in client-side encrypted format – we do not have access to the real values) and not in your local configuration file. We’ll want to use the state secrets command to define a new secret:

state secrets set project.secret-name secret-value

This will create a secret named secret-name with the value secret-value that will be shared with everyone who has permissions for the project.

If, instead, you want to define a secret that only you have access to, you need to define a user secret by specifying user.secret-name:

state secrets set user.secret-name secret-value

This will still define the secret for everyone with permissions for project, but only you will have access to the value you’ve set. Anyone else that uses this secret will be prompted for their own value.

Retrieving secrets

Now that we have a secret defined we can start using it. To view secrets that exist for your current project you can run the state secrets command. This will produce a concise list of secrets, their “scope” (user or project) as well as a usage example (what you would use to set or retrieve their value).

To retrieve the value of a secret run:

state secrets get project.secret-name

This will retrieve the value for a secret called secret-name whose value is shared with everyone in the project.

Using secrets

So we can set and retrieve secrets, what about using them in our activestate.yaml configuration file? This is actually very simple, and similar to how you use constants. Let’s use our “HELLO” constant from before but this time instead of referencing a constant called “LOCATION” we’ll reference a secret with that name instead. This syntax would look as follows:

 - name: HELLO
   value: Hello $secrets.user.LOCATION

What’s happening here is the $secrets. prefix indicates that we want to “expand” our identifier as a secret, and the user.LOCATION bits identify it as a secret named LOCATION stored under the user. This syntax is compatible with the output of the “Usage” column when running state secrets to list your secrets. You can copy and paste that value right after the $secrets. prefix in your activestate.yaml file.

It’s important to note that you do not need to first define the user.LOCATION secret. If a secret does not yet exist you will instead be prompted for its value when you try to access it.