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 signs SSL certificates for each QueryGrid Manager instance.
SSL Certificates
- 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.
Authentication and Registration of Data Source Nodes
| 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.
| 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), differs for Teradata Database, Presto, and Hive connectors. For information about security mechanisms specific to a data source, see the appropriate connector chapter.
General Security Guidelines 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.