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.
Consider:
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.
