Only Workspace Admin or Workspace DBA role can configure database instance.
To allow Bytebase to execute operations on behalf the end user, you need to supply Bytebase with the connection info for your database instance.
If you run Bytebase inside Docker and try to connect to a database instance on the same host, then you need to set host as host.docker.internal.
127.0.0.1
To make your Bytebase Cloud instance connect to your databases in your internal network, you need to whitelist the following Bytebase Cloud IPs:
34.27.188.162
To protect their databases, some hosting providers block direct remote access. However, they often enable SSH, which allows users to connect to their servers remotely using an SSH client. If you want to connect to a database on one of these servers from Bytebase, you will need to create an SSH tunnel. This will allow you to connect to the database without compromising security.
When connecting to a database instance, you may need to specify additional parameters to customize the connection behavior. Bytebase provides a feature that allows users to define extra parameters for the database connection string directly in the UI.
Supported Database Connection Parameters
Below are links to official documentation for configuring connection parameters:
Common Connection Parameters
Parameter | Description | Example |
---|---|---|
sslmode | SSL connection mode (PostgreSQL) | require |
connect_timeout | Timeout for establishing connections | 10 |
readTimeout | Read timeout for MySQL and MSSQL connections | 30s |
max_connections | Maximum number of connections allowed | 100 |
For a full list of supported parameters, refer to the official database documentation links above.
By default, Bytebase stores the database credentials in an obfuscated format in its own meta store. You can also instruct Bytebase to retrieve the database credential from an external secret manager.
Bytebase only supports KV v2 engine.
Create the secret in Vault like below:
Secret engine name: secret
Secret path: bytebase
Secret key: DB_PASSWORD
Secret: <<YOUR_PASSOWRD>>
Configure instance to retrieve database password from vault:
Specify the Vault URL.
Specify the Vault auth method.
Specify the secret engine namesecret
, secret path bytebase
and secret key DB_PASSWORD
.
If you have a custom external secret manager, you can supply its API endpoint by enclosing it with the mustache {{
}}
, e.g {{http://example.com/secrets/mydbkey}}
Sample request
Usually mydbkey
is unique for each database and used for exchanging the password for that database.
Expected response
Bytebase expects the following JSON response from the external secret manager. The payload.data
is the
base64-encoded contents of the database password.
While creating an RDS or Aurora instance, you can choose to enable IAM authentication.
Go to IAM > Policies and click Create policy.
Select RDS IAM Authentication
for service.
Select connect
permission and specific
as Resources. Check Any in this account
.
Any in this account
will mark the resource as
arn:aws:rds-db:*:<<your-db-id>>:dbuser:*/*
, which contains 3 *
:
This will allow the RDS connect on behalf of all database users in all databases in your account. If you want to limit the connection to specific databases, please follow this doc.
Name it rds-connect
and create this policy.
Go to IAM > Users can click Create user. Name it rds-connector
.
Choose Attach policy directly and select the rds-connect
policy. Click Next and then click Create user.
On the user detail page, click Create access key.
Choose Application running outside AWS
and click Next.
Then you get the access key and the secret access key.
Start Bytebase with AWS IAM credentials by passing the AWS environment variables:
Go to RDS instance detail page, you’ll find the endpoint and port.
Configure instance connection using AWS RDS IAM
, create the bytebase
user with AWSAuthenticationPlugin
and grant permission.
Use the instance endpoint, port and the username bytebase
to connect the instance.
It’s recommended to create a dedicated IAM user for Bytebase to retrieve the secrets. You only need to do this once .
Visit IAM to create a new IAM user. Name it bytebase-external-secret
.
Attach SecretsManagerReadWrite
permission.
After creating the IAM user, create an Access Key to be used by Bytebase later.
Select Third-party service
as the use case.
Optionally set the description tag and in the Retrieve access keys
screen, record Access key
and
Secret access key
. They will be passed as environment variables when starting Bytebase.
Visit AWS Secrets Manager to store a new secret. Select
Other type of secret
, and add a key/value pair. The key is DB_PASSWORD
and the value is your
database user password.
Next to the Configure secret
, use bytebase
as the Secret name
Skip rotation, review and create the secret.
Restart Bytebase with the following environment variables
AWS_REGION
=us-east-1
AWS_ACCESS_KEY_ID
and AWS_SECRET_ACCESS_KEY
are the ones you previously created on the IAM user:Go to instance setting, specify bytebase
as the Secret name and DB_PASSWORD
as the Secret key.
These two correspond to the value you created in the AWS Secrets Manager.
Visit Service accounts to create a new service account bytebase
.
Grant Cloud SQL Admin
permission to the service account.
After the service account is created, you may view the email for the service account bytebase@<<you-project-name>>.iam.gserviceaccount.com
. Go to KEYS.
Click ADD KEY and then Create new key.
Choose JSON
as the key type and click CREATE. Keep the downloaded private key file. This will be passed
as environment variables when starting Bytebase.
Go to Cloud SQL database instance detail page, and make sure cloudsql_iam_authentication
is enabled.
Go to Users tab, and click ADD USER ACCOUNT.
Select Cloud IAM
and copy/paste the service account email bytebase@<<your-project-name>>.iam.gserviceaccount.com
.
Then you can get the Cloud SQL IAM user: bytebase
.
Start Bytebase with Google IAM credentials by passing GOOGLE_APPLICATION_CREDENTIALS
as an environment variable:
Go to SQL overview page, you’ll find the Connection name, use it as the host. Choose Google Cloud SQL IAM
along with your user bytebase
to connect to the database.
It’s recommended to create a dedicated service account for Bytebase to retrieve the secrets. You only need to do this once .
Visit Service accounts to create a new service account.
Grant Secret Manager Secret Accessor
permission to the service account.
After the service account is created, visit its KEYS
page and add a new key.
Choose JSON
as the key type and create. Keep the downloaded private key file. This will be passed
as environment variables when starting Bytebase.
Visit GCP Secret Manager to create a new secret.
After creation, note the fully qualified secret name.
Restart Bytebase by specifying GOOGLE_APPLICATION_CREDENTIALS
=private key file
as an environment variable. The
private key file is the JSON file downloaded before for the service account.
If you run Bytebase in docker, you need to put the JSON file under the mounted directory. Otherwise, Bytebase won’t be able to access the key file.
Go to instance setting, specify the fully qualified name such as projects/228712144016/secrets/DB_PASSWORD
as the Secret full name.
Bytebase supports connect to Azure SQL through Azure IAM by using default Azure credential and client secret credential. This section introduces how to use system-assigned managed identity to connect to Azure SQL. For more information about the credential chain in default Azure credential, please refer to default azure credential overview.
Enable system assigned managed identity while creating a VM.
Deploy the Bytebase on the VM in Docker:
Go to the Azure SQL panel, and set the Microsoft Entra Admin for Azure SQL managed instance, don’t forget to click Save button. Once you set the Microsoft Entra Admin, the Microsoft Entra authentication is enabled. Check the Microsoft guide if you use Azure SQL on VM.
Connect to the Azure SQL database using the Microsoft Entra Admin account.
For each databases desired to be managed by Bytebase, running the following SQL command inside the database to a contained database user:
Using Azure IAM default credential to connect to Azure SQL database:
In this way, Bytebase can only connect to one specific Azure SQL database. To manage multiple Azure SQL databases in one instance inside Bytebase, considering set the VM principal as the Azure SQL Managed Instance Microsoft Entra Admin.
If the connecting instance is managed by the cloud provider, then SUPERUSER is not available and you should create the role via that provider’s admin console. The created role will have provider specific restricted semi-SUPERUSER privileges:
In AWS RDS, the roll is rds_superuser
.
In Google Cloud SQL, the role is cloudsqlsuperuser
.
You should grant Bytebase privileges with that semi-SUPERUSER role, e.g.:
Besides, you may need to grant Bytebase privileges with GRANT role_name TO bytebase;
for all existing roles. Otherwise, Bytebase may not access existing databases or tables.
To prevent blocking operations for a long time, consider setting a lock_timeout on the Bytebase user.
If the connecting instance is managed by the cloud provider, then SUPERUSER is not available and you should create the role via that provider’s admin console. The created role will have provider specific restricted semi-SUPERUSER privileges:
In AWS RDS, the roll is rds_superuser
.
In Google Cloud SQL, the role is cloudsqlsuperuser
.
You should grant Bytebase privileges with that semi-SUPERUSER role, e.g.:
Besides, you may need to grant Bytebase privileges with GRANT role_name TO bytebase;
for all existing roles. Otherwise, Bytebase may not access existing databases or tables.
To prevent blocking operations for a long time, consider setting a lock_timeout on the Bytebase user.
For managing Oracle database, Bytebase provides two manage modes: Manage based on database and Manage based on schema. You can choose the manage mode when adding an instance or in the instance detail page.
In this mode, Bytebase will manage the database as a whole.
In this mode, Bytebase will manage the schema as a whole.
Go to Atlas MongoDB Security > Network Access and add IP allowing access from Anywhere
.
Go to Atlas MongoDB Deployment > Database, and click Connect.
Click Connect to your application.
Find this string cluster0.8bxxxbz.mongodb.net
. Go back to Bytebase, put the string into Host or Socket, and leave Port empty.
Choose mongodb+srv://
as Connection String Schema.
To find the Account Locator, go to your Snowflake account, you can find it in the URL, or from the locator field (but lower case).
If the account is located in the AWS US West (Oregon) region, then it would be something like xy12345
, otherwise, the format will be <<account_locator>>.<<cloud_region_id>>.<<cloud>>
such as xy12345.us-east-2.aws
. See official doc.
If you use ClickHouse Cloud. Go to your ClickHouse Cloud account, and click View connection string. Also make sure to whitelist the IP where Bytebase connects from.
In Environment, select your database. Then fill Host or Socket, Warehouse ID and Token.
Click Test Connection to verify.
For connecting to Google Cloud Spanner, you need to provide the following info:
From the Spanner database detail page, you can get the project ID and the instance ID from the URL.
For example, the project ID and instance ID are spanner-test-3717002
and spanner-bb1
respectively for the above database.
Upload the JSON file to the Credentials
input.
Only Workspace Admin or Workspace DBA role can configure database instance.
To allow Bytebase to execute operations on behalf the end user, you need to supply Bytebase with the connection info for your database instance.
If you run Bytebase inside Docker and try to connect to a database instance on the same host, then you need to set host as host.docker.internal.
127.0.0.1
To make your Bytebase Cloud instance connect to your databases in your internal network, you need to whitelist the following Bytebase Cloud IPs:
34.27.188.162
To protect their databases, some hosting providers block direct remote access. However, they often enable SSH, which allows users to connect to their servers remotely using an SSH client. If you want to connect to a database on one of these servers from Bytebase, you will need to create an SSH tunnel. This will allow you to connect to the database without compromising security.
When connecting to a database instance, you may need to specify additional parameters to customize the connection behavior. Bytebase provides a feature that allows users to define extra parameters for the database connection string directly in the UI.
Supported Database Connection Parameters
Below are links to official documentation for configuring connection parameters:
Common Connection Parameters
Parameter | Description | Example |
---|---|---|
sslmode | SSL connection mode (PostgreSQL) | require |
connect_timeout | Timeout for establishing connections | 10 |
readTimeout | Read timeout for MySQL and MSSQL connections | 30s |
max_connections | Maximum number of connections allowed | 100 |
For a full list of supported parameters, refer to the official database documentation links above.
By default, Bytebase stores the database credentials in an obfuscated format in its own meta store. You can also instruct Bytebase to retrieve the database credential from an external secret manager.
Bytebase only supports KV v2 engine.
Create the secret in Vault like below:
Secret engine name: secret
Secret path: bytebase
Secret key: DB_PASSWORD
Secret: <<YOUR_PASSOWRD>>
Configure instance to retrieve database password from vault:
Specify the Vault URL.
Specify the Vault auth method.
Specify the secret engine namesecret
, secret path bytebase
and secret key DB_PASSWORD
.
If you have a custom external secret manager, you can supply its API endpoint by enclosing it with the mustache {{
}}
, e.g {{http://example.com/secrets/mydbkey}}
Sample request
Usually mydbkey
is unique for each database and used for exchanging the password for that database.
Expected response
Bytebase expects the following JSON response from the external secret manager. The payload.data
is the
base64-encoded contents of the database password.
While creating an RDS or Aurora instance, you can choose to enable IAM authentication.
Go to IAM > Policies and click Create policy.
Select RDS IAM Authentication
for service.
Select connect
permission and specific
as Resources. Check Any in this account
.
Any in this account
will mark the resource as
arn:aws:rds-db:*:<<your-db-id>>:dbuser:*/*
, which contains 3 *
:
This will allow the RDS connect on behalf of all database users in all databases in your account. If you want to limit the connection to specific databases, please follow this doc.
Name it rds-connect
and create this policy.
Go to IAM > Users can click Create user. Name it rds-connector
.
Choose Attach policy directly and select the rds-connect
policy. Click Next and then click Create user.
On the user detail page, click Create access key.
Choose Application running outside AWS
and click Next.
Then you get the access key and the secret access key.
Start Bytebase with AWS IAM credentials by passing the AWS environment variables:
Go to RDS instance detail page, you’ll find the endpoint and port.
Configure instance connection using AWS RDS IAM
, create the bytebase
user with AWSAuthenticationPlugin
and grant permission.
Use the instance endpoint, port and the username bytebase
to connect the instance.
It’s recommended to create a dedicated IAM user for Bytebase to retrieve the secrets. You only need to do this once .
Visit IAM to create a new IAM user. Name it bytebase-external-secret
.
Attach SecretsManagerReadWrite
permission.
After creating the IAM user, create an Access Key to be used by Bytebase later.
Select Third-party service
as the use case.
Optionally set the description tag and in the Retrieve access keys
screen, record Access key
and
Secret access key
. They will be passed as environment variables when starting Bytebase.
Visit AWS Secrets Manager to store a new secret. Select
Other type of secret
, and add a key/value pair. The key is DB_PASSWORD
and the value is your
database user password.
Next to the Configure secret
, use bytebase
as the Secret name
Skip rotation, review and create the secret.
Restart Bytebase with the following environment variables
AWS_REGION
=us-east-1
AWS_ACCESS_KEY_ID
and AWS_SECRET_ACCESS_KEY
are the ones you previously created on the IAM user:Go to instance setting, specify bytebase
as the Secret name and DB_PASSWORD
as the Secret key.
These two correspond to the value you created in the AWS Secrets Manager.
Visit Service accounts to create a new service account bytebase
.
Grant Cloud SQL Admin
permission to the service account.
After the service account is created, you may view the email for the service account bytebase@<<you-project-name>>.iam.gserviceaccount.com
. Go to KEYS.
Click ADD KEY and then Create new key.
Choose JSON
as the key type and click CREATE. Keep the downloaded private key file. This will be passed
as environment variables when starting Bytebase.
Go to Cloud SQL database instance detail page, and make sure cloudsql_iam_authentication
is enabled.
Go to Users tab, and click ADD USER ACCOUNT.
Select Cloud IAM
and copy/paste the service account email bytebase@<<your-project-name>>.iam.gserviceaccount.com
.
Then you can get the Cloud SQL IAM user: bytebase
.
Start Bytebase with Google IAM credentials by passing GOOGLE_APPLICATION_CREDENTIALS
as an environment variable:
Go to SQL overview page, you’ll find the Connection name, use it as the host. Choose Google Cloud SQL IAM
along with your user bytebase
to connect to the database.
It’s recommended to create a dedicated service account for Bytebase to retrieve the secrets. You only need to do this once .
Visit Service accounts to create a new service account.
Grant Secret Manager Secret Accessor
permission to the service account.
After the service account is created, visit its KEYS
page and add a new key.
Choose JSON
as the key type and create. Keep the downloaded private key file. This will be passed
as environment variables when starting Bytebase.
Visit GCP Secret Manager to create a new secret.
After creation, note the fully qualified secret name.
Restart Bytebase by specifying GOOGLE_APPLICATION_CREDENTIALS
=private key file
as an environment variable. The
private key file is the JSON file downloaded before for the service account.
If you run Bytebase in docker, you need to put the JSON file under the mounted directory. Otherwise, Bytebase won’t be able to access the key file.
Go to instance setting, specify the fully qualified name such as projects/228712144016/secrets/DB_PASSWORD
as the Secret full name.
Bytebase supports connect to Azure SQL through Azure IAM by using default Azure credential and client secret credential. This section introduces how to use system-assigned managed identity to connect to Azure SQL. For more information about the credential chain in default Azure credential, please refer to default azure credential overview.
Enable system assigned managed identity while creating a VM.
Deploy the Bytebase on the VM in Docker:
Go to the Azure SQL panel, and set the Microsoft Entra Admin for Azure SQL managed instance, don’t forget to click Save button. Once you set the Microsoft Entra Admin, the Microsoft Entra authentication is enabled. Check the Microsoft guide if you use Azure SQL on VM.
Connect to the Azure SQL database using the Microsoft Entra Admin account.
For each databases desired to be managed by Bytebase, running the following SQL command inside the database to a contained database user:
Using Azure IAM default credential to connect to Azure SQL database:
In this way, Bytebase can only connect to one specific Azure SQL database. To manage multiple Azure SQL databases in one instance inside Bytebase, considering set the VM principal as the Azure SQL Managed Instance Microsoft Entra Admin.
If the connecting instance is managed by the cloud provider, then SUPERUSER is not available and you should create the role via that provider’s admin console. The created role will have provider specific restricted semi-SUPERUSER privileges:
In AWS RDS, the roll is rds_superuser
.
In Google Cloud SQL, the role is cloudsqlsuperuser
.
You should grant Bytebase privileges with that semi-SUPERUSER role, e.g.:
Besides, you may need to grant Bytebase privileges with GRANT role_name TO bytebase;
for all existing roles. Otherwise, Bytebase may not access existing databases or tables.
To prevent blocking operations for a long time, consider setting a lock_timeout on the Bytebase user.
If the connecting instance is managed by the cloud provider, then SUPERUSER is not available and you should create the role via that provider’s admin console. The created role will have provider specific restricted semi-SUPERUSER privileges:
In AWS RDS, the roll is rds_superuser
.
In Google Cloud SQL, the role is cloudsqlsuperuser
.
You should grant Bytebase privileges with that semi-SUPERUSER role, e.g.:
Besides, you may need to grant Bytebase privileges with GRANT role_name TO bytebase;
for all existing roles. Otherwise, Bytebase may not access existing databases or tables.
To prevent blocking operations for a long time, consider setting a lock_timeout on the Bytebase user.
For managing Oracle database, Bytebase provides two manage modes: Manage based on database and Manage based on schema. You can choose the manage mode when adding an instance or in the instance detail page.
In this mode, Bytebase will manage the database as a whole.
In this mode, Bytebase will manage the schema as a whole.
Go to Atlas MongoDB Security > Network Access and add IP allowing access from Anywhere
.
Go to Atlas MongoDB Deployment > Database, and click Connect.
Click Connect to your application.
Find this string cluster0.8bxxxbz.mongodb.net
. Go back to Bytebase, put the string into Host or Socket, and leave Port empty.
Choose mongodb+srv://
as Connection String Schema.
To find the Account Locator, go to your Snowflake account, you can find it in the URL, or from the locator field (but lower case).
If the account is located in the AWS US West (Oregon) region, then it would be something like xy12345
, otherwise, the format will be <<account_locator>>.<<cloud_region_id>>.<<cloud>>
such as xy12345.us-east-2.aws
. See official doc.
If you use ClickHouse Cloud. Go to your ClickHouse Cloud account, and click View connection string. Also make sure to whitelist the IP where Bytebase connects from.
In Environment, select your database. Then fill Host or Socket, Warehouse ID and Token.
Click Test Connection to verify.
For connecting to Google Cloud Spanner, you need to provide the following info:
From the Spanner database detail page, you can get the project ID and the instance ID from the URL.
For example, the project ID and instance ID are spanner-test-3717002
and spanner-bb1
respectively for the above database.
Upload the JSON file to the Credentials
input.