Link Search Menu Expand Document
Start for Free

Secrets Integration

This chapter discusses secrets management and how to use it.

Page Contents
  1. Overview
    1. Supported Integrations
    2. Configuration

Overview

Secret management software allows users to securely store sensitive data such as passwords, keys and tokens in a central location with strict access controls. Secret managers can set secrets to expire, be auto-generated and, in case of a security breach, be revoked. This functionality enales Stardog administrators to secure their server and database passwords outside of Stardog and manager them without any modifications to your Stardog configuration.

Supported Integrations

Stardog Knowledge Catalog integrates with the following secret managers to store usernames and password for catalog metadata providers:

  • Hashicorp Vault

  • AWS Secrets Managwr

  • Azure Key Vault

  • Google Secret Manager

Stardog currently supports secrets stored as a single string value for a password or a serialized JSON object with username and password attributes. Data sources that are configured to use a secret manager will read in the secret values at runtime.

Configuration

You can configure data sources to use a secrets manager and retrieve username and password values for your connections. By excluding the jdbc.username and jdbc.password parameters and instead adding a secrets configuration, the jdbc username and password parameters will be added automatically at runtime.

You can also use the variables {username} and {password} in connection strings or any other configuration strings where you usually have a username and password and they will be replaced with the stored username and password.

To use a secret with a Data Source you add the appropriate set of properties for the secret manager you are using.

Property Description
secrets.manager The name of the secrets manager to use
secrets.key The key or path or other code used by a secrets manager to identity a unique secret
secrets.version The version of a secret for secret managers that support multiple versions of the same secret key
secrets.aws.manager The AWS region where the AWS Secrets Manager is running
secrets.aws.secret.key Required AWS secret key
secrets.aws.access.key Required AWS access key
secrets.google.project.id Required Google project id
secrets.google.key Required Google access key
secrets.azure.url The URL for the Azure Key Vault application
secrets.azure.tenant.id Required Azure tenant id
secrets.azure.client.id Required Azure client id
secrets.azure.client.secret Required Azure client secret
secrets.hashicorp.vault.url The URL for a Vault server
secrets.hashicorp.vault.token Required Vault access token

Different secret managers require different sets of properties.

Vault:

  • secrets.manager = “vault”
  • secrets.key = key
  • secrets.hashicorp.vault.url = vault url
  • secrets.hashicorp.vault.token = access token

AWS:

  • secrets.manager = “aws”
  • secrets.key = ARN of secret
  • secrets.aws.access.key = client access key
  • secrets.aws.secret.key = client secret key
  • secrets.aws.manager = AWS region code

Azure:

  • secrets.manager = “azure”
  • secrets.key = id of secret
  • secrets.version = version of secret
  • secrets.azure.url = key vault url
  • secrets.azure.tenant.id = azure tenant id
  • secrets.azure.client.id = azure client id
  • secrets.azure.client.secret = azure client secret

Google:

  • secrets.manager = “google”
  • secrets.google.project.id = google project id
  • secrets.google.key = google api key

Here is an example configuration for a MySql data source that uses Hashicorp Vault to store the database credentials:

jdbc.url=jdbc:mysql://yourhost.com:3306/yourdb?allowMultiQueries=true&useSSL=false&serverTimezone=Etc/GMT-8
jdbc.driver=com.mysql.cj.jdbc.Driver
parser.sql.quoting=ANSI

secrets.manager=vault
secrets.hashicorp.vault.url=http://yourhost.com:8200/v1
secrets.key=secret/data/mysql-user-json
secrets.hashicorp.vault.token=***********