Vault secrets management for Cyral in a Nomad-automated environment

Modified on: Mon, 26 Jul, 2021 at 7:22 PM

Role of Vault in a Cyral deployment

You can configure Cyral to use HashiCorp Vault to store sensitive credentials and certificates. The types of information that Cyral can read from a Vault store include:

Repository credentials for SSO mappings. The Cyral authenticator service accepts these as per-repo JSON objects in the format {"repo1":["creds-repo1"]}
Certificate chain, server certificate, and private key for mTLS. The Cyral interceptor service supports mutual TLS (mTLS) authentication and relies on Vault to store the required certificates and keys.
Certificate chain, client certificate, and private key for Filebeat. The Cyral sidecar relies on a utility called Filebeat to send log information to Logstash. In this configuration, you can choose to enable TLS and optionally mutual TLS to secure the connection.

Prerequisites

Note! In this document, we assume Cyral will authenticate to Vault using appRole. These instructions assume you have a Nomad instance running and also have the appropriate permissions to manage jobs inside it. If you do not have one, you can create an instance following this guide.

Before you begin integrating Vault into your Cyral deployment, have the following ready:

A Vault instance that Cyral can connect to, and administrator access to this Vault instance.
Authentication credentials for Cyral's account in your Vault instance. Cyral supports using AWS, Kubernetes, or app role authentication for connecting to Vault.
AppRole ID and the associated secret ID for generating Vault access tokens.
Optional: The payload you plan to store in Vault. For example:
- for database credentials, make sure you have the usernames and the passwords for the database accounts.

Add Vault Integration in Cyral Management Console

In the Integrations page of the Cyral Management Console, find the Vault tile, click Setup, click New Integration, and provide the Vault server connectivity and authentication scheme details. In the screenshot below, we show an example configuration:

Note that in the above example, the Vault server is using an app role, and the following blob specifies that. The base path /approle is defined in the Nomad template for the sidecar as a shared volume between the cyral_vault_wrapper Nomad task and the host machine running Nomad.

Vault integration payload:

method "approle" {

mount_path = "auth/approle"

config {

role_id_file_path = "/approle/role.txt"

secret_id_file_path = "/approle/secret.txt"

remove_secret_id_file_after_reading = false

}

You must set the remove_secret_id_file_after_reading value to false in the above configuration, as the sidecar needs to have continuous access to the secret id. The role.txt file contains only the role ID retrieved from Vault. The secret.txt file contains only the associated secret ID, also retrieved from Vault.

Volume definition in the Nomad sidecar template:

task "cyral_vault_wrapper" {

driver = "docker"

volumes = [

# Disclaimer: the following path is relative to the Nomad allocation path

# in the computing instance. You may instead replace it by

# absolute paths like "/tmp/approle/:/approle".

"./cyral/vault/approle/:/approle"

]

}

Generate a custom sidecar

To get the sidecar template from the Cyral management console, use the custom template option. Go to Sidecars, click the "+" button, click Deploying a sidecar using a custom template, and click Generate.

Use the provided sidecar ID to populate the SIDECAR_ID environment variable used by the Nomad template. Do the same with the provided clientID and clientSecret values, using them to populate the SIDECAR_CLIENT_ID and SIDECAR_CLIENT_SECRET settings, respectively.

Add database credentials to KV V2 secrets engine

The following example shows adding a single credential set using Vault command line utility. Note that the secret name can be anything, but it is advisable to organize it so that it can be extended to include more repos and credentials.

vault kv put /cyral/dbsecrets/patientdata/analyst username=analyst

vault kv patch /cyral/dbsecrets/patientdata/analyst password=STRONGPASSWORD

# Optional, database name you want users connected to upon login

vault kv patch /cyral/dbsecrets/patientdata/analyst databaseName=finance

Add local accounts and identity maps

In the Cyral management console, edit each repo (in the Data Repos: your repo: Local Accounts tab), and add a local account entry that points to the secret you created above. In the Identity to Account Map tab, create an identity map to associate an SSO group with a local account.

Below is an example screen shot after adding a local account for user “analyst”.

The Dynamic username checkbox must be checked when using the Vault database secrets engine with dynamic credentials (username + password).

Below is an example identity map showing the association between SSO group “Data Analysts” and local account “analyst”