Teleport Unified Access Plane

Audit Logging

Learn how Teleport keeps an audit log of access events for all SSH servers, Kubernetes clusters, and web applications.

The Basics

As the teleport daemon runs on every machine in a cluster, it detects security-related events and reports them to the cluster’s auth service. Generally, there are three types of information that can be collected for audit purposes:

  1. Access events. These include security-related events that happen “on the wire,” such as login attempts, remote command execution, access denied events, session creation, termination, etc..
  2. Session recordings. When users create interactive sessions via ssh or via kubectl exec -ti, these sessions are recorded and can be replayed later via a Youtube-like web interface with features like pause, rewind, etc.
  3. Host events. This is also called enhanced session recording. When enabled, host events allow Teleport to capture and store detailed low-level events that happen on a host during a user session, such as filesystem changes, network activity, process execution, etc. eBPF must be supported by the host kernel and BCC must be installed for this to work.

The diagram below illustrates two options (A and B) for how audit data is collected and stored:

Audit Log

Option A is called recording node. In this mode, each Teleport node sends the audit information to the auth service. This is the default and recommended method.

Option B is called recording proxy. In this mode, the Teleport Proxy service is sending the audit information to the auth service regarding all client connections.

You can read about additional considerations for picking the audit recording method in the documentation.

Audit Format

Teleport uses two data formats for the audit information:

  1. Security events such as access events and host events are stored as structured JSON documents. Teleport documentation better details their format. They are suitable for export and processing by external software.
  2. Recorded sessions contain the raw dump of stdout and stderr streams, including TAB characters (bash escape sequences). One can instantaneously replay a recorded session using cat command.

Event Data Example

{
    "event": "session.start",
    "user": "[email protected]",
    "login": "dba",
    "server_id": "f84f7386-5e22",
    "sid": "8d3895b6-e9dd",
    "addr.local": "10.5.l.15",
    "addr.remote": "73.223.221.14",
    "time": "2017-02-03T06:54:05Z"
}
        

Recorded Session Data Example

^[[94;1msmb^[[0;33m ~^[[00m: cd /usr/bin^M
^[[94;1msmb^[[0;33m /usr/bin^[[00m: ls^M
^[[94;1msmb^[[0;33m /usr/bin^[[00m: exit^M
logout^M






        

Recorded Sessions UI

Here’s what the session replay looks like:

How Teleport Works

Audit Storage

There are several options for storing audit information:

  • Both the security events and session recordings can be stored on a local file system of the auth service. This is the simplest option.
  • Security events can be stored in a cloud database such as DynamoDB, Google FireBase, and others.
  • Session recordings can be stored in cloud block storage such as AWS S3.

Teleport audit information can easily be injected into external logging and monitoring facilities such as Splunk, AlertLogic, ElasticSearch, and others.

What's Next

Try Teleport today

In the cloud, self-hosted, or open source

View developer docs

This site uses cookies to improve service. By using this site, you agree to our use of cookies. More info.