mirror of
https://github.com/gravitational/teleport.git
synced 2026-11-04 19:12:46 +08:00
Paul Gottschling
67391f93e7
* Add a glossary of Teleport terms Closes #16121 Closes #13363 - Create a Core Concepts page based on the Architecture Overview page. The Overview page is an outline of core concepts, so I thought it would make a good starting point for the glossary. - Add the Core Concepts page to the Home section to make it more prominent for users who are visiting the docs homepage. This should give it more traffic than leaving it in the Architecture section. - Move definitions out of the "Definitions" table. Since this table repeats content from the body sections and comes after them, it makes sense to condense all content into brief body sections. - Alphabetize sections - Bold the first instance of each keyword within a given section. Not adding links since these are all to the same page. It might get a bit confusing to click a link and not see a change in view, since the target section would already be on the page. - Remove the intro paragraph of the old Overview page, since it's not strictly related to core concepts. * Respond to PR feedback and add further edits - Group definitions into H3-level sections organized into H2s, improving readability by presenting the more central components first. - Group "Machine ID" with "Teleport Services" to simplify the glossary. - Call instances of a Teleport Service an "agent". This is consistent with our source and informal language about Teleport. This also removes the "Node" terminology, which is prone to misuse (does it mean "a Service instance"? An "SSH Service instance"? Both are present in the docs) and easily confused with the lowercase "node" (i.e., a host). - For simplicity, remove the term "Teleport Process" and simply explain that multiple Teleport Services can run via the same binary. - Add a section on Teleport's editions, including the terms "Community Edition", "Enterprise", and "Enterprise Cloud". - Remove the mention of Teleport Discover, which isn't documented yet. - Minor wording/readability changes. * Respond to PR feedback * Respond to zmb3 feedback
74 lines
2.8 KiB
Plaintext
74 lines
2.8 KiB
Plaintext
---
|
|
title: Teleport Proxy Service
|
|
description: Architecture of Teleport's identity-aware proxy service
|
|
h1: Teleport Identity-Aware Proxy Service
|
|
---
|
|
|
|
Teleport Proxy is a identity aware proxy, with a web UI. Here are Proxy's key features:
|
|
|
|
- Users can authenticate with a Single-Sign-On or local credentials to access SSH and Windows Desktops via Proxy's web UI.
|
|
- Proxy is identity aware - it makes sure that only authenticated clients can connect to target resources.
|
|
It intercepts traffic for multiple protocols - SSH, Kubernetes, HTTPS, databases.
|
|
It records commands, API calls and queries and streams them to the audit log.
|
|
- Proxy provides networking and connectivity features. Nodes and proxies behind firewalls can connect
|
|
to proxies using reverse tunnels. System administrators can use TLS routing feature to compress all ports for all protocols to one TLS port using TLS routing feature.
|
|
|
|
|
|
|
|
<Notice type="tip">
|
|
To create a minimal Teleport cluster, you have run two services:
|
|
Teleport Auth Service and Teleport Proxy Service. For your home lab,
|
|
you can run both services as a one binary and process.
|
|
</Notice>
|
|
|
|
## Web UI
|
|
|
|
In Web UI, Teleport Proxy implements WSS - secure web sockets - to proxy a
|
|
target resource, for example SSH server or Desktop:
|
|
|
|
|
|
|
|
<Admonition
|
|
type="note"
|
|
title="TLS Encryption"
|
|
>
|
|
When using the web UI, the Teleport Proxy terminates traffic and re-encodes data for the client connection.
|
|
</Admonition>
|
|
|
|
## Identity-Aware-Proxy
|
|
|
|
In IAP mode, users initiate the SSO or login flow to sign public keys on their client machines:
|
|
|
|
|
|
|
|
<Admonition
|
|
type="note"
|
|
title="IAP Mode Security"
|
|
>
|
|
We consider IAP mode more secure than Web UI access, because private keys never leave user's client.
|
|
Client's connection to resource is mutually authenticated. This mode is also less vulnerable
|
|
for web-related attacks, like CSRF or cookie hijacking, because browser is used less.
|
|
</Admonition>
|
|
|
|
## Tunnels
|
|
|
|
In this mode, resources behind firewall can establish reverse tunnels back to proxies.
|
|
Proxies will forward client's connections to target resources via those tunnels.
|
|
|
|
In the example below, Alice connects to kubernetes cluster behind firewall via two tunnels:
|
|
|
|
|
|
|
|
<Notice type="tip">
|
|
All modes above are turned on by default in Proxies. No special configuration is necessary, unless you
|
|
want to turn some of those modes off.
|
|
</Notice>
|
|
|
|
## More concepts
|
|
|
|
- [TLS Routing](tls-routing.mdx)
|
|
- [Architecture Overview](../core-concepts.mdx)
|
|
- [Teleport Authentication](authentication.mdx)
|
|
- [Teleport Authorization](authorization.mdx)
|
|
- [Teleport Proxy](proxy.mdx)
|