Machine ID: Database/Application Tunnel Services

Currently, to access Applications/Databases, users must configure an output for the correct type of certificates and then use these with tbot proxy ran separately to create the appropriate tunnel. This typically means creating a systemd service per tunnel and one for the main tbot process.

This has some limitations:

Certificates are not automatically reloaded by tbot proxy/tsh. This means that after the certificate TTL expires, the tunnel no longer functions and must be restarted.
The tsh implementation enforces arbitrary limitations that make good sense for humans but are nonsensical for machines (https://github.com/gravitational/teleport/issues/27692)
Requires tsh to be available in the environment as a tsh child process is actually used to provide this functionality.
Using tsh is fragile to CLI interface changes.
Having certificate generation and tunnel creation configured separately causes issues if configuration mismatches (https://github.com/gravitational/teleport/issues/17385)
Creating and managing systemd services for each tunnel is burdensome
Certificates are written to disk where they are more easily exfilitrated.

Following https://github.com/gravitational/teleport/pull/36140 , we can now build long-lived sub-services which run inside the main tbot process. We can leverage this to allow tunnels to applications/databases to be managed by the main tbot process. This resolves the limitations above and offers some additional benefits.

Hypothetical configuration:

services:
  - type: authenticated-app-tunnel
    listen: tcp://127.0.0.1:8080
    app_name: foo
  - type: authenticated-database-tunnel
    listen: tcp://127.0.0.1:8080
    service: example-server
    database: example
    username: alice

gravitational / teleport

Machine ID: Database/Application Tunnel Services #36291