Audits

Running the Grey Matter sidecar alongside a service allows for the auditing of request traffic and security information.

Audits

circle-check
  1. The Grey Matter Sidecar emits audit data to a Kafka topic for easy observability.

  2. If Fabric is set up with an Edge, it pulls audit data from the PKI certificate, the IP address of the originating request, etc.

  3. This audit data--also called events or observables--allows for detailed event auditing of ingress and egress traffic, and process resource use.

Grey Matter Configuration

Auditing is configured on a sidecar via the Grey Matter observables filter. The information can be emitted to an Apache Kafka clusterarrow-up-right and visualized in a Kibana dashboard or can simply be emitted to stdout in the sidecar logs.

For a step by step to configure and visualize auditing in Grey Matter, see the Audits and Observables guides.

For more info on visualizing audits, see the Audit Proxy Observable Consumer section

circle-info

What about Splunk?

While the Grey Matter Sidecar does not support direct emission of events into Splunk, you can create or modify a consumer to provide that capability. Learn more.arrow-up-right

Indexing

Grey Matter does not index audit events directly into Elasticsearch. Instead, Grey Matter contains a Kafka consumer that reads Kafka observables. This consumer transforms and indexes them to use with Elasticsearch.

Use Kibana to Visualize Observables

Kibana is an open source Elasticsearch plugin that takes observables from Grey Matter and visualizes them in a graphical dashboard.

Kibana simplifies the creation of visualizations to explore, search, view, and interact with audit data stored in Elasticsearch indices. Kibana helps you analyze and visualize individual events and trends such as:

  • Total requests

  • Number of requests by individual users

  • Geographic locations of requests made in Fabric

  • What individual users are doing

  • Timing of user requests

  • What user are looking at

  • user DNs (Authenticated user names)

  • Geographic location of IP addresses

  • Requests per hour by user

  • Response codes

  • Paths

  • Service vs. userDN

  • Services

  • Response bodies

  • User agents

Observable Information

The list information in a Grey Matter observables can be found here.

The following observable information was captured from a user accessing an event through a Sidecar operating within Grey Matter Fabric:

Audit Proxy Observable Consumer (APOC)

The Audit Proxy Observable Consumer (APOC) reads from Kafka and submits the information to Elasticsearch asynchronously for maximum throughput. When deploying with the ELK stack, Logstasharrow-up-right operates as the APOC.

APOC's goals include:

  • Listening to given Kafka topic(s)

  • Taking every event that is emitted into Kafka

  • Transforming those events

  • Submitting them to a given Elasticsearch index

Message Transformation

When a message is transformed by the APOC, event mappings are also added. The message will default to the following HTTP types found below:

The message can also be changed for individual routes by adding the following settings:

During the transformation action_locations are added to the audit event. These consist of an IP address identifier based on the x-forwarded-for in the header of the request.

action_targets is added consisting of {x=forwarded-proto}://{:authority}{x-envoy-original-path}.

Determine Value of Creator

A creator is then added to the auditing payload, and follows these steps to determine its value.

  • Allow for configuring an override default to that in the environment variable or settings.yaml or JSON.

  • If there is a request header named application , use it.

  • See if there is a request header named service , use it.

  • Extrapolate the name if the request url contains /apps/{value}/ or /services/{value}/ x-envoy-original-path.

  • Hard code a default. For instance, you could use service if none of the previous parameters are set.

In this configuration, the transformation will try to find user information in the request header and set action_initiator to be the userdn from the request. time_audited is also added to the audit information. This is the system time at which the audit transformation is completed by the APOC. Finally, if a GEO_DATABASE is supplied, the transformation will try to find the geographical location of the request based on the last IP address in the x_forwarded_for header field. The full information is added to the audit information as geo_ip, but basic location (lat and long) is added as location.

Questions

circle-check

Last updated

Was this helpful?