Secrets
Store and retrieve sensitive data
Tracecat comes with a build-in secrets manager. This allows you to store and retrieve sensitive data without exposing the value in plaintext. Secrets are encrypted at rest and stored in the database.
Storing secrets
Secrets are scoped to a workspace. To add a secret, navigate to the Credentials page and click on the Create Secret button.
Retrieving secrets in workflows
To get a secret and use it in an action input, use the SECRETS.<secret-name>.<secret-key>
syntax.
Tracecat will automatically replace the expression with the secret value at runtime. Retrieved secrets are deleted from memory after the workflow run completes.
Integrations and secrets
Check out the Integrations page for a list of pre-built integrations and their required secrets.
Pre-built integrations require a specific secret name and required keys.
For example, the VirusTotal integration requires a secret with the name virustotal
and the key VIRUSTOTAL_API_KEY
.
Different integrations may require different required and optional keys. For example, Tracecat’s AWS integration is configured with the following secret with optional keys:
Check out the Quickstart tutorial for a step-by-step example of the concepts discussed above.
Organization-level secrets
Tracecat also supports organization-level secrets that are accessible to all workspaces within an organization. To create an organization-level secret, navigate to the Organization page and click on the Create Secret button.
Multi-tenant secrets
A common use case is to have different sets of the same secret for different tenants or environments. For example, an MDR provider will likely have different Crowdstrike tenant IDs for each customer.
Use Tracecat’s secrets manager and child workflows to create and retrieve multi-tenant secrets.
Example: Multi-account AWS integration
Create a multi-tenant secret
Create a multi-tenant secret for an integration by specifying the environment key.
The secret name and keys (e.g. aws
and AWS_ROLE_ARN
) remain the same.
If no environment key is specified, the environment key defaults to default
.
Trigger environment-specific child workflow
Let’s assume you have a child workflow that retrieves GuardDuty detector IDs for a specific AWS account.
You have multiple sets of AWS_ROLE_ARN
, one for each account:
arn:aws:iam::{account_id}:role/ListGuardDutyDetectors
Given a list of AWS account IDs configured in the parent workflow’s static inputs,
select the Execute Child Workflow
action and configure it with the following inputs: