Existing Cloudera Navigator audits are not transitioned to the Cloudera 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 Cloudera 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 Cloudera, 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.
