on 08-17-2023 02:53 PM
The Incorta admin user account is a super user with special privileges to govern and administer the platform. It is important to understand the role of an administrator before deploying Incorta in your environment. In this article, we discuss the best practices concerning the use of the admin user account. Take note that Incorta provides separate admin users for the main analytics platform and the CMC (Cluster Management Console). There could be a potential overlap of management functions between these two roles in some areas. The focus of this article is on the admin user responsible for the analytics platform.
The usage of the admin user should be understood in the larger context of building and securing the Incorta platform.
Some of the common tasks performed by an Incorta administrator are:
The following best practices span the list of typical activities managed by Incorta Administrators.
A common task for administrators is to manage users. Here are some best practices for managing Incorta users.
Recommendation | Comments |
Grant permissions via Groups
|
Only grant permissions to groups, not to individuals. This allows you to manage roles and permissions at the group level instead of the user level which will save time and provide better control. |
Set up user admins |
As long as user admins are trained to properly maintain users and permissions at the group level, this will reduce the burden of user maintenance if maintaining users and groups in Incorta directly. |
Use a directory service to sync user data |
Integrate Incorta with LDAP or another service to maintain users and groups centrally instead of in Incorta directly. |
Use preexisting user and group processes |
Use the same group definitions in Incorta that you use in your source system to manage Incorta content access in the same way. This provides continuity for your users as well. |
Limit admin access |
Limit the number of users with admin credentials to one or at most 2-3 trained administrators so that you have backups in case the primary admin is unavailable. This minimizes the chances that changes to the system can be made anonymously. |
Update the admin password regularly |
Update the admin password regularly as per your security policy. Alternatively, use SSO to eliminate the need to maintain user passwords in Incorta. |
Do not use generic or shared accounts for users |
Every new Incorta user account should be identified to a specific user from the company directory. Do not allow users to share accounts. This will enable you to audit Incorta usage. Use SSO to eliminate this threat. |
Assign correct privileges to users |
Make sure to assign only the appropriate permissions to Incorta users. Review platform permissions periodically to make sure they are correct (see metadata dashboard). See these Security Guidance Articles for more suggestions. |
Remove users who no longer use Incorta |
Delete or deactivate the privileges of users who no longer use Incorta. When you delete, you can assign any objects/content owned by these users to the appropriate still active user. |
Having common standards for your Incorta configuration will streamline object creation and will make it easier to understand the work done by others.
Recommendation | Comments |
Follow standard naming conventions
|
Develop and follow standard naming conventions when naming objects in Incorta. Use these articles for reference: |
Name data sources by source not by environment |
Do not use names like “UAT” or “Prod” when naming data sources as these will be migrated with the same name to all of your environments even if you do not, for example, intend to allow access to production data in your UAT environment. |
Administrators should administer different environments for different purposes.
Recommendation | Comments |
Maintain separate Dev and Production environments |
Maintain different environments for different purposes so that, for example, development work does not get interrupted by UAT work. There should be a minimum of two environments with Production having its own right sized cluster. |
Use Prod equivalent cluster for testing |
It is best to have at least one other environment that is sized and configured the same way as your production cluster so that you can fully test the impact of changes that you plan to introduce into Production. |
Control content creation in Production |
To prevent the possibility of Production activities being impacted, development and testing work should take place in a lower environment and users with the privileges of adding objects (schemas, dashboards) should be limited in Prod. |
Use Change Management Requests |
Establish or take advantage of existing change management processes (e.g. from an inhouse IT desk/Training Dept) when introducing new use cases to Production. |
The Incorta tenant can be used to restore or migrate all of the configuration you have created separately from the data. It is important to extract and back it up on a regular basis in case an issue occurs.
Recommendation | Comments |
Back up the tenant regularly |
Schedule tenant backups from the CMC daily or more frequently. Incorta can maintain up to 30 tenant revisions. |
Disaster Recovery |
Consider implementing a Disaster Recovery (DR) environment. In the event of a crash, there may be data (snapshot data for example) that cannot be recovered by running full data loads. Backing up the data files can be implemented as part of a DR strategy. |
Backup objects when working on them |
It is a good idea to extract a copy of an object before performing changes to the object so that it can be easily restored if needed. |
Good communication is always important and will keep your Incorta users happy.
Recommendation | Comments |
Notify your users of scheduled down times |
Use the appropriate notification channel to make sure your users know about planned outages ahead of time. Downtime may be required for upgrades to the Incorta software or Incorta infrastructure or even for content migration. |
Account of load schedule stoppage |
Make it clear in your communication if the load schedule will be stopped in advance of Incorta being taken down and when normal loads have resumed. |
It is important to monitor Incorta to prevent degradation of user experience.
Recommendation | Comments |
Monitor processes |
Like any application, Incorta should be monitored for activity that requires intervention. See this article on what to monitor in Incorta. You can also check out the Monitoring and Hardening Your Environment and Security sections of the Best Practices index on Community. |
Create alerts |
Use alerts to notify you of data or other conditions that may require you to take action. See this Alerting article for suggestions on what to implement. |
Inform object owners of unused objects and regularly clean them up to minimize your Incorta footprint and make it easier to organize your content.
Recommendation | Comments |
Identify Unused Objects |
Use the Unused Objects dashboard which comes with Incorta Tools to find the objects that get little to no usage. Refer to this article for the advantages of and how to use the dashboard. |
Delete Users |
The admin can delete users and at that time can review and reallocate ownership of the content they owned. If not needed, the content can be assigned to the admin who can then delete it after taking a backup |
Incorta, for security purposes, does not allow any one user to edit or even view all content automatically from the Incorta UI. This means that the admin user may not see or be aware of all entities that have been created.
Recommendation | Comments |
Share all content with the admin group |
If you would like the admin to have access to all content in Incorta, define and document a process in which all Incorta object creators are trained to share what they create with the admin group. |
Use Incorta Tools to identify all objects |
Incorta provides a dashboard with the Incorta Tools that helps administrators identify entities that they would not be able to see otherwise and their owners. Once identified, you can work with the owner of the object to have them share it with you or assume their identity to share it. |