The State Tool has a secret management solution built in for managing any confidential values required by your coding project.
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
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.
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.
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:
constants: - 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
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.