Support using corporate proxies

[ascopes]

What is the problem you're trying to solve?.

I would like to be able to run Finch on my Machine that is running behind a corporate proxy with MITM-SSL manipulation.

Describe the feature you'd like

I want to be able to provide some configuration in my finch.yaml that instructs Finch to load in CA bundles from some path on my machine during the initial creation of a Finch VM.

Lima supports this natively, and I can confirm that "hacking in" the CA bundles by modifying what Lima is doing during the provision process works, but this feels like a fairly big bodge, and is not documented anywhere in the Finch documentation.

ca_bundle_path="/path/to/bundle.pem"

yq e '.' -o json /Applications/Finch/os/finch.yaml \
  | jq -e '. * { caCerts: { files: [ $ca_bundle_path ] } }' --arg ca_bundle_path "${ca_bundle_path}" \
  | yq -o yaml -P > /Applications/Finch/os/finch.yaml.new

mv /Applications/Finch/os/finch.yaml{.new,}

Effectively, in /Applications/Finch/os/finch.yaml, the following config has to be added upon finch creating this configuration for the first time:

caCerts:
  files:
    - /path/to/bundle.pem

Additional context

Raised also under AWS Support Case ID 176435092100995.

When running using a Corporate Proxy that has its own SSL certificates, bringing up a Finch VM is problematic. Right now, upon first boot, we observe that finch vm init just hangs for about 15 minutes and then crashes.

Upon pulling all of this configuration and code to pieces, I found that the problem lies within the ISO that is downloaded. The script causing us problems is the following:

#!/bin/sh

# SPDX-FileCopyrightText: Copyright The Lima Authors
# SPDX-License-Identifier: Apache-2.0

set -eux

# Check if cloud-init forgot to reboot_if_required
# (only implemented for apt at the moment, not dnf)

if command -v dnf >/dev/null 2>&1; then
	# dnf-utils needs to be installed, for needs-restarting
	if dnf -h needs-restarting >/dev/null 2>&1; then
		# needs-restarting returns "false" if needed (!)
		if ! dnf needs-restarting -r >/dev/null 2>&1; then
			systemctl reboot
		fi
	fi
fi

Specifically, take not of the if ! dnf needs-restarting -r >/dev/null 2>&1; then systemctl reboot. Whilst it is true that dnf needs-restarting will return a non-zero exit code if we need to reboot, it also returns a non-zero exit code if it failed to complete.

It turns out that dnf needs-restarting dials out to the Fedora repository mirrors... under a corporate proxy that operates on L3/L4 (e.g. as part of a ZTNA), this won't work. You'll just get the following output (which is somewhat unhelpfully suppressed and sent to /dev/null here):

└─[127] <> docker run --rm -it fedora                               
[root@97829c00283b /]# dnf needs-restarting
Updating and loading repositories:
 Fedora 42 - aarch64 - Updates                                                                                             ???% [  <=>             ] |   0.0   B/s |   0.0   B |  00m01s
>>> Curl error (60): SSL peer certificate or SSH remote key was not OK for https://mirrors.fedoraproject.org/metalink?repo=updates-released-f42&arch=aarch64 [SSL certificate problem: u
>>> Curl error (60): SSL peer certificate or SSH remote key was not OK for https://mirrors.fedoraproject.org/metalink?repo=updates-released-f42&arch=aarch64 [SSL certificate problem: u
>>> Curl error (60): SSL peer certificate or SSH remote key was not OK for https://mirrors.fedoraproject.org/metalink?repo=updates-released-f42&arch=aarch64 [SSL certificate problem: u
>>> Curl error (60): SSL peer certificate or SSH remote key was not OK for https://mirrors.fedoraproject.org/metalink?repo=updates-released-f42&arch=aarch64 [SSL certificate problem: u
>>> Curl error (60): SSL peer certificate or SSH remote key was not OK for https://mirrors.fedoraproject.org/metalink?repo=updates-released-f42&arch=aarch64 [SSL certificate problem: u
...

This then exits with a non-zero exit code.

This means if you have no side-loaded CA certificates, finch vm init will get stuck in a loop of repeatedly restarting the VM every 5 seconds or so, while providing no output of what the issue is, since everything is sent to /dev/null.