.png)
- Article History
- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
on 08-17-2023 02:53 PM
Introduction
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.
What you need to know before reading this article
The usage of the admin user should be understood in the larger context of building and securing the Incorta platform.
Let's Go
Admin User - Common Tasks
Some of the common tasks performed by an Incorta administrator are:
- Manage users and access
- Manage data sources
- Manage Schemas, Business Schemas, Content access, Content configurations and Loading schedules
- Review, monitor and audit platform usage
- Work alongside infrastructure owners and the Incorta application owner for upgrades and patch fixes
- Migrate content and support content development
- Integrate with other systems
- Perform Cluster Management Console (CMC) administration tasks
- Troubleshoot issues, work with Incorta Support
Admin User - Best Practices
The following best practices span the list of typical activities managed by Incorta Administrators.
Manage Users and Access Permissions
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. |
Create and Maintain Incorta Development Guidelines
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. |
Maintain Multiple Environments
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. |
Back up Incorta Tenant Regularly
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. |
Communicate Service Downtime
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. |
Monitor Incorta
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. |
Clean up Unused Objects
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 |
Share with Admin Users
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. |
Related Material
- Best Practice Articles
- Administer Incorta
- Administrator Training
- Physical Schema Naming Conventions
- Business Schema Naming Conventions
- Tenant Backup
- Disaster Recovery
- Snapshot Data
- Monitoring Incorta
- Alerting
- Delete Users
- Maximizing Memory Available by Removing Unused Entities