Ranger Audit Filters

You can use Ranger audit filters to control the amount of audit log data collected and stored on your cluster.

About Ranger audit filters

Ranger audit filters allow you to control the amount of audit log data for each Ranger service. Audit filters are defined using a JSON string that is added to each service configuration. The audit filter JSON string is a simplified form of the Ranger policy JSON. Audit filters appear as rows in he Audit Filter section of the Edit Service view for each service. The set of audit filter rows defines the audit log policy for the service. For example, the default audit log policy for the Hadoop SQL service appears in the in the Ranger Admin web UI Service Manager Edit Service when you scroll down to Audit Filter. Audit filter is checked (visible) by default. In this example, the top row defines an audit filter that causes all instances of "access denied" to appear in audit logs. The lower row defines a filter that causes no metadata operations to appear in audit logs. These two filters comprise the default audit filter policy for the Hadoop SQL service.

Default audit filters

Default audit filters for the following Ranger service appear in the Edit Services and can then be modified as needed by Admin users.

HDFS service:
HBase service:
Hadoop SQL service:
Knox service
Solr service
Kafka service:

KMS service

Atlas service
ADLS service:
Ozone service

S3 service

Tag-based service

Default audit filter policies do not exist for Yarn, NiFi, NiFi Registry, Kudu, or schema registry services.

Ranger audit filter policy configuration

To configure an audit filter policy, click the Edit icon for either a resource-, or tag-based service in the Ranger Admin web UI. You configure a Ranger audit filter policy by adding (+), deleting (X), or modifying each audit filter row for the service. The preceding example shows the Add and Delete icons for each filter row. To configure each filter in the policy, use the controls in the filter row to edit filter properties. For example, you can
choose Yes or No in Is Audited
to include or not include a filter in the audit logs for a service
choose DENIED, ALLOWED, or NOT_DETERMINED in Access Result
to include that access result in the audit log filter
add or delete a path in Ressorces
to include or remove the resource from the audit log filter
type an action name in Operations
to include the action/operation in the audit log filter
(click x to remove an existing operation)
click + in Permissions to open the Add permsisions dilaog
select read, write, execute or All, then choose Allow or Deny
to grant or revoke permissions to defined user, groups and/or roles defined in the audit log filter.
click Select User to see a list of defined users
choose one or multiple users to include in the audit log filter
click Select Group to see a list of defined groups
choose one or multiple groups to include in the audit log filter
click Select Role to see a list of defined roles
choose one or multiple roles to include in the audit log filter

Audit filter details

  • When you save the UI selctions described in the preceeding list, audit filters are defined as a JSON list. Each service references a unique list.

  • For example, ranger.plugin.audit.filters for the HDFS service includes:
    [ {'accessResult': 'DENIED', 'isAudited': true},
    
         {'users': ['unaudited-user1'], 'groups': ['unaudited-group1'], 'roles':['unaudited-role1'], 'isAudited': false}, 
    
         {'actions': [ 'listStatus', 'getfileinfo' ], 'accessTypes':['execute'], 'isAudited': false}, 
    
     {'resources':{'path':{'values':['/audited'],'isRecursive':true}},
    'isAudited': true},
         
    {'resources':{'path':{'values':['/unaudited'],'isRecursive':true}},'isAudited': false} ]
  • Each value in the list is an audit filter, which takes the format of a simplified Ranger policy, along with access results fields.
  • Audit filters are defined with rules on Ranger policy attributes and access result attributes.
    • Policy attributes: resources, users, groups, roles, accessTypes
    • Access result attributes: isAudited, actions, accessResult
  • The following audit filter specifies that accessResult=DENIED will be audited. The isAudited flag specifies whether or not to audit.
    {'accessResult': 'DENIED', 'isAudited': true}
  • The following audit filter specifies that “resource => /unaudited” will not be audited.
    {'resources':{'path':{'values':['/unaudited'],'isRecursive':true},
    'iAudited': false}
  • The following audit filter specifies that access to resource database=> sys table=> dump by user “use2” will not be audited.
    {'resources':{'database':{'values':['sys']},'table':{'values':dump']},
    'users':['user2'],'isAudited': false }
  • The following audit filter specifies that access result in actions => listStatus, getfileInfo and accessType => execute will not be audited.
    {{'actions': [ 'listStatus', 'getfileinfo' ], 'accessTypes':['execute'], 'isAudited': false}
  • The following audit filter specifies that access by user "superuser1" and group "supergroup1" will not be audited.
    {'users':['superuser1'],'groups':['supergroup1'], 'isAudited': false}
  • The following audit filter specifies that access to any resource tagged as NO_AUDIT will not be audited.
    {'resources':{'tag':{'values':['NO_AUDIT']}},'isAudited': false}

Ranger audit filters format

Audit filters consist of a subset of Ranger policy attributes, along with access results attributes. These attributes define the audit filter rules.

{'resources':
            {
            'database':{'values':['data','data2']},
            'table':{'values':['*']},
            'column':{'values':['*']}
            },
            'accessTypes':['select','insert'],
            'users':['user1','user2],
            'groups':['no_audit_group'],
            'roles' :['role1','role2'],
            'actions': ['METADATA OPERATION','SHOW_ROLES'],
            'accessResult': 'DENIED' or 'ALLOWED' or 'NOT_DETERMINED' or empty
            'isAudited' : false
            }