Visit our new documentation site! This documentation page is no longer updated.

Access Control

Treasure Data offers ways to control access to resources and capabilities. Access control settings are managed within the Console. See also Permissions.

Table of Contents

REST APIs Access

REST API access is controlled through API keys. Almost every REST API call needs to be issued with a valid API key for authentication and resource authorization purposes.

There are two types of API keys: Master and Write-only.
By default, every new user is created with one Master and one Write-only API key; however, any user can generate any number of the two types of API keys. Any of the API Keys can be revoked at any time by the user themselves or any user having ‘Manage User’ permissions.

  • Master
    This is the traditional type of API key and it can be used to perform all permitted operations listed in the table above based on the user’s permission level and access, no exception.
  • Write-only
    This API key type provides an additional layer of security in controlling access to a Treasure Data account through the REST APIs, especially when access has to be provided to 3rd parties or API keys need to be embedded in ingestion libraries (see the Overview of Data Import page). Based on the permissions and access levels associated to a user, the user’s Write-only API key will only allow importing data into Treasure Data to those databases it has write access to.

Access levels

Console or Master API key

The following table lists actions that can be performed through either the Console or the REST APIs. Some actions might not be available at the REST API level and some other actions (for example, Data Import) are not available with the Console.

Action Owner Admin Full
Access
Query
only
Import
only
Add User OK OK
Manage User OK OK (1)
Delete User OK OK (1)
List Databases OK OK OK OK OK
Create Database OK OK n/a (2) n/a (2) n/a (2)
Manage Database OK OK OK (2) OK (2) OK (2)
Delete Database OK OK OK (2) OK (2) OK (2)
Show Table OK OK OK OK OK
List Tables OK OK OK OK
Create Table OK OK OK
Delete Table OK OK OK
Data Import (td-agent) OK OK OK OK
Data Import (Result Output to TD) OK OK OK OK
Data Import (Bulk Import) OK OK OK OK
Data Import (embulk-output-td) OK OK OK
Data Import (Data Connector) OK OK OK OK
Data Import (FileUploader v2) OK OK OK OK
Data Import (Insert Into) OK OK OK (3)
Delete Data OK OK OK
Issue Query OK OK OK OK
Kill Own Query OK OK OK OK
Kill Query from Others OK OK OK (4)
Export Table OK OK OK OK

Notes:

  1. ‘Administrator’ users can only ‘Manage User’ and ‘Delete User’ for ‘Restricted’ users but are not allowed to manage and delete other Administrators user or the account ‘Owner’.
    The ‘Manage User’ permission includes granting or revoking the ‘Administrator’ role – therefore an ‘Administrator’ user can promote a user to ‘Administrator’ but cannot demote an user from ‘Administrator’ to ‘Restricted’ user.
  2. Any user (including Restricted ones) can create a new database and they will ‘own’ and have all permissions for it. ‘Full Access’, ‘Query-only’, and ‘Import-only’ permissions for ‘Create Database’ don’t apply in that case. ‘Restricted’ users can only ‘Delete’ and ‘Manage’ databases they created (and therefore own). ‘Administrators’ and ‘Owner’ can always manage databases.
  3. While the end-goal of INSERT INTO is to write the result back into a table, it requires special permissions. The executing user must possess read (‘Query-only’, ‘Full Access’, ‘Admin’, or ‘Owner’) permissions for all the databases accessed by the query as well as read & write permission (‘Full Access’, ‘Admin’, or ‘Owner’) to the database the result is inserted into the query will fail otherwise.
  4. Restricted users with ‘Query-only permission can see all the jobs running on the database they have 'Query-only’ permissions for but will not be able to kill a job unless it’s their own.

Write-only API key

Action Owner Admin Full
Access
Query
only
Import
only
Add User
Manage User
Delete User
List Databases
Create Database OK OK n/a (1) n/a (1) n/a (1)
Manage Database
Delete Database
List Tables
Create Table OK OK OK OK
Delete Table
Data Import (td-agent) OK OK OK OK
Data Import (Result Output to TD) OK OK OK OK
Data Import (Bulk Import) (2) (2) (2) (2)
Data Import (embulk-output-td) (2) (2) (2)
Data Import (Data Connector) (2) (2) (2) (2)
Data Import (Insert Into) (3) (3) (3) (3) (3)
Issue Query
Kill Own Query
Kill Query from Others
Export Table

Notes:

  1. Any user (including Restricted ones) can create a new database and they will ‘own’ and have all permissions for it. ‘Full Access’, ‘Query-only’, and ‘Import-only’ permissions for ‘Create Database’ don’t apply in that case. ‘Restricted’ users can only ‘Delete’ and ‘Manage’ databases they created (and therefore own). ‘Administrators’ and ‘Owner’ can always manage databases.
  2. Bulk Import require the ability to check the status of a job, and this is not possible using a write-only API key.
  3. INSERT INTO requires the ability to execute a query, which is not allowed using a Write-only API key.

IP Whitelist

IP whitelists restrict access to Treasure Data accounts through specified sets of IP addresses. There are two types of whitelists: default account IP whitelist and user IP whitelist.

The default account IP whitelist affects all users in an account. the Account Owner and Administrators can modify the default account IP whitelist.

The user IP whitelist contains IP addresses that a specific user can use to access services. The Account Owner and Administrators set user IP whitelists. A user IP whitelist is viewable from a user’s profile page.

Refer to the article IP Whitelist for more information.

Session Timeout

Administrators can specify the maximum length of Web browser sessions. Click Admin > Security.



The default value is 1 week. For example, if 1 week is specified, users do not need to login until after 7 days have passed. With 1 week specified, users would need to log in only once per week. Only administrators can set the maximum session for users.

Deleted Users and the Impact on Existing Objects

When a user is deleted from an account, objects created by that user might be affected. The following table summarizes how objects are affected by user deletion:

Object Re-Assigned To Status Notes
API Keys Account Owner Continuously available The authority level of deleted user is changed to the level of the re-assigned user (Account owner). If the deleted user was “Restricted” user, you must manually reassign API Keys to be Restricted by creating a new user, if necessary.
Databases Account Owner Continuously available The Account Owner is notified by email.
Tables (None) Continuously available -
My Connections (None) Continuously available -
My Input Transfers Account Owner Available The Account Owner is notified by email.

Schedule is deactivated. Re-enable it manually, as necessary.
Queries Account Owner Available The Account Owner is notified by email.

Schedule is deactivated. Re-enable it manually, as necessary.
Jobs (None) Continuously available -
Workflow (Owner is invisible) Continuously available Current limitation: The Treasure Data related operators in the workflow (such as td>, td_run>, and so forth) fail if the td.apikey secret is not set for projects that the deleted user created.

To avoid failed runs, set the td.apikey secret. Refer to workflow secrets.

Last modified: May 11 2018 19:53:33 UTC

If this article is incorrect or outdated, or omits critical information, let us know. For all other issues, access our support channels.