Teradata Connection

See the Teradata end-user license agreement.

Public preview: This feature is available to select accounts. Contact your Immuta representative to enable this feature.

The Teradata connection registers data from Teradata VantageCloud and Teradata VantageCore in Immuta and enforces subscription policies on that data.

The sequence diagram below outlines the events that occur when an Immuta user who is subscribed to a data source queries that data in Teradata.

What does Immuta do in my environment?

Registering a connection

Immuta utilizes connections to register and manage data from your Teradata environment. Instead of registering individual databases, connections enable you to register an entire data platform at once. This approach simplifies data registration and allows Immuta to automatically monitor your Teradata platform for changes. Data sources are then added or removed to reflect the current state of your data platform.

When the connection is registered, Immuta ingests and stores connection metadata in the Immuta metadata database. In the example below, the Immuta application administrator connects the database that contains marketing-data, research-data, and cs-data views. Immuta registers these views as data sources and stores the view metadata in the Immuta metadata database. Creating the connection does not impact any user's existing access in Teradata until subscription policies are applied to the views.

Immuta presents a hierarchical view of your data that reflects the hierarchy of objects in Teradata after registration is complete:

• Host

• Database

• View

Beyond making the registration of your data more intuitive, connections provides more control. Instead of performing operations on individual schemas or views, you can perform operations (such as object sync) at the connection level.

See the Connections reference guide for details about connections and how to manage them. To configure your Teradata connection, see the Register a Teradata connection guide.

Applying policies

Immuta enforces read subscription policies on Teradata views by issuing SQL statements in Teradata that grant and revoke access to views according to the policy.

When a user is subscribed to a view registered in Immuta,

1. Immuta creates a role for that user in Teradata, if one doesn't already exist. The role will be .

2. Teradata stores that role in its internal system catalog.

3. Immuta issues grants to that user's role in Teradata to enforce policy. The Protecting data page provides an example of this policy enforcement.

4. Immuta will then grant that personalized role to the Immuta user in Teradata. The Accessing data page provides details about how the user should set their Teradata roles.

5. The users will query data in Teradata, using SET ROLE ALL, which allows them to use the privileges from all roles that have been granted to them including the immuta_<username> role and their current active primary role.

See the Subscription policy access types page for details about the Teradata privileges granted to users when they are subscribed to a data source protected by a subscription policy.

Teradata privileges

The privileges that the Teradata connection requires align to the least privilege security principle. The table below describes each privilege required by the and the user.

Teradata privilege	User requiring the privilege	Explanation
DBADMIN in Teradata	Setup user	This privilege allows the user registering the connection to assign SELECT privileges to the Immuta system account so that it can register and manage the connection.
SELECT on the DBC database	Immuta system account	This privilege provides access to all the Teradata system views necessary to register the connection and maintain state between the Teradata database and Immuta.
SELECT WITH ADMIN OPTIONon all Teradata views that Immuta should manage permissions to	Immuta system account	This privilege allows Immuta to grant the roles it creates access to the views where subscription policies are applied.
CREATE ROLE and DROP ROLE	Immuta system account	Because Teradata privileges are granted to roles, this privilege is required so that Immuta can create Teradata roles and manage role membership to enforce access controls.

Maintaining state with Teradata

The following user actions spur various processes in the Teradata connection so that Immuta data remains synchronous with data in Teradata. The list below provides an overview of each process:

• Data source created: Immuta registers data source metadata and stores that metadata in the Immuta metadata database.

• Data source deleted: Immuta deletes the data source metadata from the metadata database.

• User account is mapped to Immuta: When a user account is mapped to Immuta, their metadata is stored in the metadata database.

• User subscribed to a data source: When a user is added to a data source by a data owner or through a subscription policy, Immuta creates a role for that user (if a role for them does not already exist) and grants Teradata privileges to their role.

• Automatic subscription policy applied to or updated on a data source: Immuta calculates the users and data sources affected by the policy change and grants or revokes users' privileges on the Teradata view. See the Protecting data page for details about this process.

• Subscription policy deleted: Immuta revokes privileges from the affected roles.

• User removed from a data source: Immuta revokes privileges from the user's role.

Supported object types

Views are the only supported object type for Teradata. See an outline of privileges granted by Immuta on the Subscription policy access types page.

Object type	Subscription policy support	Data policy support	Marketplace support
View	✅	❌	✅

Immuta will not ingest the following objects:

• Teradata databases without any views. If a database does not contain any views, it will not be ingested into Immuta.

• Views and databases created by the following system users: DBC, SYSADMIN, and SYSTEMFE. Views from these users will be ignored by object sync and will not be ingested into Immuta.

Supported policies

The Teradata connection allows users to author subscription policies to enforce access controls. Data policies will not be enforced natively in the Teradata platform.

See the applying policies section for details about policy enforcement.

Security and compliance

Authentication methods

The Teradata connection supports the following authentication methods to register a connection. The credentials provided must be for an account with the permissions listed in the Register a Teradata connection guide.

• Username and password

• LDAP

• OAuth

User registration and ID mapping

The built-in Immuta IAM can be used as a complete solution for authentication and user entitlement. However, you can connect your existing identity management provider to Immuta to use that system for authentication and user entitlement instead. Each of the supported IAM protocols includes a set of configuration options that enable Immuta to communicate with the IAM system and map the users, permissions, groups, and attributes into Immuta.

For policies to impact the right users, the user account in Immuta must be mapped to the user account in Teradata. You can ensure these accounts are mapped correctly in the following ways:

• Automatically: If usernames in Teradata align with usernames in the external IAM and those accounts align with an IAM attribute, you can enter that IAM attribute on the app settings page to automatically map user IDs in Immuta to Teradata.

• Manually: You can manually map user IDs for individual users.

For guidance on connecting your IAM to Immuta, see the how-to guide for your protocol.

Limitations and known issues

• The following Immuta features are unsupported:

  • Data policies

  • Tag ingestion

  • Query audit

• In the data source data dictionary, the column types will be unknown.