Skip to main content
Secrets store the cloud provider credentials that DataRaven uses to access your storage locations. Every location references a secret, and DataRaven supports two storage modes to fit your security requirements.

Native Vault

Enter credentials directly. Stored encrypted in AWS SSM Parameter Store (SecureString). Simple, secure, zero configuration.

External Vault (BYOV)

Map credential fields to references in 1Password, Doppler, or Infisical. Credentials resolved at execution time and immediately discarded.

​
Supported Providers

Each cloud storage provider requires specific credential fields. DataRaven auto-selects the auth method when you choose a provider — except Azure, which offers two options. Each provider’s page covers how to obtain the credentials and any scoping quirks.

​
Creating a Secret

Store credentials directly in DataRaven’s encrypted vault. Best for teams that don’t use an external secrets manager.
1

Choose your provider

Select the cloud storage provider. The auth method is auto-selected (Azure lets you choose between SAS URL and account key).
2

Enter credentials

Fill in the required credential fields for your provider. These are encrypted and stored in AWS SSM Parameter Store.
3

Name and save

Give the secret a descriptive name (e.g., “Production AWS” or “Staging GCS”) and save.
You cannot provide both credentials and vault_connection_id on the same secret. Choose one storage mode — native vault or external vault — per secret.

​
Validation Rules

DataRaven validates secrets on creation and update:
  • auth_method must be valid for the chosen secret_type
  • field_mappings must cover all required fields for the auth method (partial mappings are rejected)
  • credentials and vault_connection_id are mutually exclusive

​
Updating & Rotating Secrets

Edit a secret to rotate the credentials
You cannot switch a secret between native vault and external vault after creation. A native secret always uses credentials, and a BYOV secret always uses field_mappings.
Changing secret_type on an existing secret triggers validation against all linked locations to ensure compatibility.

​
Secret Lifecycle

Secrets are referenced by Locations, which are referenced by Tasks. This creates a dependency chain:
1

Create a secret

Store credentials for a cloud provider using either storage mode.
2

Link to a location

When creating a storage location, select the secret that holds credentials for that provider.
3

Use in tasks

Tasks reference locations. At execution time, DataRaven resolves the secret’s credentials to access the storage.
4

Deletion protection

A secret cannot be deleted while it’s in use by one or more locations. You’ll receive a 409 Conflict error. Unlink or delete the dependent locations first.
The secret detail view shows all linked locations and tasks, along with creation metadata.

​
Security

Never exposed

Credentials are never returned in any API response — not on read, not on list, not on update confirmation.

Encrypted at rest

Native vault credentials are stored as AWS SSM Parameter Store SecureString parameters, encrypted with AWS KMS.

In-memory only

External vault credentials are resolved in-memory at execution time and immediately discarded after the operation completes.

Audit logged

All secret operations — creation, updates, deletions, and runtime resolutions — are logged for audit purposes.

​
Provider Tips

Provider-specific credential guidance — which console issues the keys, scoping quirks like Fil One’s region-scoped keys or Fastly’s full-access requirement, and what belongs in the secret versus the location — lives in the Credentials section of each provider’s page.

​
Tier Limits

Need more? Upgrade your plan from the billing page.