Configs & Secrets Stores

CTO.ai Configs and Secrets Stores provide a centralized location for managing environment variables used for configuring your cloud-native applications. The basic functionality of a Secrets Store is largely the same as what you’ll find offered by our Configs Stores—with a few minor differences intended to keep sensitive configuration values stored securely.

This feature is provided to enable to you follow the principles for building a Twelve-Factor App, where your application behavior is configured through environment variables made available in the application’s runtime environment.

When a new key-value pair is added to either your Configs Store or Secrets Store, that value can be included in the ops.yml definition of a workflow to make the Configs or Secrets key-value pair available in the workflow’s runtime environment as an environment variable.

Centralized Workflow Configuration

By moving configuration values away from the individual ops.yml files defining your Commands, Pipelines, and Services workflows and into a centralized location, you can share configuration data across workflows and ensure that your configuration method is implemented consistently between applications. Moreover, your developers won’t need to keep track of common configurations values that may be updated frequently as your application’s architecture matures—setting a key-value pair once in your Configs or Secrets Store makes it accessible to every workflow on the team.

Securing Sensitive Configuration Details

Additionally, using a Secrets Store helps keep sensitive information secure by reducing the number of opportunities for leakage of secure data to occur in the first place.

For example, if a workflow run via our Slack App integration prompted the user for passwords or other sensitive configuration information, that data would also be sent to Slack’s servers—any information entered into the Slack UI is stored by Slack! Likewise, if a workflow expects sensitive details to be passed via command line arguments, that data will be automatically stored in each user’s shell history.

By storing sensitive configuration details in a Secrets Store directly accessed by your workflows, there is significantly less opportunity for data leakage to even occur, forming the first layer of your defense-in-depth security strategy.

Chaining Workflows via Configuration

Beyond the configuration variables you might manually set to manage the behavior of your workflows, you can also build workflows that add or modify existing variables in your Configs and Secrets Stores. This capability makes it possible to chain workflows together which use your Configs or Secrets Store to share configuration information.

Example: Provisioning and Management Workflows

Manually creating a configuration for each engineer’s development environment would be a tedious process prone to errors. However, you would expect the process to be similar each time and each development environment usually only needs to be configured once, making this situation a perfect candidate for automation!

One way to approach this might be to build a workflow that provisions new development environments by interactively prompting for configuration values when it is first run. That workflow would then save the relevant configuration details for the development environment in the team’s Configs or Secrets Stores, as appropriate.

After the development environment has been provisioned, other workflows designed to interact with that environment can be created by the operations engineers on your team to allow your developers to create deployments, scale services, access logs, etc. These management workflows can then access the configuration values set by the provisioning workflow, eliminating the need to pass static variables to those workflows at run time.

Secrets Store Security Restrictions

There are two characteristics that distinguish Secrets Stores from Configs Stores:

• All values in a Secrets Store are processed as string values; it is not possible to set values in the form of a JSON object.
• All values in a Secrets Store are write-only via the Dashboard and CLI; they can only be read by workflows which are explicitly given access to those values via ops.yml definition.

The distinction between these features is most evident on the Dashboard, where the values of your Secrets are entirely hidden from view in the Secrets list, preventing leakage of sensitive information:

This is also apparent if you click on a Secret’s key or the edit button to the left side of its row, where the Edit Secret screen presents a blank text box to set a new value for the Secret, but the current value is hidden: