Database accounts

To give users access to a repository, you will map SSO users and SSO groups to database accounts that you've registered with Cyral.

A database account is a user account on your repository, DBaaS, or DBMS. When an SSO user attempts to connect to your repository through the Cyral sidecar, Cyral relies on that SSO user's mapped database account to authenticate with the underlying repository, such as a PostgreSQL database.

To register a database account in Cyral, follow the steps below. Later you will map each database account to the SSO users who will use it.

Register a database account

Prerequisite

Each database account must have its credentials stored as a secret in your secrets manager. See the tabs below for help storing secrets.

The credentials secret for a database account must contain:

• the username — the database user account name as stored in the repository system, like a PostgreSQL username, for example. Don't worry about the SSO user or group names now; you'll map those later in the Cyral UI.
• the password — the database user's password used for direct authentication to the repository system

Procedure

1. In the Cyral control plane UI, click Data Repos in the left navigation bar, click the name of your repository, and click the User Authentication tab.

2. Click Register Database Account

3. In the Database Account Username field, enter the name of the database account (for example, a PostgreSQL username) that will be used to connect. Click Next.

4. Click the button that corresponds to your secrets storage type and click Next. For instructions, see the tab for your sercrets manager below:

AWS Secrets Manager

If you have the ARN of your database credentials secret, paste it into the ARN field and click Create.

If you need to create a credentials secret, follow the instructions below.

Store the local account credentials as a JSON blob in AWS Secrets Manager. The secret's name must start with the prefix /cyral/dbsecrets/, which will become part of its ARN.

The JSON blob must follow one of the formats shown below. Cyral supports:

• a single set of credentials (username/password) for one database, or
• a list of credentials for multiple databases, where each set of credentials is identified for each database

For singular database accounts, store the local account credentials in the JSON format shown below.

{
  "username": "someuser",
  "password": "somepassword",
  "databaseName": "db1"
}

Note that databaseName is optional for singular credentials.

For multiple database accounts, store the local account credentials in the following JSON format:

[
  {
    "username": "someuser",
    "password": "somepassword",
    "databaseName": "db1"
  },
  {
    "username": "someuser",
    "password": "anotherpassword",
    "databaseName": "db2"
  }
]

Note that for multiple database accounts, databaseName is required so the sidecar can identify which database the credentials belong to.

See the AWS Secrets Manager tutorial for help storing secrets.

Kubernetes Secrets

If you have the Secret Name and Kay Name of your database credentials secret, paste it into the Secret Name and Key Name fields and click Create.

If you need to create a credentials secret, follow the instructions below.

Store the local account credentials as a JSON blob in Kubernetes Secrets. Use one of the formats shown below.

You must create the secret in the same Kubernetes namespace where the sidecar is deployed.

Cyral supports secrets that contain:

• a single set of credentials (username/password) for one database, or
• a list of credentials for multiple databases, where each set of credentials is identified for each database

For singular database accounts, store the local account credentials in the JSON format shown below.

{
  "username": "someuser",
  "password": "somepassword",
  "databaseName": "db1"
}

Note that databaseName is optional for singular credentials.

For multiple database accounts, store the local account credentials in the following JSON format:

[
  {
    "username": "someuser",
    "password": "somepassword",
    "databaseName": "db1"
  },
  {
    "username": "someuser",
    "password": "anotherpassword",
    "databaseName": "db2"
  }
]

Note that for multiple database accounts, databaseName is required so the sidecar can identify which database the credentials belong to.

You must create the database local account secret in Kubernetes before you add it to a data repository in Cyral. You can add the secret using various Kubernetes interface tools (see their documentation on creating secrets).

For example, using kubectl, you can create a secret named db-secrets with the credentials stored in the secret data key as follows:

kubectl create secret generic db-secrets \
  --from-literal=secret='{
  "username": "someuser",
  "password": "somepassword",
  "databaseName": "db1"
}'

Additionally, the sidecar will require sufficient permissions within Kubernetes itself to read secrets using the Kubernetes API. The Cyral sidecar Helm chart creates and uses a Kubernetes service account with sufficient permissions by default, and if you are using that, there are no actions required. This advice only applies if you are using your own (pre-created, in this documentation's terms) service account. For details, see the section, Deploy sidecar with a pre-created service account.

GCP Secret Manager

If you have the Secret Name of your database credentials secret, paste it into the Secret Name field and click Create.

If you need to create a credentials secret, follow the instructions below.

Store the local account credentials as a JSON blob in Google Cloud Secret Manager. Use one of the formats shown below. Cyral supports secrets that contain:

• a single set of credentials (username/password) for one database, or
• a list of credentials for multiple databases, where each set of credentials is identified for each database

For singular database accounts, store the local account credentials in the JSON format shown below.

{
  "username": "someuser",
  "password": "somepassword",
  "databaseName": "db1"
}

Note that databaseName is optional for singular credentials.

For multiple database accounts, store the local account credentials in the following JSON format:

[
  {
    "username": "someuser",
    "password": "somepassword",
    "databaseName": "db1"
  },
  {
    "username": "someuser",
    "password": "anotherpassword",
    "databaseName": "db2"
  }
]

Note that for multiple database accounts, databaseName is required so the sidecar can identify which database the credentials belong to.

You must create the database local account secret in Google Cloud Secret Manager before you add it to a data repository in Cyral. You can add a secret as explained in the Google Cloud documentation).

Environment variable

If you have the variable name of your database credentials secret, paste it into the Variable Name field and click Create.

If you need to create a credentials secret, follow the instructions below.

Store the local account credentials as an environment variable on the sidecar host. Create the environment variable on your sidecar host and configure the sidecar to fetch the environment variable.

Note:

• The variable name must start with the prefix CYRAL_DBSECRETS_
• The contents of the variable must be formatted as a JSON blob as shown in the examples below. You can use:
  • a single set of credentials (username/password) for one database, or
  • a list of credentials for multiple databases, where each set of credentials is identified for each database

For singular database accounts, store the local account credentials in the JSON format shown below. You must create the secret in the same Kubernetes namespace where the sidecar is deployed.

{
  "username": "someuser",
  "password": "somepassword",
  "databaseName": "db1"
}

Note that databaseName is optional for singular credentials.

For multiple database accounts, store the local account credentials in the following JSON format:

[
  {
    "username": "someuser",
    "password": "somepassword",
    "databaseName": "db1"
  },
  {
    "username": "someuser",
    "password": "anotherpassword",
    "databaseName": "db2"
  }
]

Note that for multiple database accounts, databaseName is required so the sidecar can identify which database the credentials belong to.

Cyral recommends that you specify a unique environment variable for each local account in the repo.

Hashicorp Vault

Specify the Secret Path of the HashiCorp Vault secret that stores your database credentials.

If you're using dynamic usernames in your Vault secrets store for this repository's credentials, click Username is dynamic.

Click Create.

AWS IAM

Specify the ARN for the IAM role of the repository user and click Create. This is the ARN of the IAM role that will connect to the repository. Make sure the role has access to your database or other repository.

Next step

Now that you've saved your database account, you can map it to the SSO users who will use it. To do this, make sure your database account name is selected in the Database Accounts list of the User Authentication tab, and click Add Rule. For instructions, see the next section, Access rules for users and groups.