Connect: Accommodate for making gRPC server creds in shared process

[ravicious]

Equivalent Teleport PR: gravitational/teleport#16782.

On Windows, we use gRPC over TCP with mTLS since Node.js doesn't support UDS on Windows. Each process creates its own keypair and saves the public key to a predetermined location.

Up until now, these were the client-server pairs we had to support:

Server	Client
tsh daemon	renderer
shared (Electron process)	renderer

For tshd-initiated communication, the tshd process will need to create a client that will connect to a gRPC server operated by the renderer process of the Electron app.

grpcCredentials refactor

packages/teleterm/src/services/grpcCredentials used to look like this:

packages/teleterm/src/services/grpcCredentials/
├── clientCredentials.ts
├── helpers.ts
├── index.ts
├── makeCert
├── serverCredentials.ts
└── types.ts

Now it looks like this:

packages/teleterm/src/services/grpcCredentials/
├── credentials.ts
├── files.ts
├── index.ts
├── makeCert
└── types.ts

clientCredentials.ts and serverCredentials.ts contained logic that was specific to a concrete process (renderer for clientCredentials). I extracted generic functions from those files. The orchestration of credentials for each process happens now in that process' main file.

Instead of having a catch-all helpers.ts or utils.ts file, I split the generic functions into functions that operate primarily on files (files.ts) and functions that work with credentials (credentials.ts). IMHO it's very important to do that – having a utils.ts file is almost always a bad choice as it signals that we didn't spend enough time thinking how the contents of that file fit into the general structure of the project.

• https://dave.cheney.net/2019/01/08/avoid-package-names-like-base-util-or-common
• https://breadcrumbscollector.tech/stop-naming-your-python-modules-utils/
• https://www.adam-bien.com/roller/abien/entry/class_naming_suffix_util_is

[ravicious]

Now that we're going to have both a gRPC client and a gRPC server in the renderer process, the name "client" stopped being sufficient. I refactored this so that it closer reflects what we want to achieve with gRPC certs – each process owns its own key pair, keeps the private key in memory and the public key is saved to the file.

[ravicious]

This was just moved from the bottom of the file to the top, before function declarations so that you can immediately see what's going to be executed when this file is loaded.

[ravicious]

To my surprise, Go didn't complain when a cert without this was used as a client cert, but it was a problem when I tried to use it as a server cert for the client credentials.

[avatus]

I like it and I'm excited for what it leads to. Also, side note: what a succinct and informative PR.

[avatus]

What happens if any of these promises fail?

[ravicious]

createGrpcCredentials will throw, then after it getElectronGlobals will throw. getElectronGlobals gets exposed through contextBridge as window.electron:

webapps/packages/teleterm/src/preload.ts

Line 33 in be9639e

contextBridge.exposeInMainWorld('electron', getElectronGlobals());

It's used in boot.tsx:

webapps/packages/teleterm/src/ui/boot.tsx

Lines 13 to 14 in be9639e

	try {
	const globals = await getElectronGlobals();

getElectronGlobals in boot.tsx calls window.electron underneath, so it will fail as well, triggering the catch branch:

webapps/packages/teleterm/src/ui/boot.tsx

Lines 28 to 30 in be9639e

	} catch (e) {
	logger.error('Failed to boot the React app', e);
	renderApp(<FailedApp message={e.toString()} />);

This will show the error to the user in the actual browser window.

[gzdunek]

Well done @ravicious! I don't have any comments to the code, I have to try it out (I'll do it on Monday).

[gzdunek]

Works nicely!

[ravicious]

I’m going to backport this once v11.0.0 is released.