Changelog

6.0.0-alpha.2

Note: This version is a pre-release and is not recommended for production usage.

This release of Teleport contains a number of improvements and bug fixes.

6.0.0-alpha.1

Note: This version is a pre-release and is not recommended for production usage.

This release of Teleport introduces Database Access with PostgreSQL support.

See Database Access Preview docs for more information.

5.1.0

This release of Teleport adds a new feature.

5.0.2

This release of Teleport contains a security fix.

Any Enterprise SSO users using Okta, Active Directory, OneLogin or custom SAML connectors should upgrade their auth servers to version 5.0.2 and restart Teleport. If you are unable to upgrade immediately, we suggest disabling SAML connectors for all clusters until the updates can be applied.

5.0.1

This release of Teleport contains multiple bug fixes.

5.0.0

Teleport 5.0 is a major release with new features, functionality, and bug fixes. Users can review 5.0 closed issues on Github for details of all items.

New Features

Teleport 5.0 introduces two distinct features: Teleport Application Access and significant Kubernetes Access improvements - multi-cluster support.

Teleport Application Access

Teleport can now be used to provide secure access to web applications. This new feature was built with the express intention of securing internal apps which might have once lived on a VPN or had a simple authorization and authentication mechanism with little to no audit trail. Application Access works with everything from dashboards to single page Javascript applications (SPA).

Application Access uses mutually authenticated reverse tunnels to establish a secure connection with the Teleport unified Access Plane which can then becomes the single ingress point for all traffic to an internal application.

Adding an application follows the same UX as adding SSH servers or Kubernetes clusters, starting with creating a static or dynamic invite token.

$ tctl tokens add --type=app

Then simply start Teleport with a few new flags.

$ teleport start --roles=app --token=xyz --auth-server=proxy.example.com:3080 \
    --app-name="example-app" \
    --app-uri="http://localhost:8080"

This command will start an app server that proxies the application "example-app" running at http://localhost:8080 at the public address https://example-app.example.com.

Applications can also be configured using the new app_service section in teleport.yaml.

app_service:
   # Teleport Application Access is enabled.
   enabled: yes
   # We've added a default sample app that will check
   # that Teleport Application Access is working
   # and output JWT tokens.
   # https://dumper.teleport.example.com:3080/
   debug_app: true
   apps:
   # Application Access can be used to proxy any HTTP endpoint.
   # Note: Name can't include any spaces and should be DNS-compatible A-Za-z0-9-._
   - name: "internal-dashboard"
     uri: "http://10.0.1.27:8000"
     # By default Teleport will make this application
     # available on a sub-domain of your Teleport proxy's hostname
     # internal-dashboard.teleport.example.com
     # - thus the importance of setting up wilcard DNS.
     # If you want, it's possible to set up a custom public url.
     # DNS records should point to the proxy server.
     # internal-dashboard.teleport.example.com
     # Example Public URL for the internal-dashboard app.
     # public_addr: "internal-dashboard.acme.com"
     # Optional labels
     # Labels can be combined with RBAC rules to provide access.
     labels:
       customer: "acme"
       env: "production"
     # Optional dynamic labels
     commands:
     - name: "os"
       command: ["/usr/bin/uname"]
       period: "5s"
     # A proxy can support multiple applications. Application Access
     # can also be deployed with a Teleport node.
     - name: "arris"
       uri: "http://localhost:3001"
       public_addr: "arris.example.com"

Application access requires two additional changes. DNS must be updated to point the application domain to the proxy and the proxy must be loaded with a TLS certificate for the domain. Wildcard DNS and TLS certificates can be used to simplify deployment.

