Management of Users, Authorizations, Groups, and Permissions
Permission and Authorization Overview
Audience: System Administrators
Content Summary: System Administrators are responsible for managing users and their permissions, authorizations, and groups. This page defines and explains how permissions, authorizations, and groups work in Immuta.
Permissions are a system-level mechanism that control what actions a user is allowed to take. These are applied to
both the API and UI actions.
Permissions can be added to any user by a System Administrator (any user with the
ADMIN permission), but the permissions
themselves are managed by Immuta and cannot be added or removed in the Immuta UI; however, custom permissions
can be created in the Immuta Configuration Builder.
- CREATE_DATA_SOURCE: Gives the user the ability to create data sources.
- CREATE_PROJECT: Gives the user the ability to create projects.
- ADMIN: Gives the user access to administrative actions. These include:
- AUDIT: Gives the user access to the audit logs.
- GOVERNANCE: Gives the user the ability to act as a Governor.
- IMPERSONATE_HDFS_USER: When creating an HDFS data source, this allows the user to enter any HDFS username to access data.
- CREATE_S3_DATASOURCE_WITH_INSTANCE_ROLE: When creating an S3 data source, this allows the user to the handler to assume an AWS role when ingesting data.
Authorizations are custom tags that can be added to a user to restrict what data the user can see. When creating a policy on a data source, you can apply the policy to any user that possesses an authorization. Authorizations can be added manually as well as mapped in from LDAP or Active Directory.
Groups function similarly to those in Active Directory and LDAP, allowing System Administrators to group a set of users together. Users can belong to any number of groups and can be added or removed from groups at any time. Similar to authorizations, groups can be used to restrict what data a set of users has access to. When creating a policy on a data source, you can apply the policy to a group, which would affect any user that belongs to the said group. Permissions and authorizations cannot be applied to groups.
Audience: System Administrators
Content Summary: Any number of identity managers can be configured and enabled for an instance of Immuta. Each identity manager has a specific set of configurations that enable it to communicate with the IAM and map the users, permissions, groups, and authorizations into Immuta.
Each identity manager supports the configuration of default permissions. This configuration setting controls what permissions each user who logs in receives by default. These permissions are applied the first time each user logs in, and any changes to the default permissions will only apply to new users.
The list can contain any valid permissions or can be empty. In the case where the default permissions are empty, new users will receive no special permissions in Immuta and an administrator will need to grant them any permissions that they need.
In the example below, users logging in to Immuta for the first time using the
LDAP IAM will be granted two permissions:
plugins: ldap: id: ldap plugin: ldap displayName: LDAP IAM type: ldap defaultPermissions: - CREATE_DATA_SOURCE - CREATE_PROJECT
Identity managers can be configured for authentication only, group synchronization, authorization synchronization, or group and authorization synchronization:
supportedActions: : Authentication only. User will log in with the identity manager backend. User profile information (name, email, location, etc.) can be populated, but no groups or authorizations will be synced back. Immuta's built-in groups and authorizations can be assigned to the user.
supportedActions: ['syncGroups']: In addition to authentication and profile information, user groups will be populated from the identity manager, and Immuta's built-in authorizations can be assigned to the user.
supportedActions: ['syncAuthorizations']: User authentication, profile, and authorizations will be synced from the identity manager backend.
supportedActions: ['syncGroups', syncAuthorizations']: User authentication, profile, groups, and authorizations will be synced from the identity manager backend.
In the example below, the IAM will be used for authentication and group syncing.
plugins: ldap: id: ldap plugin: ldap displayName: LDAP IAM type: ldap supportedActions: ['syncGroups']
Hiding the Built-in Identity Manager
Once you have configured Immuta with an additional identity manager, you may want to hide the built-in Immuta option
from the login screen. You can do this by setting the
hideBim option in the Immuta configuration.
client: hideBim: true
If your only admin account was created using the built-in identity manager, make sure that you assign the
permission to a user from your configured IAM.
Custom IAM Integrations
Immuta's IAM connections are built with a pluggable NodeJS architecture. This architecture allows rapid development of a custom IAM integration to suit your specific needs.
If you plan to implement a custom IAM integration, contact your Immuta support professional for required source code access, full API documentation, and implementation guidance.
- Email Notifications: Provides instructions for configuring email notifications for users.
- Immuta HDFS Principals: Provides instructions for assigning HDFS principals to users.
- ODBC Drivers: Outlines the data source handlers configuration and lists drivers supported by Immuta.
- Permissions and Authorizations Overview: Defines and explains how permissions, authorizations, and groups work in Immuta
- HA Database Configuration Changes: Outlines how to change the PostgreSQL settings, connect to the database container, modify the configuration, and apply changes and restart the cluster
- External Catalogs Configurations: outlines configuration and examples for Collibra integration, Apache Atlas integration, and Waterline Data integration.
- User Impersonation: Details how to create an impersonation user.
- Identity Managers: Contains general information about configuring default permissions and supported actions for enterprise IAMs, hiding the built-in Immuta IAM, and implementing custom IAM integrations. This section also includes documentation for specific identity managers.