What is the issue?

For security reasons many companies man-in-the-middle all SSL traffic to the internet with their own certificate. This causes a x509: certificate signed by unknown authority issue in two spots for dagger:

1. Dagger engine. This is easy to solve by mounting the certificates in the container.
2. Dagger modules. The modules appear to be loading a tar container /usr/local/share/dagger/go-module-sdk-image.tar and building a go program when running any module command. The commands all fail when the go build does a go get for dependencies and hits the same x509 issue.

Steps I have tried to work around this issue:

1. Building a ModuleRuntime as recommended in the discord thread here. I quickly found that all the existing module runtimes point back to go as a dependency, which was the issue.
2. Putting my certificates in the engine and the tar container. This resolves the certificate issues but breaks modules for some reason. On a fresh project (or any project) made with dagger mod init it would always fail with "main object not found".

Posting this as recommended in discord since there appears to be no workarounds and modules are completely broken in this environment.

Dagger version

v0.9.6

Steps to reproduce

No response

Log output

No response

Current Solutions

(this section and below is from edits by @sipsma)

Proxy Support

As of v0.11.4, the engine has support for "standard" proxy envs: HTTP_PROXY, HTTPS_PROXY, NO_PROXY, ALL_PROXY, and FTP_PROXY.

• If any of these env vars are set on the engine container (e.g. registry.dagger.io/engine:v0.11.4) they will be automatically passed to all containers started by the engine.
• They will be passed in both UPPER and lower case to support applications that have a preference for one or the other.
• These values also will be honored for internal operations (such as pulling containers).
• Changing these values has no impact on the caching of operations.
• If a container has any of these values explicitly set, the engine will not override them with the values from the system.

Additionally, we also support custom GOPROXY values being set on the Go SDK (only the Go SDK for now, not all containers).

• In this case, the engine needs to be provisioned with an environment variable _DAGGER_ENGINE_SYSTEMENV_GOPROXY=<value>

Custom CA Support

The engine also has support for use of custom CAs. When configured, the engine will use them for any of its internal requests (e.g. pulling/pushing container images) and makes a best-effort attempt at installing them in every container started by the engine (explained more below).

There was a bug in v0.11.4, so currently you will need to use the engine image registry.dagger.io/engine:2ae9f4d815c1fcf48626ce9437c788d0efb91a79 which is a build off of our main branch.

• The next release will have this fix in place.

To configure the engine with custom CA certs, you will need to provision a custom engine with the certs placed in the directory /usr/local/share/ca-certificates.

• This is all that's needed, the engine will see those on startup and run update-ca-certificates automatically so they are configured for use from there.

The support for automatic installation in all containers is best-effort because CA certificates are very far from standardized and their configuration depends on the distro of the base image of the container being installed into.

• We currently have support for:
  • Alpine
  • Debian based distros (debian, ubuntu, etc.)
  • RHEL based distros (rhel/ubi, fedora, centos, etc.)

If a container is supported, CAs will be installed before the container runs and uninstalled after it finishes.

• This is to ensure that no CA certs leak into any images that are published from containers created by Dagger
• This unfortunately adds some performance overhead, though it remains to be seen how much in practice and whether it's actually a noticeable bottleneck. Feedback on this from real-world users will be appreciated!

If a container is not supported or a non-fatal error is hit during installation, then Dagger will not fail the exec and instead just continue on without the CAs installed.

• If you hit this situation, let us know and we can look into adding support.
• A workaround in the mean time is to explicitly install them into containers (i.e. withMountedFile).

Further support planned

Support for client-side settings

We should add support for configuring CA certs and proxy settings from the client side. This is intended for corporate use-cases where Dagger users are on a machine that also has all these settings available+configured to the same values that the engine should use (whether or not it's on the same machine).

The values may be set either from env vars, a config file, or both. Leaving that open as TBD for now, but will note that if env vars are supported we should require them to have a specific prefix like DAGGER_ENGINE_ to ensure that users more explicitly opt-in to these values being propagated to their pipelines.

This helps solve the problem of needing to custom provision an engine to set these values, though only for users that have these settings available client-side.

Generalized custom proxy support

Right now GOPROXY is supported only for our Go SDK. We also don't have support for other language/application specific proxy settings other than the "standard" ones mentioned above (HTTP_PROXY, HTTPS_PROXY, etc.).

This is fairly limiting, so we need to design a way for more arbitrary support for passing system-wide application-specific proxy settings to containers. The current workaround is to explicitly set them on containers, but that has the problem of being tedious/boilerplate-y and also includes those values in the cache key of the operations, which invalidates them if they change.