Secrets

Your credentials are sensitive, this is how you configure them and how we handle them.

Secrets are often required in a workspace for some of the following use cases:

• Service Level Indicator codebundles interacting with a system that requires authn/authz

  • e.g. quering metrics from datadog, sysdig, prometheus, AWS, GCP, Kubernetes, databases and so on.

• TaskSets interacting with a system that requires authn/authz

  • e.g. Gathering logs, creating reports, querying multiple component statuses, notifying chat systems, restarting system components, configuring systems, and so on.

• Interacting with the RunWhen API

  • e.g. Querying the status of a dependent SLX, creating composite SLIs, configuring the workspace through the SLI

Adding & Updating Workspace Secrets

Secrets are managed at the workspace configuration level and are available to be used by SLI or TaskSet codebundles that require secrets. Secrets can be written and overwritten from the RunWhen UI, however, they cannot be read.

Secrets are added in a simple key:value pair, with the key representing the name that SLI and TaskSet codebundles will reference. The value will be a string that represents whatever data the codebundles requires - this could be yaml (e.g. kubeconfig), json (e.g. http headers or service account credentials) or simply a string (such as a username or password).

In order to update a secret, simply add a secret with the same name and the value will update.

Secrets can also be added from the SLI or TaskSet configuration window as well. When a codebundle requires a secret, simply start typing the name of a new secret and click "Add". The RunWhen UI will prompt you for the secret values.

How RunWhen Manages Secrets

The RunWhen platform utilizes HashiCorp Vault to store and retrieve workspace secrets. Using HashiCorp Vault Policies, the core RunWhen components are permitted to create, update and list secrets for a given workspace, but are not permitted to read the secret content.

Example HashiCorop Vault Policy for RunWhen components:

# Allow writing and updating of secrets to the locations endpoint
path "workspaces/data/*" {
  capabilities = ["create", "update"]
}

# Support listing of secrets of a workspace
path "workspaces/metadata/*" {
  capabilities = [ "list" ]
}

When platform users configure a Service Level Indicator or TaskSet codebundle, they select a RunWhen Location in which that service will operate. This task will "authorize" the location workspace to read the necessary secret contents such that the SLI and/or TaskSet can function properly. In this way, only the SLI or TaskSet code has the permissions to read sensitive secrets for its workspace in order to perform the necessary tasks and the main RunWhen platform components can not read workspace secret contents (meaning that you cannot retrieve secret contents from the RunWhen API).

Example HashiCorp Vault Policy for Location SLI/TaskSets:

# Per workspace policy.
path "workspaces/data/{{location_workspace}}/*" {
  capabilities = [ "read" ]
}

# Support listing of secrets of a workspace
path "workspaces/metadata/{{location_workspace}}/*" {
  capabilities = [ "list" ]
}

Workflow Secrets

Workflow chat tokens/webhooks are not stored as secrets

Workflow configuration currently supports integration with messaging platforms that might require a webook or bot token. This information is currently visible to workspace users and stored in the database (rather than Vault), as the RunWhen platform components must read this content during workflow execution. Other sensitive secrets needed for TaskSet execution are still stored in Vault and scoped to the location TaskSet. This design may be refactored in the future based on customer input.