Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Boulder without CGO #7931

Open
mcpherrinm opened this issue Jan 10, 2025 · 0 comments
Open

Boulder without CGO #7931

mcpherrinm opened this issue Jan 10, 2025 · 0 comments

Comments

@mcpherrinm
Copy link
Contributor

Background

This isn't planned anytime soon, but something that was on my mind so I thought I'd record some notes.

It would be nice to be able to build Boulder without CGO. That would facilitate easier cross-compilation at least, such as building on arm64 laptops, or deploying binaries from GHA to arm64 cloud instances

I believe the only place we use CGO is for PKCS#11 to talk to the HSM.

Options

P11-kit remoting

We switch to some other standard interface for talking to HSMs. For example, the p11-kit "remoting" protocol for PKCS11 is used in AWS Nitro Enclaves as its interface, and we could use the p11-kit server to wrap our vendor's pkcs11 library. I think there may be other options here too

Subprocess

Use a process-based plugin model to isolate the C_GO code. I think something like Hashicorp's go-plugin could be either used, or serve as a model. Approximately, this means boulder_ca manages a subprocess that handles the CGO parts. All of the configuration for Boulder stays the same, probably just with the addition of a path to the plugin process. go-plugin executes a subprocess and communicates with it over grpc via the subprocess' stdin/stdout, eliminating the need to worry about anything like unix socket paths, permissions, and so on. Or even one-execution-per-signing, but that sounds inefficient.

Sidecar

Pull the core of signing out into a minimal, independent sidecar service. Could be grpc-over-unix socket or similar. It handles all the details of PKCS11 configuration, etc. This does mean we need to be careful about permissions, to ensure only boulder-ca can access the socket. However, this does mean we can do things like run separate containers for the HSM/PKCS11 code, which may be advantageous for other reasons as well.

boulder-ca with CGO

Split all of boulder-ca into its own binary built with CGO, and the rest of boulder can be built without CGO.

Performance

Because we run dedicated, isolated instances for boulder-ca, we have plenty of memory and CPU available, so latency is the only performance concern.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant