Connect Your Database

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.

Connect to the instance on the same host

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.

connect-local-docker

  • If you run Bytebase without Docker and try to connect to a database instance on the same host, then you need to set host as 127.0.0.1

connect-local-no-docker

Connect to the instance from Bytebase Cloud

network-topology

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

Configure SSL

SSL connection configuration only supports PostgreSQL, MySQL, TiDB and ClickHouse for now.

Configure SSH tunnel

This feature is available in Enterprise Plan.

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.

ssh explain

  1. After filling in the standard database connection information, click SSH Connection > Tunnel + Private Key.
  2. Fill in the SSH connection information. The Private Key is used to authenticate the SSH connection. You can also use a password instead. ssh tunnelling
  3. Click Test Connection. If the connection is successful, click Create to create this instance.

Configure read-only connection

This feature is available in Enterprise Plan.

To separate from admin connection, you can configure read-only connections used by SQL Editor once an instance is added. This separation can be configured at the database user/role access control level or replication instance level.

  1. Create a new role with read-only access or a read-replica instance.
  2. Click Create or + on Connection info.
  3. Enter read-only connection info. If this is a read-replica instance, you need to enter its host and port information.
  4. Click Update to finish the configuration.
  5. Click + to add more, or click trash icon to delete.

bb-instance-read-only-connection

Use IAM Auth

This feature is available in Enterprise Plan.

You can use Cloud providers' IAM user to connect to their databases.

AWS RDS/Aurora

While creating an RDS or Aurora instance, you can choose to enable IAM authentication.

Create IAM policy

  1. Go to IAM > Policies and click Create policy.

  2. Select RDS IAM Authentication for service.

  3. 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 *:

  • 1st *: any regions
  • 2nd *: any databases
  • 3rd *: any database users

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.

  1. Name it rds-connect and create this policy.

Create IAM user

  1. Go to IAM > Users can click Create user. Name it rds-connector.

  2. Choose Attach policy directly and select the rds-connect policy. Click Next and then click Create user.

  3. On the user detail page, click Create access key.

  4. Choose Application running outside AWS and click Next.

  5. Then you get the access key and the secret access key.

Use IAM Auth in Bytebase

  1. Start Bytebase with AWS IAM credentials by passing the AWS environment variables:

    docker run --init \
      -e AWS_ACCESS_KEY_ID=<<your-access-key>> \
      -e AWS_SECRET_ACCESS_KEY=<<your-secret-access-key>> \
      -e AWS_REGION=<<your-aws-region>> \
      --name bytebase \
      --publish 8080:8080 --pull always \
      bytebase/bytebase:2.21.0
  2. Go to RDS instance detail page, you'll find the endpoint and port.

  3. Configure instance connection using AWS RDS IAM, create the bytebase user with AWSAuthenticationPlugin and grant permission.

    CREATE USER bytebase@'%' IDENTIFIED WITH AWSAuthenticationPlugin AS 'RDS';
    
        ALTER USER 'bytebase'@'%' REQUIRE SSL;
    
        GRANT ALTER, ALTER ROUTINE, CREATE, CREATE ROUTINE, CREATE VIEW,
        DELETE, DROP, EVENT, EXECUTE, INDEX, INSERT, PROCESS, REFERENCES,
        SELECT, SHOW DATABASES, SHOW VIEW, TRIGGER, UPDATE, USAGE,
        RELOAD, LOCK TABLES, REPLICATION CLIENT, REPLICATION SLAVE
        /*!80000 , SET_USER_ID */ON *.* to bytebase@'%';
  4. Use the instance endpoint, port and the username bytebase to connect the instance.

Google Cloud SQL

Create a service account

  1. Visit Service accounts to create a new service account bytebase.

  2. Grant Cloud SQL Admin permission to the service account.

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

  4. Click ADD KEY and then Create new key.

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

  6. Go to Cloud SQL database instance detail page, and make sure cloudsql_iam_authentication is enabled.

  7. Go to Users tab, and click ADD USER ACCOUNT.

  8. Select Cloud IAM and copy/paste the service account email bytebase@<<your-project-name>>.iam.gserviceaccount.com.

  9. Then you can get the Cloud SQL IAM user: bytebase.

