Guides
Start typing to search…

Integration with Other Logging Frameworks

The TSM allows integrating the audit logging with other log frameworks. This can be done with the fluentd service:

The fluentd service allows taking inputs from multiple different sources and sending it to different other log systems, like e.g. Splunk or Cloudwatch.

Setting up the fluentd service

The fluentd service has a docker image that can be used to launch the service. The following docker-compose snippet should launch the service:

  auth-server:
    image: fluent/fluentd:edge-debian
    ports:
      - "9080:9080"
    networks:
      - tsm
    volumes:
      - ./config/:/fluentd/etc
      - ./logs/:/tmp/logs

This starts the service to listen on port 9080 and will load the configuration from the ./config directory. The ./logs/ directory is used to demonstrate how to write to files in the following output examples.

Configuration

This will only discuss some of the simple options when using the fluentd service. The service allows a multitude of different plugins, that allows it to communicate with a lot of different services. So check the documentation link above if something more complicated is needed.

The configuration need to be inserted into the file ./config/fluent.conf if the above docker-compose is used.

Input handler

To get the audit logs from the TSM, an input handler need to be defined. The port defined in the following examples need to match the port in the docker-compose. The simplest handler is just:

<source>
  @type http
  port 9080
  bind 0.0.0.0
</source>

This should automatically parse the input as JSON, due to the content type of the communication. If this however does not happen, a JSON parsing can be forced with the following:

<source>
  @type http
  port 9080
  bind 0.0.0.0
  <parse>
    @type json
  </parse>
</source>

Once this is inserted in the configuration file, the audit log events from the TSM will be handled in the fluentd server and raise log events the can be handled by the various plugins.

Output handler

Fluentd allows outputting logs to a long list of output plugins, which can be seen on the plugin page above. We will cover a few simple options here, that are mainly relevant for running the fluentd as a stand alone audit log server. If more advanced behavior is needed, then one of the plugins in the plugin list above can be used.

Output in fluentd is done in an match section. This can contain one or more output options. The first example here shows how to log to a single output, in json format, on stdout:

<match **>
  @type stdout

  <format>
    @type json
  </format>
</match>

If multiple outputs are used, then the type need to be copy. Each output option is then specified in different store sections. The following example shows how to log to two different file formats, while logging a shortened output to stdout:


<match **>
  @type copy

  <store>
    @type file
    path /tmp/logs/json
    <format>
      @type json
    </format>
  </store>

  <store>
    @type file
    path /tmp/logs/tag-value
    <format>
      @type ltsv
      delimiter "\t"
      label_delimiter " => "
    </format>
  </store>

  <store>
    @type stdout
    <format>
      @type csv
      fields timestamp,userID,algorithm,keyID,operation,parameters
      force_quotes false
    </format>
  </store>
</match>

If the signatures need to be validated, it is advised to save the log entries in JSON format. The JSON format allows using the audit validation described here. If JSON is not used, then the fields will need to be reconstructed and if any fields have been dropped or modified, then signature validation is not possible.

Setting up the TSM

To setup audit logging in the TSM simply add the [Audit] section to the configuration:

[Audit]
ReceiverURL="http://auth-server:9080"                             # The URL of the audit server
LogEntrySigningKeySeed="9L/49DsAFKtZrTFiq49T6j2LXlVU+6A0Nbw5FIWemVw=" # The seed for signing

The Signing key can be the same for all TSMs, but using separate signing keys will ensure that the entry came from the node that the key belonged to, so this is more secure.

Besides this the three options MaxBatchSize, MinWaitTime, and MaxWaitTime can be used to instruct the TSM how to upload entries.

If using HTTPS then ReceiverPublicKey can be used to specify the Audit (in this case the fluentd server) public key of the TLS protocol. If using mTLS, then ClientPrivateKey can be used to configure the client key.

For more information on these options, see the [Audit] section in the example file here.

Updated 19 days ago