<commit_before>---
title: Application Access Guide
description: How to set up and configure Teleport for Application access with SSO and RBAC
---

# Teleport Application Access

## Introduction
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

## Demo

<video autoplay loop muted playsinline controls>
  <source src="https://goteleport.com/teleport/videos/k8s-application-access/k8s-taa.mp4" type="video/mp4" />
  <source src="https://goteleport.com/teleport/videos/k8s-application-access/k8s-taa.webm" type="video/webm" />
Your browser does not support the video tag.
</video>


#### Hardware Requirements
[How it works](https://gravitational.com/teleport/how-it-works/) page will give you a good overview of the setup.

#### Networking Requirements

!!! note "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.

|Port      | Service    | Description
|----------|------------|-------------------------------------------
| 3023     | Proxy      | SSH port for clients who need tsh login
| 3024     | Proxy      | SSH port used to create reverse SSH tunnels from behind-firewall environments into a trusted proxy server.
| 3025     | Auth       | TLS port used by the Auth Service to serve its API to other nodes in a cluster.
| 3080     | Proxy      | HTTPS 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: `teleport.example.com` will host the Access Plane. `*.teleport.example.com` will host all of the applications e.g. `jenkins.teleport.example.com`.

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.

```yaml
proxy_service:
  enabled: "yes"
  listen_addr: 0.0.0.0:3023
  tunnel_listen_addr: 0.0.0.0:3024
  public_addr: teleport.example.com:443
  ## Example of two https keypairs.
  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
```

!!! tip "Using Certbot to obtain Wildcard Certs"

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

      ```sh
      certbot certonly --manual \
        --preferred-challenges=dns \
        --email [EMAIL] \
        --agree-tos \
        --manual-public-ip-logging-ok \
        -d "teleport.example.com, *.teleport.example.com"
      ```


## 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 replace | Description  |
|-|-|
| `--roles=app` | The 'app' role will set up the reverse proxy for applications |
| `--token` | A dynamic or static `app` token obtained from the root cluster |
| `--auth-server` | URL of the root cluster auth server or public proxy address |
| `--app-name` | Application name |
| `--app-uri` |  URI and Port of Application  |

```sh
teleport start --roles=app --token=<PASSWORD> --auth-server=proxy.example.com:3080 \
    --app-name="example-app" \
    --app-uri="http://localhost:8080"
```

### 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 a-z 0-9 _ -` allowed).

After Teleport is running, the application will be accessible at `app-name.proxy_public_addr.com` e.g. `jenkins.teleport.example.com`.  Teleport also provides the ability to override `public_addr`. e.g `jenkins.acme.com` 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 replace | Description  |
|-|-|
| `proxy_service: public_addr` | Public URL and Port for Teleport |<commit_msg>[docs] Document lower case only in app name (#5181)<commit_after>---
title: Application Access Guide
description: How to set up and configure Teleport for Application access with SSO and RBAC
---

# Teleport Application Access

## Introduction
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

## Demo

<video autoplay loop muted playsinline controls>
  <source src="https://goteleport.com/teleport/videos/k8s-application-access/k8s-taa.mp4" type="video/mp4" />
  <source src="https://goteleport.com/teleport/videos/k8s-application-access/k8s-taa.webm" type="video/webm" />
Your browser does not support the video tag.
</video>


#### Hardware Requirements
[How it works](https://gravitational.com/teleport/how-it-works/) page will give you a good overview of the setup.

#### Networking Requirements

!!! note "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.

|Port      | Service    | Description
|----------|------------|-------------------------------------------
| 3023     | Proxy      | SSH port for clients who need tsh login
| 3024     | Proxy      | SSH port used to create reverse SSH tunnels from behind-firewall environments into a trusted proxy server.
| 3025     | Auth       | TLS port used by the Auth Service to serve its API to other nodes in a cluster.
| 3080     | Proxy      | HTTPS 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: `teleport.example.com` will host the Access Plane. `*.teleport.example.com` will host all of the applications e.g. `jenkins.teleport.example.com`.

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.

```yaml
proxy_service:
  enabled: "yes"
  listen_addr: 0.0.0.0:3023
  tunnel_listen_addr: 0.0.0.0:3024
  public_addr: teleport.example.com:443
  ## Example of two https keypairs.
  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
```

!!! tip "Using Certbot to obtain Wildcard Certs"

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

      ```sh
      certbot certonly --manual \
        --preferred-challenges=dns \
        --email [EMAIL] \
        --agree-tos \
        --manual-public-ip-logging-ok \
        -d "teleport.example.com, *.teleport.example.com"
      ```


## 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 replace | Description  |
|-|-|
| `--roles=app` | The 'app' role will set up the reverse proxy for applications |
| `--token` | A dynamic or static `app` token obtained from the root cluster |
| `--auth-server` | URL of the root cluster auth server or public proxy address |
| `--app-name` | Application name |
| `--app-uri` |  URI and Port of Application  |

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

### 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 `app-name.proxy_public_addr.com` e.g. `jenkins.teleport.example.com`.  Teleport also provides the ability to override `public_addr`. e.g `jenkins.acme.com` 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 replace | Description  |
|-|-|
| `proxy_service: public_addr` | Public URL and Port for Teleport |
{'fraction_non_alphanumeric': 0.1078107810781078, 'fraction_numerical': 0.011001100110011002, 'mean_word_length': 3.526935264825713, 'pattern_counts': {'":': 0, '<': 14, '<?xml version=': 0, '>': 12, 'https://': 8, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 4, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 3, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '3688062', 'n_tokens_mistral': 2976, 'n_tokens_neox': 2803, 'n_words': 1125}