Managing Data Tank 2.0 with the Management UI

The Management UI is a web application that enables you to configure, monitor, and control Treasure Data Data Tank 2.0. Management UI access requires administrator-level permission. Contact your Customer Success representative for access.

See also Understanding Data Tank 2.0 Maintenance.

You can manage Data Tank 2.0 by using the Management UI.

Sign in to the Treasure Console before accessing these URLs. The user signing in should be an administrator or owner.

Use the Database page to view and configure database-related settings.

Use the Schemas page to view, create, and delete schemas.

A schema is a namespace that contains named database objects such as tables, views, indexes, data types, functions, stored procedures, and operators. Each database has a public schema automatically as the default. The Management UI enables you to create a new schema and delete an empty schema. After a schema is created, the schema name is not editable. The public schema and its description cannot be deleted.

Here are some example scenarios where you might want to use schemas:

• Organizing database objects -- For example, organizing tables into logical groups to make them more manageable.
• Enabling multiple users -- To use one database without interfering with each other.

1. To create a new schema, select NEW.
2. Create the new schema. By default, a new schema does not permit the execution of DDL statements. To enable DDL for a specific user with the new schema, toggle Enable customized DDL.

Access Keys are required to access Data Tank 2.0. The Access Keys page allows you to view and edit an access key required to access Data Tank 2.0.

Creating a new Access Key generates a random username and password to access Data Tank 2.0. When creating an Access Key, ensure the logical name is unique and that it is not a Data Tank 2.0 username.

You can revoke permission to connect to Data Tank 2.0 by deactivating the access key. The access key itself is not deleted. Re-enabling the access key restores permission.

The Access Policies page enables you to grant access permission for a specific schema using an access key.

After a new access key is created, by default, the user has access permission to the system catalog. The following types of access policies can be set per user.

When the CUSTOMIZABLE_USER policy is applied to an access key, the user can view and change access controls on a table-by-table basis for that access key. The access types that can be applied in combination with access keys and tables are as follows:

This section explains the procedure for executing DDL statements such as CREATE, ALTER, DROP, GRANT, and REVOKE.

1. Create a new Access Key.

2. Create an Access Policy of type CUSTOMIZABLE_ADMIN for the new Access Key.

3. Connect to Data Tank 2.0 using the PostgreSQL client with the new Access Key.

4. Execute the following statement:

   SET ROLE _owner_<database name>_<schema name>

5. Execute the required DDL statements.

DDL statements can only be executed if SET ROLE is executed in the session.

The role name to switch to, _owner_<database name>_<schema name>, is determined based on the database name and schema name. For example, if the database name is aciddb and the schema name is public, the owner role name is _owner_aciddb_public.

When the SET ROLE statement is executed, the access key can temporarily inherit the owner user's privileges. This inheritance lasts until the session ends. The access key is only permitted to execute SET ROLE if the CUSTOMIZABLE_ADMIN access policy is set.

You can configure a maintenance window in the Management UI.

Use the following fields to configure a maintenance window in the Management UI:

• Namespace: instance
• Key: preferredMaintenanceWindow
• Value:
  • Format: ^(Mon|Tue|Wed|Thu|Fri|Sat|Sun):([01][0-9]|2[0-3]):[0-5][0-9]-(Mon|Tue|Wed|Thu|Fri|Sat|Sun):([01][0-9]|2[0-3]):[0-5][0-9]$
  • Examples:
    • Sun:10:00-Sun:12:00 -- Between Sunday 10:00 and 12:00 (GMT)
    • Mon:23:00-Tue:01:00 -- Between Monday 23:00 and Tuesday 01:00 (GMT)
• Secret: unchecked

The Changes page lets you view and manage DB instances and their parameters and IP whitelist.

The IP whitelist feature enables you to grant Data Tank 2.0 access only to specific IP addresses.

1. On the configuration page, select Changes and then select the allowedAddress key.

   

2. Enter IP addresses you want to allow in the Value field using CIDR format. Here are the values for the fields:

   • Namespace: instance
   • Key: allowedAddress
   • Value:
     • g:treasuredata-main -- This entry contains the IP addresses of Treasure Data servers for the Management UI and Integration with PostgreSQL. Be careful not to delete it.
     • IP addresses, with each IP address on a separate line
   • Secret: toggled off
   

3. Select SAVE. The configuration is not yet applied at this time.

4. Review the Change to be applied and then select DEPLOY.

   

Applying a change usually takes a few minutes until the processing status changes from APPLYING to SUCCESS.

The connection to Data Tank 2.0 is encrypted with SSL/TLS. Treasure Data supports four options for encryption.

To update the CA of your AWS cluster, you need to set up the certificate bundle on your client side and switch the certificate authority in the Management UI.

1. Identify your AWS region in the following table.

   Region of Treasure Data	AWS region
   US	US East (N. Virginia)
   Tokyo	Asia Pacific (Tokyo)
   EU01	Europe (Frankfurt)
   AP02	Asia Pacific (Seoul)

2. Locate the certificate bundle for your AWS Region, which is required for Data Tank 2.0 and based on Aurora PostgreSQL.

3. Download the certificate bundle (PEM).

This bundle includes all of the CA certificates: rds-ca-2019, rds-ca-rsa2048-g1, rds-ca-rsa4096-g1, and rds-ca-ecc384-g1. After you set it up on your client side with this bundle, no update is required next time you switch the certificate authority.

1. Create a change draft named certificateAuthority as depicted in the following image.
2. Run a deployment job on that cluster.