QueryGrid Manager 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.
QueryGrid Manager SSL Certificates
- Additional QueryGrid Manager instances in the same cluster
- Data source nodes in a system
- Viewpoint
- Browser to QueryGrid Manager REST API documentation
- REST clients
When a data source node is added to a data source system 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 communication is with a trusted QueryGrid Manager instance.
All communication between the QueryGrid Manager instances and data source nodes within the fabric use HTTPS over port 9444.
QueryGrid Manager Service Accounts
QueryGrid Manager service accounts provide the access to call QueryGrid Manager APIs. These accounts are internal to QueryGrid Manager and do not correspond to any database or operating system user accounts. The service accounts only provide access to QueryGrid configuration and monitor data.
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 about changing passwords, see Changing a Service Account Password or Resetting a Service Account Password if the password is forgotten.
Service accounts are locked for 30 minutes if there are 3 failed login attempts within 15 minutes due to an incorrect password. Run /opt/teradata/tdqgm/bin/unlock-account.sh to immediately unlock the account.
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 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 data source for the first time. |
IP Addresses and Hostname Verification
When the first 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 QueryGrid Manager so that clients can perform host verification.
If the QueryGrid Manager is accessed by unknown hostnames or IP addresses, you can add them to the SSL certificate by setting an alias 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.
Data Transfer
- A fabric process runs on each attached node running QueryGrid.
- The connector establishes a channel with the local fabric node to send and receive data.
- The fabric only allows connections from local connector processes in the allowed OS user list defined on the connector.
- As of QueryGrid 2.15, fabric processes communicate using TLS 1.2+.
- All data is encrypted by default and each fabric process generates a public/private key pair used for mutual authentication with other fabric processes.
- The private key is maintained in memory and the public key is sent and distributed by QueryGrid Manager.
- Keys are rotated once a week.
OS Users
Security also depends on the OS user the connector software uses. You can specify the OS user for each connector. The user is typically the same user as the data source user.
Data Source | User |
---|---|
Teradata system | teradata user |
Presto | starburst 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 are different for Teradata, Presto, and Hive connectors. For information about security mechanisms specific to a data source, see the appropriate connector security sections.
General Security Guidelines for QueryGrid
- Change the 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 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.