About Secrets
Secrets for use in bricks need to be centralized, bricks run and scale in a dynamic, cloud-agnostic environment with frequently changing machines and network addresses. In order to achieve centralized control over our secrets we maintain a Vault cluster, secrets can be managed from the Portal without exposing their contents.
When creating a new secret, it is recommend to use downscoped/permissioned credentials tailored to the specific task it intends to solve.
Why store Secrets in Vault?#
When running a Raven Flow, some bricks may require a credential parameter to be set. Many source-pull bricks require some kind of authentication in order to access the data it needs.
By making use of Vault, you can make a secret available to your entire team, while keeping the credential data secure and easily manageable.
Long-lived static secrets are hard to manage long term and pose a risk to most organizations. We try to alleviate this concern by having some secret types be created dynamically. This means that Vault will distribute a secret with limited validity. Raven renews dynamic secrets while its bricks require them. Dynamic secrets get recreated constantly as Raven starts and stops bricks periodically. For secrets that are not dynamic, a warning is displayed when the credential value remains unchanged for too long.
What happens with a Secret?#
The concept is simple. You create a secret and we hide it, even from you. After creating the secret you can no longer see what is inside it. You may alter the secrets name or description and set a new credential value. Bricks will automatically be updated to use the new secret containing the updated credential.
Using a Secret#
When a brick parameter is in need of a secret it contains a secret-select in the config window containing all available secrets. Select the secret for the brick and finish the brick's configuration.
Some Secrets only apply for something specific like a region. Make sure when creating a secret this specification is mentioned in the name or description of the secret to avoid confusion.
Secret types#
The current available secret types are:
BASIC, Basic Authentication#
| Key | Label |
|---|---|
| USERNAME | "Username" |
| PASSWORD | "Password" |
oauth2client, OAuth 2.0 client credentials#
| Key | Label |
|---|---|
| OAUTH2_CLIENT_ID | "Client Id" |
| OAUTH2_CLIENT_SECRET" | "Client Secret" |
AWS, Amazon Webservices#
| Key | Label |
|---|---|
| AWS_ACCESS_KEY_ID | "Access Key" |
| AWS_SECRET_ACCESS_KEY | "Secret Access Key" |
APIKEY, Api KEY#
| Key | Label |
|---|---|
| API_KEY | "Key" |
Google, Google Service Account#
| Key | Label |
|---|---|
| GOOGLE_SERVICE_ACCOUNT_JSON | "Private Key (json)" |
Azure, Azure#
| Key | Label |
|---|---|
| AZURE_TENANT_ID | "Tenant Id" |
| AZURE_CLIENT_ID | "Client Id" |
| AZURE_CLIENT_SECRET | "Client Secret" |
ConnectionString#
| Key | Label |
|---|---|
| CONNECTION_STRING | "Connection String" |