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": "0.2",
  "type": "flag",
  "action": "created",
  "status": "success",
  "metadata": {
    "actor": {
      "authentication": "none",
      "ip": "172.17.0.1"
    }
  },
  "payload": {
    "description": "flipt flag",
    "enabled": true,
    "key": "flipt",
    "name": "flipt",
    "namespace_key": "default"
  },
  "timestamp": "1970-01-01T00:00:00Z"
}
  • 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. The actor field will always be present containing some identity information of the source which initiated the audit event
  • payload : the actual payload used to interact with the Flipt server for certain auditable events
  • timestamp: the time the event was created
  • status: 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 or console 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:

flag:created
namespace:created
flag:*
rollout:deleted
rule:deleted
*:updated

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.