App Settings Tutorial
Audience: Application Admins
Content Summary: This page details how to use the App Settings page to configure settings for Immuta for your organization.
Navigating to the App Settings Page
Click the App Settings icon in the left sidebar.
Click the link in the Configuration panel to navigate to that section.
Identity and Access Management (IAM)
To configure Immuta to use your organization's existing IAM,
- Click the Add IAM button.
Complete the Display Name field and select your IAM type from the Identity Provider Type dropdown: LDAP/Active Directory, SAML, or OpenID.
Adding LDAP or Active Directory
Once you have selected LDAP/Active Directory from the Identity Provider Type dropdown menu,
- Adjust Default Permissions granted to users by selecting from the list in this dropdown menu, and then complete the required fields in the Credentials and Options sections. Note: Either User Attribute OR User Search Filter is required, not both. Completing one of these fields disables the other.
- Opt to Enable Debug Logging or Enable SSL by clicking the checkboxes.
- In the Profile Schema section, map attributes in LDAP/Active Directory to automatically fill in a user's Immuta profile. Note: Fields that you specify in this schema will not be editable by users within Immuta.
Opt to Link SQL Account, Sync groups from LDAP/Active Directory to Immuta, Sync attributes from LDAP/Active Directory to Immuta, enable External Groups and Attributes Endpoint, or Make Default IAM by selecting the checkbox, and then click the Test Connection button.
Note: If you select Link SQL Account, you will need to update the Query Engine configuration.
Once the connection is successful, click the Test User Login button.
Once you have selected SAML from the Identity Provider Type dropdown menu,
- Adjust Default Permissions granted to users by selecting from the list in this dropdown menu, and then complete the required fields in the Client Options section.
- In the Profile Schema section, map attributes in SAML to automatically fill in a user's Immuta profile. Note: Fields that you specify in this schema will not be editable by users within Immuta.
- Opt to select the Allow Identity Provider Initiated Single Sign On, Sync groups from SAML to Immuta, Sync attributes from SAML to Immuta, or External Groups and Attributes Endpoint checkboxes, and then click the Test Connection button.
- Once the connection is successful, click the Test User Login button.
Once you have selected OpenID from the Identity Provider Type dropdown menu,
- Adjust Default Permissions granted to users by selecting from the list in this dropdown menu, and then complete the rest of the required fields in the first section.
- Add the Client ID and Client Secret.
- Make note of the Redirect URL, and ensure that it is set appropriately in the OpenID provider application configuration.
- Configure OpenID provider settings. There are two options:
- Set Discover URL to the
/.well-known/openid-configurationURL provided by your OpenID provider.
- If you are unable to use the Discover URL option, you can fill out Authorization Endpoint, Issuer, Token Endpoint, JWKS Uri, and Supported ID Token Signing Algorithms.
- Set Discover URL to the
- If necessary, add additional Scopes.
- In the Profile Schema section, map attributes in OpenID to automatically fill in a user's Immuta profile. Note: Fields that you specify in this schema will not be editable by users within Immuta.
- Opt to select the Allow Identity Provider Initiated Single Sign On or External Groups and Attributes Endpoint checkboxes.
- Click the Test Connection button.
- Once the connection is successful, click the Test User Login button.
To set the default permissions granted to users when they log in to Immuta, click the Default Permissions dropdown menu, and then select permissions from this list.
To link Immuta to your organization's enterprise data catalog system,
- Click the Add Catalog button.
- Enter the URL to the external catalog in the URL field.
- Complete the Username and Password fields. Note: This is the username and the password that Immuta can use to connect to the external catalog.
- Click the Test Connection button.
Note: Google Data Catalog requires additional steps to link with Immuta. See detailed instructions below.
Adding Google Data Catalog as an External Catalog
Prerequisite: Create a service account by following Google Cloud Platform's instructions and download the JSON file containing your Google Service Account key.
- In the Immuta console, navigate to the App Settings page and click External Catalogs in the left panel.
- Click Add Catalog and select Google Data Catalog from the dropdown menu.
Upload your Google Service Account key.
Opt to select any of the following checkboxes:
- Keep true and false values as leaf tags
- Don't import tags that have numeric values
- Don't import tags that have datetime values
Click Test Connection and Save the updated configuration.
Now, when a data source is created from a table in BigQuery, Immuta will import any tags that have been applied to the table in Google Data Catalog.
Working with Tags from Multiple Google Cloud Platform Projects
By default, service accounts only have access to resources (such as tags) in the project where they are created. However, tags from different projects can be applied to a single table by using a tag template in Google Data Catalog.
To allow Immuta to import tags from other projects,
- In Google Data Catalog, navigate to an additional project with tags that have been applied to a table.
- Select the IAM & Admin tab from the navigation menu.
- Click the Add User button in the top left of the screen.
- Enter the email associated with the created service account. This address can be found in the downloaded JSON key file or in the IAM section of the original project.
- Select the TagTemplateUser role from the dropdown menu to allow access to tags.
Immuta will now import tags from this project. Further details and instructions about the TagTemplateUser role and tag templates can be found in Google Cloud Platform documentation.
To enable external masking,
- Navigate to the App Settings page and click External Masking in the left sidebar.
Click Add Configuration and specify an external endpoint in the External URI field.
Click Configure, and then add at least one tag by selecting from the Search for tags dropdown menu. Note: Tag hierarchies are supported, so tagging a column as
Sensitive.Customerwould drive the policy if external masking was configured with the tag
Select Authentication Method and then complete the authentication fields (when applicable).
- Click Test Connection and then Save.
You can enable or disable the types of data sources users can create in this section. Some of these types will require you to upload an ODBC driver before they can be enabled. The list of currently supported drivers is on the ODBC Drivers page.
To enable a data provider,
Click the menu button in the lower right corner of the provider icon you want to enable.
Select Enable from the dropdown.
If an ODBC driver needs to be uploaded,
Click the menu button in the lower right corner of the provider icon, and then select Upload Driver from the dropdown.
Click in the Add Files to Upload box and upload your file.
- Click the menu button again, and then select Enable from the dropdown.
Application Admins can configure the SMTP server that Immuta will use to send emails to users. If this server is not configured, users will only be able to view notifications in the Immuta console.
To configure the SMTP server,
- Complete the Host and Port fields for your SMTP server.
- Enter the username and password Immuta will use to log in to the server in the User and Password fields, respectively.
- Enter the email address that will send the emails in the From Email field.
- Opt to Enable TLS by clicking this checkbox, and then enter a test email address in the Test Email Address field.
Finally, click Send Test Email.
Once SMTP is enabled in Immuta, any Immuta user can request access to notifications as emails, which will
vary depending on
the permissions that user has. For example, to receive email notifications about group membership changes, the
receiving user will need the
GOVERNANCE permission. Once a user requests access to receive emails, Immuta will
compile notifications and distribute these compilations via email
at 10-minute intervals.
To configure Immuta to protect data in a kerberized Hadoop cluster,
Upload your Kerberos Configuration File, and then you can add modify the Kerberos configuration in the window pictured below.
Upload your Keytab File.
- Enter the principal Immuta will use to authenticate with your KDC in the Username field. Note: This must match a principal in the Keytab file.
- Adjust how often (in milliseconds) Immuta needs to re-authenticate with the KDC in the Ticket Refresh Interval field.
- Click Test Kerberos Initialization.
HDFS Cache Settings
To improve performance when using Immuta to secure Spark or HDFS access, a user's access level is cached momentarily. These cache settings are configurable, but decreasing the Time to Live (TTL) on any cache too low will negatively impact performance.
To configure cache settings, enter the time in milliseconds in each of the Cache TTL fields.
System API Key
If you are using Immuta to protect data in a Hadoop cluster, you will need to configure the HDFS name node with a system API key.
To do so,
- Click the Generate Key button.
- Save this API key in a secure location, and then follow the instructions in the
Hadoop Installation Guide to set the
immuta.system.api.keyproperty in the name node configuration.
You can set the URL users will use to access the Immuta Application and Query Engine. Note: Proxy configuration must be handled outside Immuta.
- Complete the Public Immuta URL, Public Query Engine Hostname, and Public Query Engine Port fields.
Opt to Enable SSL by clicking this checkbox.
Sensitive Data Detection
Select the Enable Sensitive Data Detection checkbox to automatically discover and tag columns with sensitive data when users create data sources.
Click the Allow Policy Exemptions checkbox to allow users to specify who can bypass all policies on a data source.
Governor and Admin Settings
These options allow you to restrict the power individual users with the GOVERNANCE and USER_ADMIN permissions have in Immuta. Click the checkboxes to enable or disable these options.
You can create custom permissions that can then be assigned to users and leveraged when building subscription policies. Note: You cannot configure actions users can take within the console when creating a custom permission, nor can the actions associated with existing permissions in Immuta be altered.
To add a custom permission, click the Add Permission button, and then name the permission in the Enter Permission field.
Data Source Access Requests
To create a custom questionnaire that all users must complete when requesting access to a data source, fill in the following fields:
- Key: Any unique value that identifies the question.
- Header: The text that will display on reports.
- Label: The text that will display in the questionnaire for the user.
To create a custom message for the login page of Immuta, enter text in the Enter Login Message box. Note: The message can be formatted in markdown.
Opt to adjust the Message Text Color and Message Background Color by clicking in these dropdown boxes.
Native Snowflake Workspace
- Check the Enable checkbox in the Native Snowflake Workspace section.
Complete the Host, Port, and Default Warehouse fields.
Select Automatic or Manual by clicking the toggle.
- Automatic: provide Immuta with privileged user credentials for an automatic installation.
- Manual: download the linked
bootstrap.sqlfile and manually configure Snowflake environment.
When performing an automated installation, the credentials provided must have the ability to both CREATE databases and CREATE, GRANT, REVOKE, and DELETE roles. In a typical Snowflake environment, the only users with access to the necessary permissions are those who have the ACCOUNTADMIN role.
If you run a manual setup using the
bootstrap.sqlfile, you should only replace the
##IMMUTA_PASSWORD##value. Changing the login name, system role, or system user we create is not supported and will break the integration.
If you need to add additional project warehouses after you've already enabled the integration, you will need to do so in the Advanced Configuration section:
nativeSnowflake: projectWarehouses: - WAREHOUSE_ONE - WAREHOUSE_TWO - WAREHOUSE_THREE
Click Test Snowflake Connection.
- Once the credentials are successfully tested, click Save.
Users will now have the option to create new Projects with Native Snowflake Workspaces and enable Snowflake Workspaces on existing equalized Projects.
Advanced configuration options provided by the Immuta Support team can be added in this section. The configuration must adhere to the YAML syntax.
Updating the K-Anonymity Cardinality Cutoff
To increase the default cardinality cutoff for columns compatible with k-anonymity,
Expand the Advanced Settings section and add the following text to the Advanced Configuration:
plugins: postgresHandler: maxKAnonCardinality: 10000000 snowflakeHandler: maxKAnonCardinality: 10000000
- To regenerate the data source's fingerprint, navigate to that data source's Policy tab.
Click the dropdown menu to the right of Data Policies and select Policy Availability.
Click Recalculate in the Fingerprint section of the window that appears.
Note: Recalculating the fingerprint is only necessary for existing data sources. New data sources will be generated using the new maximum cardinality.
Deploying Configuration Changes
When you are ready to finalize your configuration changes, click the Save button at the bottom of the left panel