2.10 - Teradata QueryGrid Security - Teradata QueryGrid

Teradata® QueryGrid™ Installation and User Guide

prodname
Teradata QueryGrid
vrm_release
2.10
created_date
September 2019
category
Administration
Configuration
Installation
User Guide
featnum
B035-5991-099K

Root Certificate Authority

A QueryGrid Manager instance can be installed on one or more TMSs, VMs, or servers. When the first QueryGrid Manager instance is installed, QueryGrid Manager generates a root certificate authority (CA). If additional QueryGrid Manager instances are installed and all instances are clustered, the root CA generated by the first QueryGrid Manager instance is used throughout the cluster.

The root CA must be registered in Viewpoint during Teradata QueryGrid installation.

The root CA signs SSL certificates for each QueryGrid Manager instance.

SSL Certificates

Each QueryGrid Manager instance generates an SSL certificate for secured communication between itself and all other clients. Clients include:
  • Additional QueryGrid Manager instances in the same cluster
  • Data source nodes in a system
  • Viewpoint

When a data source node is added to a system (data source) in QueryGrid, a QueryGrid Manager instance gives the node an SSL certificate during node software installation. The SSL certificate, which is signed by the root CA, allows the data source node to verify that it is communicating with a trusted QueryGrid Manager instance.

All communication between the Teradata QueryGrid Manager instances and data source nodes within the fabric use HTTPS over port 9444.

QueryGrid Manager Service Accounts

Service accounts named viewpoint and support are automatically created using default passwords when QueryGrid Manager is initially started. Teradata strongly recommends changing the default password for these accounts. For more information on changing passwords, see Changing a Service Account Password.

Authentication and Registration of Data Source Nodes

When a data source node is added to a system (data source) in QueryGrid, node software is installed on the node, and a node service registers the node with a QueryGrid Manager instance. The node service provides the following:
Item Description
UUID Acts as the node username when the node authenticates itself to a QueryGrid Manager instance.
Time-limited access token Authenticates the node before the node can be added to a system (data source) for the first time.
Generated password for authentication Allows the node to authenticate itself to a QueryGrid Manager instance after the node joins a system (data source) for the first time.

IP Addresses and Hostname Verification

When the first Teradata QueryGrid Manager instance starts, the generated SSL certificate contains the IP address for the QueryGrid Manager TMS, VM, or server, and the hostnames known to Teradata QueryGrid Manager so that clients can perform host verification.

If the Teradata QueryGrid Manager is accessed by hostnames or IP addresses unknown to it, you can add them to the SSL certificate by setting an aliases property, which can contain a comma-separated list of hostnames or IP addresses. Procedures for adding aliases are included in the installation procedures in this guide.

Communication Policies for Data Transfer within a Fabric

Connectors enable sending and receiving data to and from the data source nodes in a fabric. When configuring Teradata QueryGrid, a communication policy can be set for the link pair associated with the initiating connector (the connector starting the query) and the target connector (the connector receiving the query). You can define different combinations of authentication, integrity, and encryption checks to use for data transfer and specify which one to use for each link.

A communication policy can have one of the following security levels.
Security Level Usage

IP-based authentication, no integrity check, no encryption

Default that specifies a minimum level of security. It is recommended for use only in highly trusted environments.
IP-based authentication, checksum integrity check, no encryption Provides more security than the previous level, but is still recommended for use only in a trusted environment.
Key-based authentication, secure integrity check, encryption credentials Provides more security than the previous level and is recommended in non-trusted environments.
Key-based authentication, secure integrity check, encrypt all data Provides the highest level of security and is recommended in non-trusted environments. The following encryption and integrity algorithms are available: AES-CRC32, AES-GCM (default), AES-SHA256, or AES-SHA512.

OS Users

Security also depends on the OS user the connector software runs as. You can specify the OS user for each connector. The user is typically the same user under which the data source runs.

Data Source User
Teradata Database teradata user
Presto presto user
Hive user executing the query (which may be hive), yarn user, and Kerberos principal or other authorized user
Spark SQL user executing the query (which may be hive), yarn user, and Kerberos principal or other authorized user

LDAP and Kerberos

Supported security mechanisms for a target connector (connector for the data source being queried), are different for Teradata Database, Presto, and Hive connectors. For information about security mechanisms specific to a data source, see the appropriate connector security sections.

General Security Guidelines for Teradata QueryGrid

The following guidelines represent best practices for maintaining security for Teradata QueryGrid.
  • Change Teradata QueryGrid Manager service account default passwords during installation. Procedures are provided in this guide.
  • Set appropriate permissions in Viewpoint to limit the users who can edit the Teradata QueryGrid configuration.
  • Create links using only initiator data sources running in secure environments.
  • Use the security option appropriate to the environment when specifying communication policies for links.