diff --git a/docs/config.json b/docs/config.json index a3dfcce1a3484..4d10c520bf4b8 100644 --- a/docs/config.json +++ b/docs/config.json @@ -53,7 +53,8 @@ { "title": "Scaling", "slug": "/setup/operations/scaling/" }, { "title": "Upgrading", "slug": "/setup/operations/upgrading/" }, { "title": "Backup and Restore", "slug": "/setup/operations/backup-restore/" }, - { "title": "Cert Authority Rotation", "slug": "/setup/operations/ca-rotation/" } + { "title": "Cert Authority Rotation", "slug": "/setup/operations/ca-rotation/" }, + { "title": "TLS Routing Migration", "slug": "/setup/operations/tls-routing/" } ] }, { @@ -314,7 +315,8 @@ { "title": "Teleport Nodes", "slug": "/architecture/nodes/" }, { "title": "Teleport Auth", "slug": "/architecture/authentication/" }, { "title": "Teleport Proxy", "slug": "/architecture/proxy/" }, - { "title": "Trusted Clusters", "slug": "/trustedclusters/" } + { "title": "Trusted Clusters", "slug": "/trustedclusters/" }, + { "title": "TLS Routing", "slug": "/architecture/tls-routing/" } ] } ], diff --git a/docs/img/architecture/tls-routing.png b/docs/img/architecture/tls-routing.png new file mode 100644 index 0000000000000..7c494dc84e847 Binary files /dev/null and b/docs/img/architecture/tls-routing.png differ diff --git a/docs/img/database-access/pgadmin-connection@2x.png b/docs/img/database-access/pgadmin-connection@2x.png index 7de8890047ac3..0d28e8164922d 100644 Binary files a/docs/img/database-access/pgadmin-connection@2x.png and b/docs/img/database-access/pgadmin-connection@2x.png differ diff --git a/docs/img/database-access/pgadmin-ssl@2x.png b/docs/img/database-access/pgadmin-ssl@2x.png index c3f5477b441f1..f574d94a5b737 100644 Binary files a/docs/img/database-access/pgadmin-ssl@2x.png and b/docs/img/database-access/pgadmin-ssl@2x.png differ diff --git a/docs/pages/architecture/tls-routing.mdx b/docs/pages/architecture/tls-routing.mdx new file mode 100644 index 0000000000000..dda3575290a88 --- /dev/null +++ b/docs/pages/architecture/tls-routing.mdx @@ -0,0 +1,153 @@ +--- +title: TLS Routing +description: How Teleport implements a single-port setup with TLS routing +--- + +
+ TLS routing is available starting from Teleport `8.0`. +
+ +In TLS routing mode [Teleport proxy](./proxy.mdx) multiplexes all client +connections on a single TLS port. + +With TLS routing, cluster administrators can simplify network configurations +since proxy only listens on one port. All connections are authenticated with +mutual TLS and users are able to tunnel protocols that may be blocked on the +network such as SSH. + +To implement TLS routing, Teleport uses SNI ([Server Name Indication](https://en.wikipedia.org/wiki/Server_Name_Indication)) +and ALPN ([Application-Level Protocol Negotiation](https://en.wikipedia.org/wiki/Application-Layer_Protocol_Negotiation)) +TLS extensions. + +## How it works + +Starting from version `8.0` Teleport proxy listens for all client connections +on its `web_listen_addr` by default: + +```yaml +proxy_service: + web_listen_addr: "0.0.0.0:443" +``` + +All Teleport clients including SSH, web browser, kubectl, database and reverse +tunnel clients establish a TLS tunnel to the proxy's web port and indicate the +protocol they're requesting using SNI and ALPN TLS extensions. + +Upon accepting a new connection, the proxy inspects the SNI/ALPN value in the +TLS handshake and forwards the connection to appropriate backend service. + +### Local proxy + +Clients like `psql` or `mysql` implement TLS handshake as a part of their +protocol-specific connection negotiation phase (aka [STARTTLS](https://en.wikipedia.org/wiki/Opportunistic_TLS)). + +To support these clients, as well as clients that do support TLS but don't allow +setting custom ALPN values, Teleport's `tsh` client includes ability to start +a local TLS routing aware proxy. + +Such clients connect to the local proxy instead of Teleport proxy directly. The +local proxy establishes a TLS connection to the Teleport proxy with the proper +SNI/ALPN values set and tunnels the client's connection over it. + +In most cases, clients handle TLS routing transparently when establishing +connection. For example, `tsh` client starts local proxy and sets appropriate +SNI/ALPN values automatically. For some clients, like native/GUI database +clients instead of `tsh db connect`, the user needs to start the local proxy so +these clients can connect to it. + +### Diagram + +
+ ![TLS routing](../../img/architecture/tls-routing.png) +
+ +Let's take a look at how each protocol Teleport supports implements TLS routing. + +## SSH + +Teleport client `tsh`, when connecting to an SSH node, first dials Teleport +proxy over TLS and requests `teleport-ssh-proxy` ALPN protocol. + +No local proxy is started in this case as `tsh` uses this TLS connection as a +transport to establish the SSH connection. + +### OpenSSH + +To support standard OpenSSH client, Teleport provides a `tsh proxy ssh` command +which can be used as a `ProxyCommand`. + +Similarly to `tsh ssh`, `tsh proxy ssh` establishes a TLS tunnel to Teleport +proxy with `teleport-ssh-proxy` ALPN protocol, which `ssh` then connects over. + +See [OpenSSH client](../server-access/guides/openssh.mdx#use-openssh-client) +guide for details on how it's configured. + +## Reverse tunnels + +Reverse tunnel agents for Teleport node, application and database services, as +well as for trusted clusters, open a TLS tunnel to the cluster's proxy with +`teleport-reversetunnel` ALPN protocol and then dials SSH over it establishing +the reverse tunnel connection. + +## Kubernetes + +Kubernetes client `kubectl` uses HTTPS API and TLS handshake to talk to the API +server. + +As such, it is not possible to request a custom ALPN protocol using `kubectl`. +Instead, Teleport leverages SNI and sets a `ServerName` prefixed with `kube.` +when generating a kubeconfig file during `tsh kube login`: + +```yaml +apiVersion: v1 +kind: Config +clusters: +- cluster: + certificate-authority-data: ... + server: https://proxy.example.com:443 + tls-server-name: kube.proxy.example.com + name: example +``` + +## Databases + +The `tsh db connect` command executes an appropriate database client for the +database you're connecting to. + +In TLS routing mode, `tsh` starts a local proxy which database client connection +is tunneled through. The local proxy uses one of `teleport-postgres`, +`teleport-mysql` or `teleport-mongodb` ALPN values depending on the database. +The proxy is shut down when the database session ends. + +### Native and GUI clients + +For the native or graphical database clients to work with TLS routing, they +must be connecting to the local proxy instead of Teleport proxy directly. + +Teleport provides a `tsh proxy db` command to launch a local database proxy: + +```code +$ tsh proxy db example-db +``` + +See [GUI clients](../database-access/guides/gui-clients.mdx) guide for a usage +example. + +## Web UI, apps and desktops + +Application access, desktop access and Teleport web UI are served by the +Teleport proxy's web listener and don't require a local proxy or any special +ALPN/SNI negotiation. These web connections use standard `http1.1` and `h2` +protocols for ALPN. + +## Next steps + +- See [migration guide](../setup/operations/tls-routing.mdx) to learn how to + upgrade an existing cluster to use TLS routing. +- Read through TLS routing design document [RFD](https://github.com/gravitational/teleport/blob/master/rfd/0039-sni-alpn-teleport-proxy-routing.md). diff --git a/docs/pages/database-access/guides/cockroachdb-self-hosted.mdx b/docs/pages/database-access/guides/cockroachdb-self-hosted.mdx index 79f9910b8eed2..c460ed4f4dc11 100644 --- a/docs/pages/database-access/guides/cockroachdb-self-hosted.mdx +++ b/docs/pages/database-access/guides/cockroachdb-self-hosted.mdx @@ -164,12 +164,6 @@ $ tsh db connect roach in order to be able to connect. -To see the native `cockroach` shell connect command, run: - -```code -$ tsh db config --format=cmd roach -``` - To log out of the database and remove credentials: ```code diff --git a/docs/pages/database-access/guides/gui-clients.mdx b/docs/pages/database-access/guides/gui-clients.mdx index 892180ce2de7c..b3fc3be9cd3b3 100644 --- a/docs/pages/database-access/guides/gui-clients.mdx +++ b/docs/pages/database-access/guides/gui-clients.mdx @@ -8,25 +8,48 @@ description: How to configure graphical database clients for Teleport Database A This article describes how to configure popular graphical database clients to work with Teleport Database Access. -## Obtain local certificate/key-pair +## Get connection information -Issue the following command after you login with `tsh`: + + +If you're using Teleport in [TLS routing](../../setup/operations/tls-routing.mdx) +mode where each database protocol is multiplexed on the same web proxy port, use +the following command to start a local TLS proxy your GUI database client will +be connecting to: + +```code +$ tsh proxy db +Started DB proxy on 127.0.0.1:61740 + +Use following credentials to connect to the proxy: + ca_file=/Users/r0mant/.tsh/keys/root.gravitational.io/certs.pem + cert_file=/Users/r0mant/.tsh/keys/root.gravitational.io/alice-db/root/-x509.pem + key_file=/Users/r0mant/.tsh/keys/root.gravitational.io/alice +``` + +Use the displayed local proxy host/port and credentials paths when configuring +your GUI client below. When entering the hostname, use `localhost` rather than +`127.0.0.1`. + + +If you're not using TLS routing, run the following command to see the database +connection information: ```code # View configuration for the database you're logged in to. -tsh db config +$ tsh db config # View configuration for the specific database when you're logged into multiple. -tsh db config example +$ tsh db config example ``` -It will display the path to your locally cached PEM files: +It will display the path to your locally cached certificate and key files: ``` Name: example Host: teleport.example.com -Port: 3036 -User: alice -Database: +Port: 3080 +User: postgres +Database: postgres CA: /Users/alice/.tsh/keys/teleport.example.com/certs.pem Cert: /Users/alice/.tsh/keys/teleport.example.com/alice-db/root/example-x509.pem Key: /Users/alice/.tsh/keys/teleport.example.com/alice @@ -35,6 +58,8 @@ Key: /Users/alice/.tsh/keys/teleport.example.com/alice The displayed `CA`, `Cert`, and `Key` files are used to connect through pgAdmin 4, MySQL Workbench, and other graphical database clients that support mutual TLS authentication. + + ## PostgreSQL pgAdmin 4 @@ -50,25 +75,18 @@ In the "General" tab of the new server dialog, enter the server connection name: ![pgAdmin General](../../../img/database-access/pgadmin-general@2x.png) -In the "Connection" tab, enter the default database name (the *maintenance -database*) and the connection service name (the same one that you specify when -connecting through `psql`). Leave all the other fields blank: +In the "Connection" tab, fill in the hostname, port, user and database name from +the configuration above: ![pgAdmin Connection](../../../img/database-access/pgadmin-connection@2x.png) -In the "SSL" tab, set "SSL Mode" to `Verify-Full`: +In the "SSL" tab, set "SSL Mode" to `Verify-Full` and fill in paths for client +certificate, key and root certificate from the configuration above: ![pgAdmin SSL](../../../img/database-access/pgadmin-ssl@2x.png) -Click "Save", and pgAdmin should immediately connect. - - - On a Windows client, use terminal to export a PG Service File env variable: - - `$ setx PGSERVICEFILE ` - - Restart the pgAdmin client. - +Click "Save", and pgAdmin should immediately connect. If pgAdmin prompts you +for password, leave the password field empty and click OK. ## MySQL Workbench diff --git a/docs/pages/database-access/guides/mongodb-atlas.mdx b/docs/pages/database-access/guides/mongodb-atlas.mdx index 07fd1191738e1..6741f4548bada 100644 --- a/docs/pages/database-access/guides/mongodb-atlas.mdx +++ b/docs/pages/database-access/guides/mongodb-atlas.mdx @@ -189,12 +189,6 @@ $ tsh db connect mongodb-atlas able to connect. -If you would like to see the native `mongo` shell connect command, run: - -```code -$ tsh db config --format=cmd mongodb-atlas -``` - To log out of the database and remove credentials: ```code diff --git a/docs/pages/database-access/guides/mongodb-self-hosted.mdx b/docs/pages/database-access/guides/mongodb-self-hosted.mdx index 7e0f83a165bbd..cf7f5e00f33d6 100644 --- a/docs/pages/database-access/guides/mongodb-self-hosted.mdx +++ b/docs/pages/database-access/guides/mongodb-self-hosted.mdx @@ -229,12 +229,6 @@ $ tsh db connect example-mongo able to connect. -If you would like to see the native `mongo` shell connect command, run: - -```code -$ tsh db config --format=cmd example-mongo -``` - To log out of the database and remove credentials: ```code diff --git a/docs/pages/database-access/guides/mysql-cloudsql.mdx b/docs/pages/database-access/guides/mysql-cloudsql.mdx index aa9bc5e3d744c..3d00fbddd7685 100644 --- a/docs/pages/database-access/guides/mysql-cloudsql.mdx +++ b/docs/pages/database-access/guides/mysql-cloudsql.mdx @@ -240,12 +240,6 @@ $ tsh db connect cloudsql able to connect. -If you would like to see the native `mysql` shell connect command, run: - -```code -$ tsh db config --format=cmd cloudsql -``` - To log out of the database and remove credentials: ```code diff --git a/docs/pages/database-access/guides/mysql-self-hosted.mdx b/docs/pages/database-access/guides/mysql-self-hosted.mdx index 081eb95245382..1b61fe7dcaefe 100644 --- a/docs/pages/database-access/guides/mysql-self-hosted.mdx +++ b/docs/pages/database-access/guides/mysql-self-hosted.mdx @@ -217,12 +217,6 @@ $ tsh db connect example able to connect. -If you would like to see the native `mysql` shell connect command, run: - -```code -$ tsh db config --format=cmd example -``` - To log out of the database and remove credentials: ```code diff --git a/docs/pages/database-access/guides/postgres-cloudsql.mdx b/docs/pages/database-access/guides/postgres-cloudsql.mdx index 701fce11baa67..c02cd79887e9c 100644 --- a/docs/pages/database-access/guides/postgres-cloudsql.mdx +++ b/docs/pages/database-access/guides/postgres-cloudsql.mdx @@ -316,12 +316,6 @@ $ tsh db connect aurora able to connect. -If you would like to see the native `psql` shell connect command, run: - -```code -$ tsh db config --format=cmd aurora -``` - To log out of the database and remove credentials: ```code diff --git a/docs/pages/database-access/guides/postgres-redshift.mdx b/docs/pages/database-access/guides/postgres-redshift.mdx index 953b4a399f611..551f474128855 100644 --- a/docs/pages/database-access/guides/postgres-redshift.mdx +++ b/docs/pages/database-access/guides/postgres-redshift.mdx @@ -262,12 +262,6 @@ $ tsh db connect aurora able to connect. -If you would like to see the native `psql` shell connect command, run: - -```code -$ tsh db config --format=cmd aurora -``` - To log out of the database and remove credentials: ```code diff --git a/docs/pages/database-access/guides/postgres-self-hosted.mdx b/docs/pages/database-access/guides/postgres-self-hosted.mdx index 192d11373d2fb..fbebbc5d5a069 100644 --- a/docs/pages/database-access/guides/postgres-self-hosted.mdx +++ b/docs/pages/database-access/guides/postgres-self-hosted.mdx @@ -213,12 +213,6 @@ $ tsh db connect aurora able to connect. -If you would like to see the native `psql` shell connect command, run: - -```code -$ tsh db config --format=cmd aurora -``` - To log out of the database and remove credentials: ```code diff --git a/docs/pages/database-access/guides/rds.mdx b/docs/pages/database-access/guides/rds.mdx index 62057199b8208..b31ebd99c8c97 100644 --- a/docs/pages/database-access/guides/rds.mdx +++ b/docs/pages/database-access/guides/rds.mdx @@ -378,12 +378,6 @@ $ tsh db connect postgres-rds available in PATH in order to be able to connect. -To see the native database CLI client connect command, run: - -```code -$ tsh db config --format=cmd postgres-rds -``` - To log out of the database and remove credentials: ```code diff --git a/docs/pages/server-access/guides/openssh.mdx b/docs/pages/server-access/guides/openssh.mdx index 842b50884f34e..5671672c67fdf 100644 --- a/docs/pages/server-access/guides/openssh.mdx +++ b/docs/pages/server-access/guides/openssh.mdx @@ -326,14 +326,13 @@ Host root.example.com Host *.root.example.com HostName %h Port 3022 - ProxyCommand ssh -p 3023 %r@root.example.com -s proxy:%h:%p + ProxyCommand tsh proxy ssh %r@%h:%p -# when connecting to a node within a trusted cluster with the name "leaf1.example.com", -# add the name of the cluster to the invocation of the proxy subsystem. +# connect to nodes within a trusted cluster with the name "leaf1.example.com". Host *.leaf1.example.com HostName %h Port 3022 - ProxyCommand ssh -p 3023 %r@root.example.com -s proxy:%h:%p@leaf1.example.com + ProxyCommand tsh proxy ssh --cluster=leaf1.example.com %r@%h:%p ``` When everything is configured properly, you can use ssh to connect to any node diff --git a/docs/pages/setup/operations.mdx b/docs/pages/setup/operations.mdx index d2ca5c5650aeb..a731ffdaca4c3 100644 --- a/docs/pages/setup/operations.mdx +++ b/docs/pages/setup/operations.mdx @@ -17,4 +17,7 @@ layout: tocless-doc
  • [CA Rotation](./operations/ca-rotation.mdx). Rotating certificates and certificate authorities.
    • +
  • + [TLS Routing Migration](./operations/tls-routing.mdx). Migrating to single-port TLS routing Teleport mode. +
    • diff --git a/docs/pages/setup/operations/tls-routing.mdx b/docs/pages/setup/operations/tls-routing.mdx new file mode 100644 index 0000000000000..3982c1e4edfff --- /dev/null +++ b/docs/pages/setup/operations/tls-routing.mdx @@ -0,0 +1,143 @@ +--- +title: TLS Routing Migration +description: How to upgrade exising Teleport cluster to a single-port TLS routing mode +--- + +
    + TLS routing is available starting from Teleport `8.0`. +
    + +Starting from version `8.0` Teleport supports TLS routing. In this mode, all +client connections are wrapped in TLS and multiplexed on one Teleport proxy +port. + +TLS routing has multiple benefits compared to the deployment where each protocol +is served on a separate port: + +- Simpler network policy configurations since all clients connect to Teleport + proxy over a single port. +- Communication between any client and Teleport proxy is authenticated by + mutual TLS. +- Users are able to tunnel protocols that may normally be blocked on the + internal network like SSH. + +Existing clusters upgraded to `8.0` will not utilize TLS routing by default and +keep working in backwards-compatibility mode. Follow this guide to migrate your +Teleport installation to TLS routing. + +## Requirements + +For TLS routing to work, Teleport proxy needs to terminate all client +connections. + +Thus, it will not work with application load balancers (such as AWS ALB) or load +balancers that do TLS termination. Use plain TCP passthrough load balancers +(such as AWS NLB) to take advantage of TLS routing. + +## Step 1/7. Upgrade to Teleport `8.0` + +Download Teleport `8.0` or later from the [downloads page](https://goteleport.com/teleport/download) +or your enterprise portal and follow the standard [upgrade procedure](./upgrading.mdx). +Make sure to upgrade both root and leaf clusters as well as `tsh` client. + +Pre-8.0 cluster configurations are fully backwards compatible with TLS routing. +Existing trusted cluster and reverse tunnel agent connections won't be affected. + +## Step 2/7. Enable proxy multiplexing + +Update your root cluster auth server's configuration to set proxy listener mode +to "multiplex": + +```yaml +auth_service: + proxy_listener_mode: multiplex +``` + +This setting will indicate to the clients (such as `tsh` or reverse tunnel +agents) that they should connect to the web proxy port using TLS routing. + +## Step 3/7. Reconnect trusted clusters + +If you're already multiplexing trusted cluster connections on the web proxy port +(i.e. `web_listen_addr` and `tunnel_listen_addr` have the same port in your +proxy configuration), you can skip this step. + +Otherwise, update your trusted clusters to point both `web_proxy_addr` and +`tunnel_addr` to the root cluster's web proxy address and recreate them: + +```yaml +kind: trusted_cluster +version: v2 +metadata: + name: "root" +spec: + enabled: true + web_proxy_addr: root.example.com:443 + tunnel_addr: root.example.com:443 + ... +``` + +## Step 4/7. Reconnect reverse tunnel agents + +Restart all SSH, Kubernetes, application and database agents that connect to +the cluster's proxy over reverse tunnels. + +This will make them reconnect to the cluster in TLS routing mode. + +## Step 5/7. Relogin with tsh + +Do `tsh logout` and log into the cluster with `tsh login` again to make sure +`tsh` starts using TLS routing mode. + +## Step 6/7. Update OpenSSH config + +If you're using OpenSSH client `ssh` with the config generated by `tsh config` +to connect to nodes within your Teleport cluster, you need to regenerate the +config. + +Run `tsh config` command again so it generates SSH config compatible with SSH +routing setup. See [OpenSSH client](../../server-access/guides/openssh.mdx#use-openssh-client) +docs for reference. + +## Step 7/7. Disable legacy listeners + +At this point, all root cluster's clients connect to its web proxy port in TLS +routing mode. The final step is to instruct the Teleport proxy not to create +legacy listeners for SSH, reverse tunnels, Kubernetes and database clients by +default. + +Add `version: v2` to your proxy's configuration and remove all listen addresses +except for `web_listen_addr`: + +```yaml +version: v2 +proxy_service: + enabled: "yes" + web_listen_addr: 0.0.0.0:443 + ... +``` + +Config version `v2` will prevent other listeners from being created unless +they are explicitly set in the proxy service configuration. + +## Rollback + +To go back to the legacy separate listeners mode, perform the following steps: + +1. Set `version: v1` in the proxy configuration and restart the proxy to make + it create legacy listeners. +2. Set `proxy_listener_mode: separate` in auth service configuration to make + clients connect to the legacy listeners. +3. Reconnect all clients (trusted clusters, reverse tunnel agents, `tsh`) as + described above. +4. If using OpenSSH client, regenerate SSH config using `tsh config` command. + +## Next steps + +- Learn how TLS routing [works](../../architecture/tls-routing.mdx). diff --git a/docs/pages/setup/reference/config.mdx b/docs/pages/setup/reference/config.mdx index 3c4cd7e40320b..8f95a2b127635 100644 --- a/docs/pages/setup/reference/config.mdx +++ b/docs/pages/setup/reference/config.mdx @@ -17,6 +17,9 @@ get a good starting file, run `teleport configure -o teleport.yaml`. ```yaml # By default, this file should be stored in /etc/teleport.yaml +# Configuration file version. The current version is "v2". +version: v2 + # This section of the configuration file applies to all teleport # services. teleport: @@ -330,13 +333,25 @@ auth_service: # the configured `data_dir` . license_file: /var/lib/teleport/license.pem - # Configures a banner message to be displayed to a user logging into the cluster, # which must be acknowledged before the user is allowed to log in. Note that will # be shown *before* login, so should not contain any confidential information. # Defaults to the empty string, implying no message or acknowledgment is required. message_of_the_day: "" + # Indicates to the clients whether the cluster is running in TLS routing mode + # with all protocols multiplexed on the proxy's web_listen_addr. + # + # Possible values are: + # + # "multiplex": clients will be connecting to Teleport proxy's web listener + # in TLS routing mode. + # "separate": clients will be connecting to Teleport proxy's individual + # listeners: tunnel_listen_addr, mysql_listen_addr, etc. + # + # See "TLS Routing" in Architecture section for additional information. + proxy_listener_mode: multiplex + # This section configures the 'node service': ssh_service: # Turns 'ssh' role on. Default is 'yes' @@ -416,12 +431,22 @@ proxy_service: # SSH forwarding/proxy address. Command line (CLI) clients always begin their # SSH sessions by connecting to this port + # + # If not set, behavior depends on the config file version: + # + # "v2": listener is not created, SSH is multiplexed on web_listen_addr + # "v1": defaults to 0.0.0.0:3023 listen_addr: 0.0.0.0:3023 # Reverse tunnel listening address. An auth server (CA) can establish an # outbound (from behind the firewall) connection to this address. # This will allow users of the outside CA to connect to behind-the-firewall # nodes. + # + # If not set, behavior depends on the config file version: + # + # "v2": listener is not created, reverse tunnel traffic is multiplexed on web_listen_addr + # "v1": defaults to 0.0.0.0:3024 tunnel_listen_addr: 0.0.0.0:3024 # The HTTPS listen address to serve the Web UI and also to authenticate the @@ -461,11 +486,22 @@ proxy_service: - key_file: /etc/letsencrypt/live/*.teleport.example.com/privkey.pem cert_file: /etc/letsencrypt/live/*.teleport.example.com/fullchain.pem + # Kubernetes proxy listen address. + # + # If not set, behavior depends on the config file version: + # + # "v2": listener is not created, Kubernetes traffic is multiplexed on web_listen_addr + # "v1": defaults to 0.0.0.0:3026 kube_listen_addr: 0.0.0.0:3026 # optional: set a different public address for kubernetes access kube_public_addr: kube.example.com:3026 # MySQL proxy listen address. + # + # If not set, behavior depends on the config file version: + # + # "v2": listener is not created, MySQL traffic is multiplexed on web_listen_addr + # "v1": defaults to 0.0.0.0:3036 mysql_listen_addr: "0.0.0.0:3036" # Address advertised to PostgreSQL clients. If not set, public_addr is used.