Configuring audit filters in Ranger Admin Web UI

You can configure audit filter conditions for each service, using the Create/Edit Service option.

You can stop certain audit logs from being sent to destinations like SOLR and HDFS by setting up audit filters for a service using the Ranger Admin Web UI.

  1. In the Ranger Admin Web UI > Service Manager, click Add New Service or Edit (existing service).
  2. On Create/Edit Service, scroll down to Audit Filters.
    1. Verify that the Audit Filter option is checked.
      Optionally, define any of the following to include in the filter definition:
      Is Audited
      To store or not store a filter in the audit logs for a service. Values are:
      • Yes: Stores audit records in the defined audit destination.
      • No: Does not store audit records.
      Access Results
      To include that access result in the audit log filter. Values are:
      • Denied
      • Allowed
      • Not Determined
      Resource
      To include or exclude specific resources, such as databases, tables, or columns, from the audit log filter.
      Operations
      To include the action or operation in the audit log filter. Select specific operations to filter.
      Permissions
      Add or remove permissions:
      1. Click + in Permissions to open the Add dialog.
      2. Select/Unselect required permissions.
      Users, Groups, Roles
      To include one or multiple users/groups/roles in the audit log filter.
    2. Click Save.
  • For a service, the following audit filter is used to capture all ALLOWED audits for user systest:


  • The following filter specifies all DENIED audits to be audited:


  • The following is an example where all operations for users kafka and rangertagsync are NOT audited, configured for a Kafka service:


Audit filter evaluation order
Audit Filters, implemented as Ranger Policies, determine whether to audit an authorization request after it is processed by Tag/Resource-based Ranger policies. After an Audit Filter condition is fulfilled and executed for a request, no other audit filters are evaluated. If the evaluation dictates that the authorization request should be audited, an audit record is then added to the designated audit destination(s).
Audit filters with REST APIs
Audit filters can be configured through REST when creating or updating a service as well. The following are examples where you can use JSON to configure audit filters:
  • Audit all denied accesses
    The following audit filter specifies that any access with accessResult = DENIED will be audited:
    {
      "accessResult": "DENIED",
      "isAudited": true
    }
  • Do not audit access to path /unaudited
    The following audit filter specifies that access to the resource path /unaudited (recursively) will not be audited:
    {
      "resources": {
        "path": {
          "values": ["/unaudited"],
          "isRecursive": true
        }
      },
      "isAudited": false
    }
  • Do not audit access to database sys, table dump, by user user2
    The following audit filter specifies that access to resource database=> sys table=> dump by user “user2” will not be audited:
    {
      "resources": {
        "database": {
          "values": ["sys"]
        },
        "table": {
          "values": ["dump"]
        }
      },
      "users": ["user2"],
      "isAudited": false
    }
  • Do not audit actions listStatus and getfileinfo with access type execute
    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
    }
  • Do not audit access by user superuser1 and group supergroup1
    The following audit filter specifies that access by user "superuser1" and group "supergroup1" will not be audited:
    {
      "users": ["superuser1"],
      "groups": ["supergroup1"],
      "isAudited": false
    }
  • Do not audit access to any resource tagged as NO_AUDIT
    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
    }

Above are examples of individual filters. You can apply them together in JSON when using REST to create/update a service as well.