Transitioning Navigator audits
Existing Cloudera Navigator audits are not transitioned to the CDP cluster. To transition reports running against Navigator data to Apache Ranger and other resources you must review the available options.
To manage Navigator audits in a CDP Runtime cluster, consider the following options:
- Maintain legacy audits in Navigator
- You can continue to run
Navigator to access your existing audits (and/or metadata). If you
choose to keep Navigator running, make sure that its users don't add
content to the archived system rather than the new Atlas instance.
- Removing editing privileges from users. If Navigator is configured for LDAP or Active Directory authentication, you can modify users or groups to remove privileges for adding or editing metadata. For details, see Administering Navigator User Roles.
- Marking Navigator entities as stale. If you are managing more than one cluster in Navigator, you can mark entities from the upgraded cluster to indicate to users that the entities are no longer maintained in Navigator. One way to do this is to create a policy that assigns a tag to the entities from the upgraded cluster. For details, see Using Policies to Automate Metadata Tagging.
- Archive your Navigator audits
- When Cloudera Manager upgrades to
7.x, it maintains the database of Navigator audits. After the
upgrade, you can access audits through Navigator as normal; new
audits continue to be collected from CDH services.
When you upgrade a CDH cluster to Cloudera Runtime, the Navigator audits persist. However, services no longer produce audits for Navigator. You can continue to run Navigator to be able to access the audits; at some point—perhaps after your need for immediate access to the audits expires—you'll want to archive the audits. For details, see Maintaining Navigator Audit Server. At that point, if Cloudera Manager is not managing another CDH cluster, you can shut down Navigator.
- Transition audit reports and processes to Ranger
- In CDP, Ranger performs auditing against the data access policies defined for each
service. For example, if a Ranger policy allows only users from the Finance group to
access a particular Hive database, Ranger audits will show when those users accessed the
database successfully and when other users attempted to access the database and were
denied. While the Ranger audits are a significant subset of the audits performed by
Navigator, the format and content is different enough that Cloudera doesn't provide a
transition path for Navigator audits into the same repository as Ranger audits. When redirecting reports or processes to Ranger, you'll need to:
- Identify the audited information: does an equivalent exist in Ranger?
- Identify the method of accessing the audit data and map it to Ranger: Did the reporting application use the Navigator API? Did it access archived data or the Navigator audit database? Ranger provides an API to access audits; audit data is written to HDFS (under /ranger/audit/<component name>). 30 days of audit records are indexed in Solr. The audit events are stored in JSON format. For details, see Managing Auditing with Ranger.