Fork me on GitHub

Upcoming Teleport Releases


Teleport Application Access has been designed to provide secure access to internal dashboards and applications, building on Teleport's strong foundations of security and identity. You can now put applications onto the internet safely and securely.

You can secure any web application using application access:

  • Internal control panels
  • Wikis / Tooling that's only available on the VPN.
  • Infra dashboards - Kubernetes, Grafana
  • Developer tools, such as Jenkins, Gitlab or Opsgenie


Hardware Requirements

How it works page will give you a good overview of the setup.

Networking Requirements

Why do I see SSH Ports for Application Access?

Teleport uses SSH reverse tunnels to connect applications to the proxy. This is why the configuration below mentions SSH ports.

3023ProxySSH port for clients who need tsh login
3024ProxySSH port used to create reverse SSH tunnels from behind-firewall environments into a trusted proxy server.
3025AuthTLS port used by the Auth Service to serve its API to other nodes in a cluster.
3080ProxyHTTPS connection to authenticate tsh users and web users into the cluster. The same connection is used to serve a Teleport UI.

TLS Requirements

TLS is required to secure Teleport's Unified Access Plane and any connected applications. When setting up Teleport, the minimum requirement is a certificate for the proxy and a wildcard certificate for its sub-domain. This is where everyone will log into Teleport.

Example: will host the Access Plane. * will host all of the applications e.g.

