Teleport provides connectivity, authentication, access controls and audit for infrastructure.
It includes an identity-aware access proxy, a CA that issues short-lived certificates, a unified access control system and a tunneling system to access resources behind the firewall.
Teleport understands the [SSH](../network/SSH.md), [HTTPS](../../internet/HTTP.md), RDP, Kubernetes API, MySQL, [MongoDB](../development/MongoDB.md) and PostgreSQL wire protocols, plus many others. It can integrate with Single Sign-On providers and enables you to apply access policies using infrastructure-as-code and GitOps tools.
Teleport assigns a subdomain to each application you configure for Application Access. For example, if you enroll Grafana as a resource, Teleport assigns the resource to the `grafana.teleport.example.com` subdomain.
1. Generate a token
```shell
tctl tokens add \
--type=app \
--app-name=grafana \
--app-uri=http://localhost:3000
```
2. Install and configure teleport
```shell
sudo teleport configure \
--output=file \
--proxy=teleport.example.com:443 \
--token=/tmp/token \
--roles=app \
--app-name=grafana \
--app-uri=http://localhost:3000
```
### Advanced
#### Customize public address
By default applications are available at `<app-name>.<proxy-host>:<proxy-port>` address. To override the public address, specify the `public_addr` field:
```yml
- name: "jira"
uri: "https://localhost:8001"
public_addr: "jira.example.com"
```
#### Skip TLS certificate verification
> Danger Zone
> This is insecure and not recommended for use in production.
Teleport checks if the certificates presented by the applications are signed by a trusted Certificate Authority. When using self-signed certificates for internal applications, use `insecure_skip_verify: true` to skip this verification step:
```yml
- name: "app"
uri: "https://localhost:8443"
public_addr: "app.example.com"
insecure_skip_verify: tru
```
#### Deeplink to a subdirectory
Some applications are available in a subdirectory. Examples include the Kubernetes Dashboard.. The URI should be updated to include the subdirectory:
To support web apps that perform internal redirects, application access provides an option to rewrite the hostname of the Location header on redirect responses to the application's public address:
```yml
- name: "jenkins"
uri: "https://localhost:8001"
public_addr: "jenkins.example.com"
rewrite:
# Rewrite the "Location" header on redirect responses replacing the
# host with the public address of this application.
redirect:
- "localhost"
- "jenkins.internal.dev"
```
#### Headers passthrough
You can configure application access to inject additional headers in the requests forwarded to a web application.
For apps defined in the `teleport.yaml` configuration, the `headers` field of each app is a list of strings. Be careful to quote the entire value to ensure it is parsed correctly.
```yml
- name: "dashboard"
uri: https://localhost:4321
public_addr: dashboard.example.com
rewrite:
headers:
# Inject a static header.
- "X-Custom-Header: example"
# Inject headers with internal/external user traits.
- "X-Internal-Trait: {{internal.logins}}"
- "X-External-Trait: {{external.env}}"
# Inject header with Teleport-signed JWT token.
- "Authorization: Bearer {{internal.jwt}}"
# Override Host header.
- "Host: dashboard.example.com"
```
Headers injected this way override any headers with the same names that may be sent by an application. The following headers are reserved and can't be rewritten:
-`Teleport-Jwt-Assertion`
-`Cf-Access-Token`
- Any header matching the pattern `X-Teleport-*`
- Any header matching the pattern `X-Forwarded-*`
Rewritten header values support the same templating variables as role templates. In the example above, `X-Internal-Trait` header will be populated with the value of internal user trait logins and `X-External-Trait` header will get the value of the user's external env trait coming from the identity provider.
Additionally, the `{{internal.jwt}}` template variable will be replaced with a [JWT](../../internet/JWT.md) token signed by Teleport that contains user identity information.
#### [JSON Web Token](../../internet/JWT.md) Integration
Teleport sends a [JWT](../../internet/JWT.md) token signed with Teleport's authority with each request to a target application in a `Teleport-Jwt-Assertion` header.
You can use the [JWT](../../internet/JWT.md) token to get information about the authenticated Teleport user, its roles, and its traits. This allows you to:
- Map Teleport identity/roles/traits onto the identity/roles/traits of your web application.
- Trust Teleport identity to automatically sign in users into your application.
Example [JWT](../../internet/JWT.md):
```jsonc
{
"aud": [
"http://127.0.0.1:34679"
],
"iss": "aws",
"nbf": 1603835795,
"sub": "alice",
// Teleport user name.
"username": "alice"
// Teleport user roles.
"roles": [
"admin"
],
// Teleport user traits.
"traits": {
"logins": [
"root",
"ubuntu",
"ec2-user"
]
},
// Teleport identity expiration.
"exp": 1603943800,
}
```
##### Validate [JWT](../../internet/JWT.md)
Teleport provides a JSON Web Key Set (jwks) endpoint to verify that the [JWT](../../internet/JWT.md) can be trusted. This endpoint is `https://[cluster-name]:3080/.well-known/jwks.json`:
Teleport Machine ID enables machines, such as CI/CD workflows, to securely authenticate with your Teleport cluster in order to connect to resources and configure the cluster itself. This is sometimes referred to as machine-to-machine access.
