Restricting access and granting specific permissions through role-based access controls is the first step to securing your infrastructure. The next step is to log all activity across your infrastructure. Learn more about audit logging for SSH and Kubernetes.
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:
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..
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.
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:
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.
Teleport reduces the operations and the support burden normally associated with
on-premises software. The product also decreases the time it takes to adopt open
source technology while enabling consistent application environments across deployments.
Teleport is open source and it relies on open standards such as X.509 certificates, HTTPS, SAML, OpenID connect and others. Deployed as a single-binary it seamlessly integrates with the rest of your stack.
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.
The tsh client allows users to login to retrieve short-lived certificates.
The teleport agent can be installed on any server or any Kubernetes cluster with a single command.
# on a client
$ tsh login --proxy=example.com
# on a server
$ apt install teleport
# in a Kubernetes cluster
$ helm install