Teleport supports accessing these applications on other domains if required. DNS entries must be configured and the correct certificates need to be obtained for this to work.

  enabled: "yes"
  ## Example of two https keypairs.
  - key_file: /etc/letsencrypt/live/
    cert_file: /etc/letsencrypt/live/
  - key_file: /etc/letsencrypt/live/*
    cert_file: /etc/letsencrypt/live/*
Using Certbot to obtain Wildcard Certs

Let's Encrypt provides free wildcard certificates. If using certbot with DNS challenge, the below script will make setup easy. Update [EMAIL] and [DOMAIN]

certbot certonly --manual \
  --preferred-challenges=dns \
  --email [EMAIL] \
  --agree-tos \
  --manual-public-ip-logging-ok \
  -d ", *"

Teleport Application Service Setup

There are two options for running Teleport, once installed it can be set up with inline options using teleport start or using a teleport.yaml config file.

Starting Teleport

Variable to replaceDescription
--roles=appThe 'app' role will set up the reverse proxy for applications
--tokenA dynamic or static app token obtained from the root cluster
--auth-serverURL of the root cluster auth server or public proxy address
--app-nameApplication name
--app-uriURI and Port of Application
teleport start --roles=app --token=xyz \
    --app-name="example-app" \

Application Name

When picking an application name, it's important to make sure the name will make a valid sub-domain (<=63 characters, no spaces, only a-z 0-9 _ - allowed).

After Teleport is running, the application will be accessible at e.g. Teleport also provides the ability to override public_addr. e.g if you configure the appropriate DNS entry to point to the Teleport proxy server.

Starting Teleport with config file

Define /etc/teleport.yaml

Variable to replaceDescription
auth_token & tokensExample static join tokens
proxy_service: public_addrPublic URL and Port for Teleport.
https_keypairsHTTPS TLS Certificate key pairs
-key_fileLetsEncrypt Key File
-cert_fileLetsEncrypt Cert File
app_service: enabled: yesApplication Service should be enabled
apps: nameApplication Name
apps: uriURL and port of application
  data_dir: /var/lib/teleport
  auth_token: a3aff444e182cf4ee5c2f78ad2a4cc47d8a30c95747a08f8
  enabled: "yes"
  - proxy,node,app:a3aff444e182cf4ee5c2f78ad2a4cc47d8a30c95747a08f8
  enabled: "false"
   enabled: yes
   # We've a small debug app that can be used to make sure application
   # Access is working correctly. It'll output JWTs so it can be useful
   # for when extending your application.
   debug_app: true
   - name: "kubernetes-dashboard"
     # URI and port of application.
     uri: "https://localhost:3040"
     # Optional Label: These can be used in combination with RBAC rules
     # to limit access to applications
        env: "prod"
     # Optional Dynamic Labels
     - name: "os"
       command: ["/usr/bin/uname"]
       period: "5s"
  enabled: "yes"
  # Public address defaults to port 3080 which doesn't
  # require Teleport starting as root
  # Example using a wildcard cert
  - key_file: /etc/letsencrypt/live/
    cert_file: /etc/letsencrypt/live/
  - key_file: /etc/letsencrypt/live/*
    cert_file: /etc/letsencrypt/live/*

[ Optional ] Obtain a new App Token

In the above example we've hard coded a join token a3aff444e182cf4ee5c2f78ad2a4cc47d8a30c95747a08f8. You can use this to join apps or create a dynamic token using the tctl command below.

$ tctl tokens add --type=app

Advanced Options

Running Debug Application

For testing and debuging purposes we provide an inbuilt debugging app. This can be turned on use debug_app: true.

   enabled: yes
   debug_app: true

Customize Public Address

   - name: "jira"
     uri: "https://localhost:8001"
     public_addr: ""

Skip TLS certificate verification

Corporations often use self-signed certificates for internal applications. Teleport attempts to check if the certificates are signed by a trusted CA (Certificate Authority). If using self-signed certificates use insecure_skip_verify: true to skip this verification step.

   - name: "app"
     uri: "https://localhost:8443"
     public_addr: ""
     insecure_skip_verify: true

Some Applications are available on a Subdirectory, examples include the Kubernetes Dashboard.. The URI should be updated to include the subdirectory.

   - name: "k8s"
     uri: ""
     public_addr: ""


We provide simple rewrites. This is helpful for applications that provide internal redirect headers.

   - name: "jira"
     uri: "https://localhost:8001"
     public_addr: ""
        # Rewrite the "Location" header on redirect responses replacing the
        # host with the public address of this application.
           - "localhost"
           - ""

View Applications in Teleport

Teleport provides a UI for quickly launching connected applications. They can be viewed by navigating to a cluster and selecting Applications. The URL structure is below.


Logging out of Applications

When you log into an application, you'll get a certificate and login session per your defined RBAC. If you want to force logout before this period you can force a log out by hitting the /teleport-logout endpoint:

Integrating with JWTs

Introduction to JWTs

JSON Web Token (JWT) is an open standard that defines a secure way to transfer information between parties as a JSON Object.

For a in-depth explanation please visit

Teleport JSON Web Tokens (JWT) include three sections:

  • Header
  • Payload
  • Signature

Example Header

  "alg": "RS256",
  "typ": "JWT"


Example Payload

  "aud": [
  "exp": 1603943800,
  "iss": "aws",
  "nbf": 1603835795,
  "roles": [
  "sub": "benarent",
  "username": "benarent"

The JWT will be sent with the header: Teleport-Jwt-Assertion

Example Teleport JWT Assertion


Validate JWT with JSON Web Key Set (JWKS)

Teleport provides a jwks endpoint to verify that the JWT can be trusted. This endpoint is https://[cluster-name]:3080/.well-known/jwks.json

Example jwks.json

  "keys": [
      "kty": "RSA",
      "n": "xk-0VSVZY76QGqeN9TD-FJp32s8jZrpsalnRoFwlZ_JwPbbd5-_bPKcz8o2tv1eJS0Ll6ePxRCyK68Jz2UC4V4RiYaqJCRq_qVpDQMB1sQ7p9M-8qvT82FJ-Rv-W4RNe3xRmBSFDYdXaFm51Uk8OIYfv-oZ0kGptKpkNY390aJOzjHPH2MqSvhk9Xn8GwM8kEbpSllavdJCRPCeNVGJXiSCsWrOA_wsv_jqBP6g3UOA9GnI8R6HR14OxV3C184vb3NxIqxtrW0C4W6UtSbMDcKcNCgajq2l56pHO8In5GoPCrHqlo379LE5QqpXeeHj8uqcjeGdxXTuPrRq1AuBpvQ",
      "e": "AQAB",
      "alg": "RS256"

Example Applications

As outlined in our introduction, Application Access has been designed to support two types of applications.

Example Legacy App
A device such as a load balancer might come with a control panel, but it doesn't have any authentication and can only be access via a privileged network. These applications are supported and can extend access beyond your network.

Other example legacy apps:

  • An internal admin tool
  • Control panel for networking devices

Example Modern App
Teleport Application Access supports all modern applications, these could be built in-house or off-the-shelf software such as Jenkins, Kubernetes Dashboard and Jupyter workbooks.

  • Kubernetes Internal Dashboard
  • Grafana
  • Jupyter notebooks
  • In-house Single Page Apps (SPA)
  • SPA with custom Json Web Token support (JWT)
Have a suggestion or can’t find something?