# When adding the app_service certificates are required to provide a TLS
# connection. The certificates are managed by the proxy_service
proxy_service:
  # We've extended support for https certs. Teleport can now load multiple
  # TLS certificates. In the below example we've obtained a wildcard cert
  # that'll be used for proxying the applications.
  # The correct certificate is selected based on the hostname in the HTTPS
  # request using SNI.
  https_keypairs:
  - key_file: /etc/letsencrypt/live/teleport.example.com/privkey.pem
    cert_file: /etc/letsencrypt/live/teleport.example.com/fullchain.pem
  - key_file: /etc/letsencrypt/live/*.teleport.example.com/privkey.pem
    cert_file: /etc/letsencrypt/live/*.teleport.example.com/fullchain.pem

You can learn more at https://goteleport.com/teleport/docs/application-access/

Teleport Kubernetes Access

Teleport 5.0 also introduces two highly requested features for Kubernetes.

For a full overview please review the Kubernetes RFD.

To support these changes, we've introduced a new service. This moves Teleport Kubernetes configuration from the proxy_service into its own dedicated kubernetes_service section.

When adding the new Kubernetes service, a new type of join token is required.

tctl tokens add --type=kube

Example configuration for the new kubernetes_service:

# ...
kubernetes_service:
   enabled: yes
   listen_addr: 0.0.0.0:3027
   kubeconfig_file: /secrets/kubeconfig

Note: a Kubernetes port still needs to be configured in the proxy_service via kube_listen_addr.

New "tsh kube" commands

tsh kube commands are used to query registered clusters and switch kubeconfig context:

$ tsh login --proxy=proxy.example.com --user=awly

# list all registered clusters
$ tsh kube ls
Cluster Name       Status
-------------      ------
a.k8s.example.com  online
b.k8s.example.com  online
c.k8s.example.com  online

# on login, kubeconfig is pointed at the first cluster (alphabetically)
$ kubectl config current-context
proxy.example.com-a.k8s.example.com

# but all clusters are populated as contexts
$ kubectl config get-contexts
CURRENT   NAME                     CLUSTER             AUTHINFO
*         proxy.example.com-a.k8s.example.com   proxy.example.com   proxy.example.com-a.k8s.example.com
          proxy.example.com-b.k8s.example.com   proxy.example.com   proxy.example.com-b.k8s.example.com
          proxy.example.com-c.k8s.example.com   proxy.example.com   proxy.example.com-c.k8s.example.com

# switch between different clusters:
$ tsh kube login c.k8s.example.com

# the traditional way is also supported:
$ kubectl config use-context proxy.example.com-c.k8s.example.com

# check current cluster
$ kubectl config current-context
proxy.example.com-c.k8s.example.com

Other Kubernetes changes:

Additional User and Token Resource

We've added two new RBAC resources; these provide the ability to limit token creation and to list and modify Teleport users:

- resources: [user]
  verbs: [list,create,read,update,delete]
- resources: [token]
  verbs: [list,create,read,update,delete]

Learn more about Teleport's RBAC Resources

Cluster Labels

Teleport 5.0 also adds the ability to set labels on Trusted Clusters. The labels are set when creating a trusted cluster invite token. This lets teams use the same RBAC controls used on nodes to approve or deny access to clusters. This can be especially useful for MSPs that connect hundreds of customers' clusters - when combined with Access Workflows, cluster access can easily be delegated. Learn more by reviewing our Truster Cluster Setup & RBAC Docs

Creating a trusted cluster join token for a production environment:

$ tctl tokens add --type=trusted_cluster --labels=env=prod
kind: role
#...
  deny:
    # cluster labels control what clusters user can connect to. The wildcard ('*')
    # means any cluster. By default, deny rules are empty to preserve backwards
    # compatibility
    cluster_labels:
      'env': 'prod'
Teleport UI Updates

Teleport 5.0 also iterates on the UI Refresh from 4.3. We've moved the cluster list into our sidebar and have added an Application launcher. For customers moving from 4.4 to 5.0, you'll notice that we have moved session recordings back to their own dedicated section.

Other updates:

Signed RPM and Releases

Starting with Teleport 5.0, we now provide an RPM repo for stable releases of Teleport. We've also started signing our RPMs to provide assurance that you're always using an official build of Teleport.

See https://rpm.releases.teleport.dev/ for more details.

Improvements

Enterprise Only:

Fixes

Documentation

We've added an API Reference to simply developing applications against Teleport.

Upgrade Notes

Please follow our standard upgrade procedure.

4.4.6

This release of teleport contains a security fix and a bug fix.

Any Enterprise SSO users using Okta, Active Directory, OneLogin or custom SAML connectors should upgrade their auth servers to version 4.4.6 and restart Teleport. If you are unable to upgrade immediately, we suggest disabling SAML connectors for all clusters until the updates can be applied.

4.4.5

This release of Teleport contains a bug fix.

4.4.4

This release of Teleport adds enhancements to the Access Workflows API.

4.4.2

This release of Teleport adds support for a new build architecture.

4.4.1

This release of Teleport contains a bug fix.

4.4.0

This is a major Teleport release with a focus on new features, functionality, and bug fixes. It’s a substantial release and users can review 4.4 closed issues on Github for details of all items.

New Features

Concurrent Session Control

This addition to Teleport helps customers obtain AC-10 control. We now provide two new optional configuration values: max_connections and max_sessions.

max_connections

This value is the total number of concurrent sessions within a cluster to nodes running Teleport. This value is applied at a per user level. If you set max_connections to 1, a tsh user would only be able to tsh ssh into one node at a time.

max_sessions per connection

This value limits the total number of session channels which can be established across a single SSH connection (typically used for interactive terminals or remote exec operations). This is for cases where nodes have Teleport set up, but a user is using OpenSSH to connect to them. It is essentially equivalent to the MaxSessions configuration value accepted by sshd.

spec:
  options:
    # Optional: Required to be set for AC-10 Compliance
    max_connections: 2
    # Optional: To match OpenSSH behavior set to 10
    max_sessions: 10
session_control_timeout

A new session_control_timeout configuration value has been added to the auth_service configuration block of the Teleport config file. It's unlikely that you'll need to modify this.

auth_service:
  session_control_timeout: 2m # default
# ...

Session Streaming Improvements

Teleport 4.4 includes a complete refactoring of our event system. This resolved a few customer bug reports such as #3800: Events overwritten in DynamoDB and #3182: Teleport consuming all disk space with multipart uploads.

Along with foundational improvements, 4.4 includes two new experimental session_recording options: node-sync and proxy-sync. NOTE: These experimental modes require all Teleport auth servers, proxy servers and nodes to be running Teleport 4.4.

# This section configures the 'auth service':
auth_service:
    # Optional setting for configuring session recording. Possible values are:
    #     "node"  : sessions will be recorded on the node level (the default)
    #     "proxy" : recording on the proxy level, see "recording proxy mode" section.
    #     "off"   : session recording is turned off
    #
    #     EXPERIMENTAL *-sync modes: proxy and node send logs directly to S3 or other
    #     storage without storing the records on disk at all. This mode will kill a
    #     connection if network connectivity is lost.
    #     NOTE: These experimental modes require all Teleport auth servers, proxy servers and
    #     nodes to be running Teleport 4.4.
    #
    #     "node-sync" : sessions recording will be streamed from node -> auth -> storage
    #     "proxy-sync : sessions recording will be streamed from proxy -> auth -> storage
    #
    session_recording: "node-sync"

Improvements

Fixes

Documentation

Upgrade Notes

Please follow our standard upgrade procedure.

4.3.9

This release of Teleport contains a security fix.

Any Enterprise SSO users using Okta, Active Directory, OneLogin or custom SAML connectors should upgrade their auth servers to version 4.3.9 and restart Teleport. If you are unable to upgrade immediately, we suggest disabling SAML connectors for all clusters until the updates can be applied.

4.3.8

This release of Teleport adds support for a new build architecture.

4.3.7

This release of Teleport contains a security fix and a bug fix.

Details

A vulnerability was discovered in the github.com/russellhaering/goxmldsig library which is used by Teleport to validate the signatures of XML files used to configure SAML 2.0 connectors. With a carefully crafted XML file, an attacker can completely bypass XML signature validation and pass off an altered file as a signed one.

Actions

The goxmldsig library has been updated upstream and Teleport 4.3.7 includes the fix. Any Enterprise SSO users using Okta, Active Directory, OneLogin or custom SAML connectors should upgrade their auth servers to version 4.3.7 and restart Teleport.

If you are unable to upgrade immediately, we suggest deleting SAML connectors for all clusters until the updates can be applied.

4.3.6

This release of Teleport contains multiple bug fixes.

4.3.5

This release of Teleport contains a bug fix.

4.3.4

This release of Teleport contains multiple bug fixes.

4.3.2

This release of Teleport contains multiple bug fixes.

4.3.0

This is a major Teleport release with a focus on new features, functionality, and bug fixes. It’s a substantial release and users can review 4.3 closed issues on Github for details of all items. We would love your feedback - please pick a time slot for a remote UX feedback session if you’re interested.

New Features

Web UI

Teleport 4.3 includes a completely redesigned Web UI. The new Web UI expands the management functionality of a Teleport cluster and the user experience of using Teleport to make it easier and simpler to use. Teleport's new terminal provides a quick jumping-off point to access nodes and nodes on other clusters via the web.

Teleport's Web UI now exposes Teleport’s Audit log, letting auditors and administrators view Teleport access events, SSH events, recording session, and enhanced session recording all in one view.

Teleport Plugins

Teleport 4.3 introduces four new plugins that work out of the box with Approval Workflow. These plugins allow you to automatically support role escalation with commonly used third party services. The built-in plugins are listed below.

Improvements

Fixes

Documentation

Upgrade Notes

Always follow the recommended upgrade procedure to upgrade to this version.

New Signing Algorithm

If you’re upgrading an existing version of Teleport, you may want to consider rotating CA to SHA-256 or SHA-512 for RSA SSH certificate signatures. The previous default was SHA-1, which is now considered to be weak against brute-force attacks. SHA-1 certificate signatures are also no longer accepted by OpenSSH versions 8.2 and above. All new Teleport clusters will default to SHA-512 based signatures. To upgrade an existing cluster, set the following in your teleport.yaml:

teleport:
    ca_signature_algo: "rsa-sha2-512"

Rotate the cluster CA, following these docs.

Web UI

Due to the number of changes included in the redesigned Web UI, some URLs and functionality have shifted. Refer to the following ticket for more details. #3580

RBAC for Audit Log and Recorded Sessions

Teleport 4.3 has made the audit log accessible via the Web UI. Enterprise customers can limit access by changing the options on the new event resource.

# list and read audit log, including audit events and recorded sessions
- resources: [event]
  verbs: [list, read]
Kubernetes Permissions

The minimum set of Kubernetes permissions that need to be granted to Teleport proxies has been updated. If you use the Kubernetes integration, please make sure that the ClusterRole used by the proxy has sufficient permissions.

Path prefix for etcd

The etcd backend now correctly uses the “prefix” config value when storing data. Upgrading from 4.2 to 4.3 will migrate the data as needed at startup. Make sure you follow our Teleport upgrade guidance.

Note: If you use an etcd backend with a non-default prefix and need to downgrade from 4.3 to 4.2, you should backup Teleport data and restore it into the downgraded cluster.

4.2.12

This release of Teleport contains a security fix.

Details

A vulnerability was discovered in the github.com/russellhaering/goxmldsig library which is used by Teleport to validate the signatures of XML files used to configure SAML 2.0 connectors. With a carefully crafted XML file, an attacker can completely bypass XML signature validation and pass off an altered file as a signed one.

Actions

The goxmldsig library has been updated upstream and Teleport 4.2.12 includes the fix. Any Enterprise SSO users using Okta, Active Directory, OneLogin or custom SAML connectors should upgrade their auth servers to version 4.2.12 and restart Teleport.

If you are unable to upgrade immediately, we suggest deleting SAML connectors for all clusters until the updates can be applied.

4.2.11

This release of Teleport contains multiple bug fixes.

4.2.10

This release of Teleport contains multiple bug fixes.

4.2.9

This release of Teleport contains multiple bug fixes.

4.2.8

This release of Teleport contains multiple bug fixes.

4.2.7

As part of a routine security audit of Teleport, a security vulnerability was discovered that affects all recent releases of Teleport. We strongly suggest upgrading to the latest patched release to mitigate this vulnerability.

Details

Due to a flaw in how the Teleport Web UI handled host certificate validation, host certificate validation was disabled for clusters where connections were terminated at the node. This means that an attacker could impersonate a Teleport node without detection when connecting through the Web UI.

Clusters where sessions were terminated at the proxy (recording proxy mode) are not affected.

Command line programs like tsh (or ssh) are not affected by this vulnerability.

Actions

To mitigate this issue, upgrade and restart all Teleport proxy processes.

4.2.6

This release of Teleport contains a bug fix.

4.2.5

This release of Teleport contains multiple bug fixes.

4.2.4

This release of Teleport contains bug fixes.

4.2.3

This release of Teleport contains bug and security fixes.

4.2.2

This release of Teleport contains bug fixes and improvements.

4.2.1

This release of Teleport contains bug fixes and minor usability improvements.

4.2.0

This is a minor Teleport release with a focus on new features and bug fixes.

Improvements

Fixes

Documentation

4.1.11

This release of Teleport contains a security fix.

Details

A vulnerability was discovered in the github.com/russellhaering/goxmldsig library which is used by Teleport to validate the signatures of XML files used to configure SAML 2.0 connectors. With a carefully crafted XML file, an attacker can completely bypass XML signature validation and pass off an altered file as a signed one.

Actions

The goxmldsig library has been updated upstream and Teleport 4.1.11 includes the fix. Any Enterprise SSO users using Okta, Active Directory, OneLogin or custom SAML connectors should upgrade their auth servers to version 4.1.11 and restart Teleport.

If you are unable to upgrade immediately, we suggest deleting SAML connectors for all clusters until the updates can be applied.

4.1.10

As part of a routine security audit of Teleport, a security vulnerability was discovered that affects all recent releases of Teleport. We strongly suggest upgrading to the latest patched release to mitigate this vulnerability.

Details

Due to a flaw in how the Teleport Web UI handled host certificate validation, host certificate validation was disabled for clusters where connections were terminated at the node. This means that an attacker could impersonate a Teleport node without detection when connecting through the Web UI.

Clusters where sessions were terminated at the proxy (recording proxy mode) are not affected.

Command line programs like tsh (or ssh) are not affected by this vulnerability.

Actions

To mitigate this issue, upgrade and restart all Teleport proxy processes.

4.1.9

This release of Teleport contains a security fix.

4.1.8

This release of Teleport contains a bug fix.

4.1.7

This release of Teleport contains a bug fix.

4.1.6

This release of Teleport contains a bug fix.

4.1.5

This release of Teleport adds support for an older version of Linux.

4.1.4

This release of Teleport contains a bug fix.

4.1.3

This release of Teleport contains multiple bug fixes.

4.1.2

This release of Teleport contains improvements to the build code.

4.1.1

This release of Teleport contains a bug fix.

4.1.0

This is a major Teleport release with a focus on stability and bug fixes.

Improvements

Fixes

4.0.16

As part of a routine security audit of Teleport, a security vulnerability was discovered that affects all recent releases of Teleport. We strongly suggest upgrading to the latest patched release to mitigate this vulnerability.

Details

Due to a flaw in how the Teleport Web UI handled host certificate validation, host certificate validation was disabled for clusters where connections were terminated at the node. This means that an attacker could impersonate a Teleport node without detection when connecting through the Web UI.

Clusters where sessions were terminated at the proxy (recording proxy mode) are not affected.

Command line programs like tsh (or ssh) are not affected by this vulnerability.

Actions

To mitigate this issue, upgrade and restart all Teleport proxy processes.

4.0.15

This release of Teleport contains a security fix.

4.0.14

This release of Teleport contains a bug fix.

4.1.13

This release of Teleport contains a bug fix.

4.0.12

This release of Teleport contains a bug fix.

4.0.11

This release of Teleport adds support for an older version of Linux.

4.0.10

This release of Teleport contains a bug fix.

4.0.9

This release of Teleport contains a bug fix.

4.0.8

This release of Teleport contains two bug fixes.

Description

4.0.6

This release of Teleport contains a bug fix.

4.0.4

This release of Teleport contains a bug fix.

4.0.3

4.0.2

This release of Teleport contains multiple bug fixes.

4.0.1

This release of Teleport contains multiple bug fixes.

4.0.0

This is a major Teleport release which introduces support for Teleport Internet of Things (IoT). In addition to this new feature this release includes usability, performance, and bug fixes listed below.

New Features

Teleport for IoT

With Teleport 4.0, nodes gain the ability to use reverse tunnels to dial back to a Teleport cluster to bypass firewall restrictions. This allows connections even to nodes that a cluster does not have direct network access to. Customers that have been using Trusted Clusters to achieve this can now utilize a unified interface to access all nodes within their infrastructure.

FedRamp Compliance

With this release of Teleport, we have built out the foundation to help Teleport Enterprise customers build and meet the requirements in a FedRAMP System Security Plan (SSP). This includes a FIPS 140-2 friendly build of Teleport Enterprise as well as a variety of improvements to aid in complying with security controls even in FedRAMP High environments.

Improvements

Bug Fixes

The lists of improvements and bug fixes above mention only the significant changes, please take a look at the complete list on Github for more.

Upgrading

Teleport 4.0 is backwards compatible with Teleport 3.2 and later. Follow the recommended upgrade procedure to upgrade to this version.

Note that due to substantial changes between Teleport 3.2 and 4.0, we recommend creating a backup of the backend datastore (DynamoDB, etcd, or dir) before upgrading a cluster to Teleport 4.0 to allow downgrades.

Notes on compatibility

Teleport has always validated host certificates when a client connects to a server, however prior to Teleport 4.0, Teleport did not validate the host the user requests a connection to is in the list of principals on the certificate. To ensure a seamless upgrade, make sure the hosts you connect to have the appropriate address set in public_addr in teleport.yaml before upgrading.

3.2.15

This release of Teleport contains a bug fix.

3.2.14

This release of Teleport contains a bug fix and a feature.

3.2.13

This release of Teleport contains a bug fix.

Description

3.2.12

This release of Teleport contains a bug fix.

3.2.11

This release of Teleport contains two bug fixes.

3.2.9

This release of Teleport contains a bug fix.

3.2.4

This release of Teleport contains multiple bug fixes.

3.2.2

This release of Teleport contains a bug fix.

Changes

3.2.1

This release of Teleport contains a new feature.

Changes

3.2

This version brings support for Amazon's managed Kubernetes offering (EKS).

Starting with this release, Teleport proxy uses the impersonation API instead of the CSR API.

3.1.14

This release of Teleport contains a bug fix.

3.1.13

This release of Teleport contains two bug fixes.

3.1.11

This release of Teleport contains a bug fix.

3.1.8

This release of Teleport contains a bug fix.

Changes

3.1.7

This release of Teleport contains a bug fix.

Changes

3.1.6

This release of Teleport contains bug fixes, security fixes, and user experience improvements.

Changes

3.1.5

Teleport 3.1.5 contains a bug fix and security fix.

Bug fixes

3.1.4

Teleport 3.1.4 contains one new feature and two bug fixes.

New Feature

Bug fixes

3.1.3

Teleport 3.1.3 contains two security fixs.

Bugfixes

3.1.2

Teleport 3.1.2 contains a security fix. We strongly encourage anyone running Teleport 3.1.1 to upgrade.

Bugfixes

3.1.1

Teleport 3.1.1 contains a security fix. We strongly encourage anyone running Teleport 3.1.0 to upgrade.

3.1

This is a major Teleport release with a focus on backwards compatibility, stability, and bug fixes. Some of the improvements:

3.0.5

Teleport 3.0.5 contains a security fix.

Bug fixes

3.0.4

Teleport 3.0.4 contains two security fixs.

Bugfixes

3.0.3

Teleport 3.0.3 contains a security fix. We strongly encourage anyone running Teleport 3.0.2 to upgrade.

Bugfixes

3.0.2

Teleport 3.0.2 contains a security fix. We strongly encourage anyone running Teleport 3.0.1 to upgrade.

3.0.1

This release of Teleport contains the following bug fix:

3.0

This is a major Teleport release which introduces support for Kubernetes clusters. In addition to this new feature this release includes several usability and performance improvements listed below.

Kubernetes Support

For more information about Kubernetes support, take a look at the Kubernetes and SSH Integration Guide

Improvements

Bugfixes

The lists of improvements and bug fixes above mention only the significant changes, please take a look at the complete list on Github for more.

Upgrading to 3.0

Follow the recommended upgrade procedure to upgrade to this version.

WARNING: if you are using Teleport with the etcd back-end, make sure your etcd version is 3.3 or newer prior to upgrading to Teleport 3.0.

2.7.9

Teleport 2.7.9 contains a security fix.

Bug fixes

2.7.8

Teleport 2.7.8 contains two security fixs.

Bugfixes

2.7.7

Teleport 2.7.7 contains two security fixes. We strongly encourage anyone running Teleport 2.7.6 to upgrade.

Bugfixes

2.7.6

This release of Teleport contains the following bug fix:

2.7.5

This release of Teleport contains the following bug fix:

2.7.4

This release of Teleport focuses on bugfixes.

Bug Fixes

2.7.3

This release of Teleport focuses on bugfixes.

Bug Fixes

2.7.2

This release of Teleport focuses on bugfixes.

Bug Fixes

2.7.1

This release of Teleport focuses on bugfixes.

Bug Fixes

2.7.0

The primary goal of 2.7.0 release was to address the community feedback and improve the performance and flexibility when running Teleport clusters with large number of nodes.

New Features

Performance Improvements

Bug Fixes

As awlays, this release contains several bug fixes. The full list can be seen here. Here are some notable ones:

Upgrading

Follow the recommended upgrade procedure to upgrade to this version.

2.6.9

This release of Teleport focuses on bugfixes.

Bug Fixes

2.6.8

This release of Teleport focuses on bugfixes.

Bug Fixes

2.6.7

This release of Teleport focuses on bugfixes.

Bug Fixes

2.6.5

This release of Teleport focuses on bugfixes.

Bug Fixes

2.6.3

This release of Teleport focuses on bugfixes.

Bug Fixes

2.6.2

This release of Teleport focuses on bugfixes.

Bug Fixes

2.6.1

This release of Teleport focuses on bugfixes.

Bug Fixes

2.6.0

This release of Teleport brings new features, significant performance and usability improvements as well usual bugfixes.

During this release cycle, the Teleport source code has been audited for security vulnerabilities by Cure53 and this release (2.6.0) contains patches for the discovered problems.

New Features

Additionally, Teleport 2.6.0 has been submitted to the AWS marketplace. Soon AWS users will be able to create properly configured, secure and highly available Teleport clusters with ease.

Configuration Changes

Bug Fixes

The list of most visible bug fixes in this release:

You can see the full list of 2.6.0 changes here.

Upgrading

Follow the recommended upgrade procedure to upgrade to this version.

2.5.7

This release of Teleport focuses on bugfixes.

Bug Fixes

2.5.6

This release of Teleport focuses on bugfixes.

Bug Fixes

2.5.5

This release of Teleport focuses on bugfixes.

Bug Fixes

2.5.4

This release of Teleport focuses on bugfixes.

Bug Fixes

2.5.3

This release of Teleport focuses on bugfixes.

Bug Fixes

2.5.2

This release of Teleport includes bug fixes and regression fixes.

Bug Fixes

2.5.1

This release of Teleport fixes a regression in Teleport binaries.

Bug Fixes

2.5.0

This is a major release of Teleport. Its goal is to make cloud-native deployments easier. Numerous AWS users have contributed feedback to this release, which includes:

New Features

Improvements

Bug Fixes

Behavior Changes

Certain components of Teleport behave differently in version 2.5. It is important to note that these changes are not breaking Teleport functionality. They improve Teleport behavior on large clusters deployed on highly dynamic cloud environments such as AWS. This includes:

2.4.7

This release of Teleport contains a bugfix.

Bug Fixes

2.4.6

This release of Teleport focuses on bugfixes.

Bug Fixes

2.4.5

This release of Teleport fixes a regression in Teleport binaries.

Bug Fixes

2.4.4

This release of Teleport focuses on bugfixes.

Bug Fixes

2.4.3

This release of Teleport focuses on bugfixes.

Bug Fixes

2.4.2

This release of Teleport focuses on bugfixes.

Bug Fixes

2.4.1

This release is focused on fixing a few regressions in Teleport as well as adding a new feature.

New Features

Bug Fixes

2.4.0

This release adds two major new features and a few improvements and bugfixes.

New Features

Deprecated Features

Bug Fixes

There have been numerous small usability and performance improvements, but some notable fixed bugs are listed below:

2.3.5

This release is focused on fixing a few regressions in configuration and UI/UX.

Improvements

Bug fixes

2.3.1

Bug fixes

2.3

This release focus was to increase Teleport user experience in the following areas:

Improvements

Teleport Enterprise

Bug Fixes

2.2.7

Bug fixes

2.2.6

Bug fixes

2.2.5

Bug fixes

2.2.4

Bug fixes

2.2.3

Bug fixes

2.2.2

Bug fixes

2.2.1

Improvements

Bugfixes

2.2.0

Features

Enterprise Features

Improvements

2.0.6

Bugfixes

2.0.5

Teleport 2.0.5 contains a variety of security fixes. We strongly encourage anyone running Teleport 2.0.0 and above to upgrade to 2.0.5.

The most pressing issues (a phishing attack which can potentially be used to extract plaintext credentials and an attack where an already authenticated user can escalate privileges) can be resolved by upgrading the web proxy. However, however all nodes need to be upgraded to mitigate all vulnerabilities.

Bugfixes

2.0.4

Bugfixes

2.0.3

Bugfixes

2.0.2

Bugfixes

2.0.1

Features

Improvements

Bugfixes

2.0

This is a major new release of Teleport.

Features

Improvements

Enterprise Features

Full list of Github issues: https://github.com/gravitational/teleport/milestone/8

1.3.2

v1.3.2 is a maintenance release which fixes a Web UI issue when in some cases static web assets like custom fonts would not load properly.

Bugfixes

1.3.1

v1.3.1 is a maintenance release which fixes a few issues found in 1.3

Bugfixes

Improvements

1.3

This release includes several major new features and it's recommended for production use.

Features

Bugfixes

1.2

This is a maintenance release and it's a drop-in replacement for previous versions.

Changes

1.1.0

This is a maintenance release meant to be a drop-in upgrade of previous versions.

Changes

1.0.5

This release was recommended for production with one reservation: time-limited certificates did not work correctly in this release due to #529

Bugfixes

1.0.4

This release only includes the addition of the ability to specify non-standard HTTPS port for Teleport proxy for tsh --proxy flag.

1.0.3

This release only includes one major bugfix #486 plus minor changes not exposed to OSS Teleport users.

Bugfixes

1.0

The first official release of Teleport!

Try Teleport Today

In the Cloud, Self-hosted, or Open Source

View Developer Docs