Use IAM Auth in Bytebase

  1. Start Bytebase with Google IAM credentials by passing GOOGLE_APPLICATION_CREDENTIALS as an environment variable:

    docker run --init \
      -e GOOGLE_APPLICATION_CREDENTIALS=<<your-json-file>> \
      --name bytebase \
      --publish 8080:8080 --pull always \
      --volume ~/.bytebase/data:/var/opt/bytebase \
      bytebase/bytebase:2.21.0
  2. 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.

Use external secret manager

This feature is available in Enterprise Plan.

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.

external-secret-manager-flow

  1. User tries to access database from Bytebase.
  2. Bytebase calls the external secret manager to exchange the configured key for the database password.
  3. Bytebase retrieves the password and connect the database.

HashiCorp Vault

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

    create-secret

Configure instance to retrieve database password from vault:

  • Specify the Vault URL.

  • Specify the Vault auth method.

    • For Token, specify the token.
    • For AppRole, specify the auth role id and secret id.
  • Specify the secret engine namesecret, secret path bytebase and secret key DB_PASSWORD.

    vault-auth

AWS Secrets Manager

Create an IAM user to access the Secrets Manager

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.

Create secret

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.

Use secret in Bytebase

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:
AWS_REGION=us-east-1 AWS_ACCESS_KEY_ID=xxx AWS_SECRET_ACCESS_KEY=yyy ./bytebase <<other options>>
docker run --init \
  -e AWS_REGION=us-east-1 AWS_ACCESS_KEY_ID=xxx AWS_SECRET_ACCESS_KEY=yyy \
  --name bytebase \
  <<other options>>

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.

GCP Secret Manager

Create a service account to access the Secret Manager

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.

Create secret

Visit GCP Secret Manager to create a new secret.

After creation, note the fully qualified secret name.

Use secret in Bytebase

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.

docker run --init \
  -e GOOGLE_APPLICATION_CREDENTIALS=/var/opt/bytebase/key.json \
  --name bytebase \
  --volume ~/.bytebase/data:/var/opt/bytebase \
  <<other options>>

Go to instance setting, specify the fully qualified name such as projects/228712144016/secrets/DB_PASSWORD as the Secret full name.

Custom endpoint

external-secret-manager-config

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.

curl "http://example.com/secrets/mydbkey"

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.

{
  "payload": {
    "data": "xxx"
  }
}

PostgreSQL

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:

You should grant Bytebase privileges with that semi-SUPERUSER role, e.g.:

-- For AWS RDS
GRANT rds_superuser TO bytebase
-- For Google Cloud SQL
GRANT cloudsqlsuperuser TO bytebase

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.

Oracle

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.

Manage based on database

In this mode, Bytebase will manage the database as a whole.

  • For normal Oracle instance, we treat the Oracle database as a Bytebase database.
  • For CDB instance, we treat the CDB and all PDBs as Bytebase databases.
  • For PDB instance, we treat the PDB as a Bytebase database.

Manage based on schema

In this mode, Bytebase will manage the schema as a whole.

  • For any Oracle database, we treat the Oracle schema as a Bytebase database.

Snowflake

sf-account-locator

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

sf-locator

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.

Google Cloud Spanner

For connecting to Google Cloud Spanner, you need to provide the following info:

  1. Google cloud project ID.
  2. Google cloud Spanner instance ID.
  3. Google cloud service account credentials.

spanner

Specify Google Cloud Project ID and Spanner Instance ID

Spanner database detail page

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.

Create a Google Cloud Service Account as the Credential

  1. Go to Google Cloud console.
  2. Click APIs & Services and then Credentials. You might have to click Menu on the top left first.
  3. Click Create Credentials and then Service account.
  4. For Service account name, enter a name for the service account.
  5. Click Create and Continue.
  6. For Select a role, select Cloud Spanner Database Admin for the service account.
  7. Click Done.
  8. Click the created service account.
  9. At the top, click Keys and then Add Key and then Create new key. Make sure the key type is set to JSON and click Create.
  10. You'll get a message that the service account's private key JSON file was downloaded to your computer. Make a note of the file name and where your browser saves it. You'll need it later.

Upload the JSON file to the Credentials input.

Edit this page on GitHub

Subscribe toย Newsletter

By subscribing, you agree with Bytebase's Terms of Service and Privacy Policy.