Overview
This document describes Flipt’s auditing capabilities.
Audit Events are pieces of data that describe a particular thing that has happened in a system. Flipt provides the functionality of processing and batching these audit events and an abstraction for sending these audit events to a sink.
Events
Flipt supports sending audit events to configured sinks. Audit events have the following structure:
version
: the version of the audit event structure.type
: the type of the entity being acted upon (flag, variant, constraint, etc.)action
: the action taken upon the entity (created, deleted, updated, etc.)metadata
: extra information related to the audit event as a whole. Theactor
field will always be present containing some identity information of the source which initiated the audit eventpayload
: the actual payload used to interact with theFlipt
server for certain auditable eventstimestamp
: the time the event was createdstatus
: the status of the event (success, denied, etc.)
Currently, we support the following sinks for audit events:
-
Log: the audit events are output as either
json
orconsole
depending on configuration. The default output is to STDOUT, however, the log sink can also be output to a file. -
Webhook: the audit events are sent to a URL of your choice.
-
Kafka: the audit events are sent to a Kafka topic of your choice.
You can find examples in the main GitHub repository on how to enable audit events and how to tune configuration for it.
Event Filtering
You can specify configuration for which events you would like to receive on your audit sink.
An always up to date list of events supported is available in our GitHub repository.
Events are specified in the format of noun:verb
. You can also specify a wild card for either the noun or the verb. For instance *:created
corresponds to all created
events for every entity. Furthermore, flag:*
corresponds to all flag
events, and *:*
corresponds to every single event.
Examples of configuring events include:
Authentication / Authorization
If authentication is enabled, the actor field will contain the identity information of the source which initiated the audit event. This information may contain the user’s email, IP address, and other relevant information.
If authorization is enabled, the audit event will contain the result of the authorization check in the status
field. The status field will be set to success
if the authorization check passed, and denied
if the check failed. This information can be used to determine if an unauthorized user attempted to perform an action.