Lifecycle and Security Auditing
Minimum Required Role: Auditor (also provided by Full Administrator)
An audit event is an event that describes an action that has been taken for a cluster, host, license, parcel, role, service or user.
Cloudera Manager records cluster, host, license, parcel, role, and service lifecycle events (activate, create, delete, deploy, download, install, start, stop, update, upgrade, and so on), user security-related events (add and delete user, login failed and succeeded), and provides an audit UI and API to view, filter, and export such events. The Cloudera Manager audit log does not track the progress or results of commands (such as starting or stopping a service or creating a directory for a service), it just notes the command that was executed and the user who executed it. To view the progress or results of a command, follow the procedures in Viewing Running and Recent Commands.
The Cloudera Navigator Audit Server records service access events and the Cloudera Navigator Metadata Server provides an audit UI and API to view, filter, and export both service access events and the lifecycle and security events retrieved from Cloudera Manager. For information on Cloudera Navigator auditing features, see Exploring Audit Data Using the Cloudera Navigator Console.
Viewing Audit Events
Audit event entries are ordered with the most recent at the top.
Audit Event Properties
- Date - Date and time the action was performed.
- Command - The action performed.
- Source - The object affected by the action.
- User - The name of the user that performed the action.
- IP Address - The IP address of the client that initiated the action.
- Host IP Address - The IP address of the host on which the action was performed.
- Service - The name of the service on which the action was performed.
- Role - The name of the role on which the action was performed.
Filtering Audit Events
You filter audit events by selecting a time range and adding filters.
You can use the Time Range Selector or a duration link ( ) to set the time range. (See Time Line for details). When you select the time range, the log displays all events in that range. The time it takes to perform a search will typically increase for a longer time range, as the number of events to be searched will be larger.
Adding a Filter
- Click the icon that displays next to a property when you hover in one of the event entries. A filter containing the property, operator, and its value is added to the list of filters at the left and Cloudera Manager redisplays all events that match the filter.
- Click the Add a filter link. A filter control is added to the list of filters.
- Choose a property in the drop-down list. You can search by properties such as Username, Service, Command, or Role. The properties vary depending on the service or role.
- If the property allows it, choose an operator in the operator drop-down list.
- Type a property value in the value text field. To match a substring, use the like operator and specify % around the string. For example, to see all the audit events for files created in the folder /user/joe/out specify Source like %/user/joe/out%.
- Click Search. The log displays all events that match the filter criteria.
- Click to add more filters and repeat steps 1 through 4.
Downloading Audit Events
You can download audit events in CSV formats.
- Specify desired filters and time range.
- Click the Download CSV button. A file with the following fields is downloaded: service, username, command, ipAddress, resource, allowed,
timestamp, operationText. The structure of the resource field depends on the type of the service:
- HDFS - A file path
- Hive, Hue, and Cloudera Impala - database:tablename
- HBase - table family:qualifier
HDFS Service Audit Log
service,username,command,ipAddress,resource,allowed,timestamp hdfs1,cloudera,setPermission,10.20.187.242,/user/hive,false,"2013-02-09T00:59:34.430Z" hdfs1,cloudera,getfileinfo,10.20.187.242,/user/cloudera,true,"2013-02-09T00:59:22.667Z" hdfs1,cloudera,getfileinfo,10.20.187.242,/,true,"2013-02-09T00:59:22.658Z"
In this example, the first event access was denied, and therefore the allowed field has the value false.