No More Backdoors: Know Who Has Access to What, Right Now
Jun 13
Register Today
Teleport logoTry For Free
Background image
How Teleport Works

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": "",
"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

Recorded Sessions using

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 file system available to 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 blob storage such as Amazon S3.

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

Background image

Easy to get started

Teleport is easy to deploy and use. We believe that simplicity and good user experience are key to first-class security.

Teleport consists of just two binaries.
  1. The tsh client allows users to login to retrieve short-lived certificates.
  2. The teleport agent can be installed on any server, database, application and Kubernetes cluster with a single command.
Download Teleport
# on a client$ tsh login
# on a server$ apt install teleport
# in a Kubernetes cluster$ helm install
Background image

Try Teleport today

In the cloud, self-hosted, or open source
Get StartedView developer docs