Add app gateways to Connect

[gzdunek]

Closes #35959
Adds local proxies for TCP and HTTP apps.

The most important commits are:

• 19a304178f6edb8ed5b889c5b23633eb33b7ebca- the Go implementation of gateways. I followed the code we have for db and kube gateways and the the code for tsh proxy app.
• f3c584a8dfcc38f5dd82a3be94d26196729a22ff - the UI part. Here I based on the UI for database gateways.

TODO:

• Handle expired certs. From what I see, I should use onExpiredCert, but I haven't figured out yet a way to elegantly check if the app cert is not expired (for dbs we have CheckDBCerts).
• Replace the offline screen with Unify gateway offline screens #36324.

Changelog: Added App Access support to Teleport Connect.

[gzdunek]

FYI I took this from

teleport/tool/tsh/common/proxy.go

Line 555 in 39af8d3

func loadAppCertificate(tc *libclient.TeleportClient, appName string) (certificate tls.Certificate, needLogin bool, err error) {

[gzdunek]

@ravicious @greedy52 this PR is still in draft as I have to handle certs expiration, but this shouldn't block the review.

I'd like you to pay special attention to the Go code 🙏. I was trying follow existing patterns, but there is a chance that something should be done differently.

[ravicious]

I have to run some errands, submitting my feedback so far. I'll continue the review tomorrow.

[ravicious]

We need integration tests for these gateways. Take a look at TestTeletermKubeGateway and testTeletermGatewaysCertRenewal and compare them to existing app access integration tests if there are any. We'll likely need to add a new test function, unless the dumper app can be enabled somehow in tests. In this case, we could reuse the cluster from testTeletermGatewaysCertRenewal, just so that we don't have to spend time on spinning up a new cluster just for app gateways.

[gzdunek]

Will do!

[ravicious]

Wait, I was too fast with asking for those tests. The existing integration tests depend on cert expiry being handled. I can add those tests when adding the middleware. If you started any work on this, please DM me the patch.

[ravicious]

We might be able to reuse getConnectionGatewayOperations here instead of adding a new function, no?

[ravicious]

By that I mean that in contexts where we can treat a gateway as a gateway with a generic target, we should do so. After applying the two suggestions mentioned above, getConnectionGatewayAppOperations becomes pretty much identical to getConnectionGatewayOperations. This suggests that we should be able to use TrackedGatewayConnection for both databases and apps. targetUri could be then used to differentiate between them where needed, for example in the UI when saying "DB" vs "APP".

[gzdunek]

That's right, those gateway types are really similar. Probably we could go even further and use a single type for a document? 🤔
I'm only thinking about the backward compatibility, what will happen if an older version of Connect will try to open an app connection treating it like a db? (probably nothing good)
OTOH, now the app just crashes when it see an unsupported connection, I don't know what is worse :)

[ravicious]

That's right, those gateway types are really similar. Probably we could go even further and use a single type for a document? 🤔

I wasn't thinking too much about documents because they have considerably different UI, especially Kube vs the rest. OTOH there's a lot of similar actions (like changing the port) which could be refactored to a hook or reused in some other way between db and app gateways (I haven't looked at the UI code for app gateways in this PR yet).

In case of connections, the only meaningful difference between is the label shown in the list, or at least that's what I thought until you mentioned backward compatibility.

I'm only thinking about the backward compatibility, what will happen if an older version of Connect will try to open an app connection treating it like a db? (probably nothing good)

That's a good shout. It's more like forward compatibility I suppose. It's worth checking out, but I think besides UI inconsistencies nothing should make the app unusable? The Electron app will attempt to create a gateway for the given target URI, but tshd should fail at either parsing the target URI (if the given version of tshd supports kube gateways where we inspect if the target URI is of a db or a kube cluster) or finding the database.

[ravicious]

Right now if I go back to the previous version of the app which doesn't support app gateways, I get:

TypeError: Cannot destructure property 'rootClusterUri' of 'this._trackedConnectionOperationsFactory.create(...)' as it is undefined.
    at eval (webpack-internal:///./src/ui/services/connectionTracker/connectionTrackerService.ts:165:9)
    at Array.map (<anonymous>)
    at ConnectionTrackerService.getConnections (webpack-internal:///./src/ui/services/connectionTracker/connectionTrackerService.ts:162:35)
    at useConnections (webpack-internal:///./src/ui/TopBar/Connections/useConnections.ts:36:35)
    at Connections (webpack-internal:///./src/ui/TopBar/Connections/Connections.tsx:52:86)
    at renderWithHooks (webpack-internal:///../../../node_modules/react-dom/cjs/react-dom.development.js:16305:18)
    at mountIndeterminateComponent (webpack-internal:///../../../node_modules/react-dom/cjs/react-dom.development.js:20069:13)
    at beginWork (webpack-internal:///../../../node_modules/react-dom/cjs/react-dom.development.js:21582:16)
    at HTMLUnknownElement.callCallback (webpack-internal:///../../../node_modules/react-dom/cjs/react-dom.development.js:4164:14)
    at Object.invokeGuardedCallbackDev (webpack-internal:///../../../node_modules/react-dom/cjs/react-dom.development.js:4213:16)

[ravicious]

And once I reopen the docs:

Error: Unhandled case: [object Object]
    at assertUnreachable (webpack-internal:///../shared/utils/assertUnreachable.ts:27:9)
    at getResourceUri (webpack-internal:///./src/ui/services/workspacesService/documentsService/documentsUtils.ts:64:75)
    at useActiveDocumentClusterBreadcrumbs (webpack-internal:///./src/ui/StatusBar/useActiveDocumentClusterBreadcrumbs.ts:41:109)
    at StatusBar (webpack-internal:///./src/ui/StatusBar/StatusBar.tsx:46:135)
    at renderWithHooks (webpack-internal:///../../../node_modules/react-dom/cjs/react-dom.development.js:16305:18)
    at updateFunctionComponent (webpack-internal:///../../../node_modules/react-dom/cjs/react-dom.development.js:19583:20)
    at beginWork (webpack-internal:///../../../node_modules/react-dom/cjs/react-dom.development.js:21596:16)
    at HTMLUnknownElement.callCallback (webpack-internal:///../../../node_modules/react-dom/cjs/react-dom.development.js:4164:14)
    at Object.invokeGuardedCallbackDev (webpack-internal:///../../../node_modules/react-dom/cjs/react-dom.development.js:4213:16)
    at invokeGuardedCallback (webpack-internal:///../../../node_modules/react-dom/cjs/react-dom.development.js:4277:31)

[gzdunek]

I decided to remove doc.gateway_app and connection.app types. They were mostly copies of our regular document gateway and the gateway connection. It is much better to simply differentiate them by their URI.

If we ever need to add more properties to the app gateways, we can always create a new type.

Another advantage is that it fixes the errors that show up after downgrading the app. In case of connection, it will be shown as a db connection. If you try to connect, you will see this nice error:

The only thing that I have to fix, is to use routing.parseClusterUri instead of routing.parseDbUri here, since it can be also an app uri (we could use routing.parseClusterUri from the beginning, we don't even need anything from db at that point).
I will create a PR and backport it.

[greedy52]

thanks for inviting me for a preview 😄 . basic go implementation looks good to me 👍 . I can do some testing once everything is ready. I do have a few comments.

1. Handle expired certs

You can use a similar middleware as db, but there is no need to LocalProxy.CheckCertSubject with db route. I would suggest split LocalProxy.CheckDBCerts to have a separate LocalProxy.CheckCertExpiry without the CheckCertSubject part, and use that for App Access.

2. Definitely a stretch, is Teleport Connect able to render web pages? =p. HTTP apps renders web pages in Web App. Wonder Teleport Connect can do both WebPage and terminal modes.

3. I see cloud apps (AWS/Azure/GCP) are unsupported for now. Likely will need quite some refactoring so the same logic can be shared between tsh and Connect. 😭

[gzdunek]

Handle expired certs
You can use a similar middleware as db, but there is no need to LocalProxy.CheckCertSubject with db route. I would suggest split LocalProxy.CheckDBCerts to have a separate LocalProxy.CheckCertExpiry without the CheckCertSubject part, and use that for App Access.

Thanks for the advice! In the end, we decided to move this part out of this PR and address it separately (you can see all tasks here), so it won't block this PR.

Definitely a stretch, is Teleport Connect able to render web pages? =p. HTTP apps renders web pages in Web App. Wonder Teleport Connect can do both WebPage and terminal modes.

We want to support web apps, but by opening them a browser.

I see cloud apps (AWS/Azure/GCP) are unsupported for now. Likely will need quite some refactoring so the same logic can be shared between tsh and Connect. 😭

Yes, supporting cloud apps required more work, so we left it unsupported (unfortunately, we don't have much time until v15 release).

[ravicious]

I looked through most of the UI code, but I'm yet to actually use it.

[ravicious]

I left comments about some UI stuff that I think we should address and about a bunch of minor things, but other than that it looks good. 👍

[gzdunek]

I merged the PR that unifies gateway offline screens, so this PR now uses the correct screen.

[ravicious]