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 Access Rules 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 only meant to be used when configuring credentials for MongoDB data repositories. This field refers to the authentication database.

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"
  }
]

See the AWS Secrets Manager tutorial for help storing secrets.

Note: sidecars will require sufficient AWS IAM permissions to access any AWS Secrets Manager database account secrets. For example, if the sidecar is running on an EC2 instance, the instance must have the necessary IAM permissions to access the secret in Secrets Manager. For more information, see the AWS Secrets Manager access control overview..

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 only meant to be used when configuring credentials for MongoDB data repositories. This field refers to the authentication database.

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"
  }
]

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 only meant to be used when configuring credentials for MongoDB data repositories. This field refers to the authentication database.

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"
  }
]

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).

Note: sidecars will require sufficient GCP permissions to access any GCP Secret Manager database account secrets. For example, if the sidecar is running on a GCP VM, the VM must have the necessary IAM permissions to access the secret in Secret Manager. For more information, see the Secret Manager access control overview..

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 and should only be used when configuring credentials for MongoDB data repositories. This field refers to the authentication database.

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"
  }
]

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.

Azure Key Vault

Database accounts can be stored as secrets in Azure Key Vault. Cyral requires the secret URL of the Azure Key Vault secret. The secret URL may be one of the following formats:

• https://{vaultName}.{dnsSuffix}/secrets/{secretName}/{secretVersion}
• https://{vaultName}.{dnsSuffix}/secrets/{secretName}

The DNS suffix depends on the Azure cloud environment. For example, for Azure Cloud, it is vault.azure.net. For more information, see the Azure Key Vault documentation. If the secret version is omitted, the latest version of the secret is assumed.

If you have the secret URL of your database credentials secret, paste it into the Secret URL 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 as an Azure Key Vault secret.

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 only meant to be used when configuring credentials for MongoDB data repositories. This field refers to the authentication database.

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"
  }
]

See the Azure Key Vault tutorial for help storing secrets.

Note: sidecars will require sufficient Azure permissions to access any Azure Key Vault database account secrets. For example, if the sidecar is running on an Azure VM, the VM must have the necessary IAM permissions to access the secret in Azure Key Vault. For more information, see the Azure Key Vault security overview.

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 Access Rules tab, and click Add Rule. For instructions, see the next section, Access rules for users and groups.