Forward SSL env variables to containerization

[sebimarkgraf]

• Fixes [Bug]: failed to verify certificate with self signed certs #305.

Type of Change

• Bug fix
• New feature
• Breaking change
• Documentation update

Motivation and Context

This is a follow-up to apple/containerization#402 allowing to easily use container with custom SSL proxies.
Especially in corporate setups, using an HTTPS Proxy is quite common for varying reasons and by following common coventions of env variables, container can be used easily without additional setup.

Testing

• Tested locally
• Added/updated tests
• Added/updated docs

Tagging @dcantah as he did the upstream PR review and this here is only the plumbing not the core change.

[jglogan]

@sebimarkgraf If there isn't one, could you make an issue for this describing with examples what this enhances or fixes?

Also, please rebase onto the latest main as ContainerClient is gone, updating your imports if needed:

• ContainerAPIClient has the actual client code
• ContainerResource has the core types
• ContainerSandboxServiceClient has the sandbox client code (unlikely you're using this though)

[sebimarkgraf]

I will rebase and update today.

This fixes #305 by being able to provide custom certificates via the standard env variables.
I can write a more extensive feature issue if you think this is helpful.

[jglogan]

Thanks! I'll update the PR description.

[jglogan]

Can you drop REQUESTS_CA_BUNDLE and CURL_CA_BUNDLE? We shouldn't be evaluating variables that are specific to Python requests or curl.

We should only use SSL_CERT_FILE (Go honors that one), and make the corresponding revert in containerization as well.

[dcantah]

I agree with the above, sorry for approving the other two over in containerization. Those two seem odd looking back now, but the ssl_* ones are fairly standard across the board.

[jglogan]

We should only use SSL_CERT_FILE (Go honors that one)

Actually I think Go might only use that env variable on Linux.

@sebimarkgraf @dcantah let's use this issue to circle back on both this and apple/containerization#402.

Has this fix been verified in an environment that uses both a registry with a self-signed cert and registries that need the system trust store? Will the utility code only make it such the either a self-signed cert will be used or the system trust store, but not both?

public enum TLSUtils {

    public static func makeEnvironmentAwareTLSConfiguration() -> TLSConfiguration {
        var tlsConfig = TLSConfiguration.makeClientConfiguration()

        // Check standard SSL environment variables in priority order
        let customCAPath =
            ProcessInfo.processInfo.environment["SSL_CERT_FILE"]
            ?? ProcessInfo.processInfo.environment["CURL_CA_BUNDLE"]
            ?? ProcessInfo.processInfo.environment["REQUESTS_CA_BUNDLE"]

        if let caPath = customCAPath {
            tlsConfig.trustRoots = .file(caPath)
        }
        // else: use .default

        return tlsConfig
    }
}

[sebimarkgraf]

Agree with the reasoning, included them as these are the ones I usually look for.

Reduced the list here to SSL_CERT_FILE.

Fix has only been tested in an environment where my proxy has a self-signed cert via SSL_CERT_FILE.
Let me try to create a script

[jglogan]

Thanks! I don't have a problem with us getting this feature in place as the use case (I have a private/local registry with a self-signed certificate and want to use it without having to allow the cert to be used system-wide).

I wonder about the naming. SSL_CERT_FILE is used by all kinds of libraries (libssl, Go, various Rust TLS libraries) with varying meaning and applicability. It might make more sense to use a container-specific variable name that indicates the semantics.

If we chose CONTAINER_CERT_FILE, setting it would override the system trust store, which I believe is consistent with what apple/containerization#402 does.

If we chose CONTAINER_ADDITIONAL_CERT_FILE, setting it would use both the system trust store and the additional cert, which would require a change to the TLS utility function you created.

There are of course other more complicated possibilities but let's make sure we (including @dcantah and anyone else interested!) all agree on the use case and then deliver the simplest feature that satisfies it.