Skip to content

Provide a way to map in host certificate store(s) to started devcontainers #1334

Open

Description

Inspired by the recent 8 compromised intermediate certificates, I would like a way to mount my host's certificate stores into any images started with devcontainer up, or built with devcontainer build.

The fundamental problem is that outgoing network traffic in a devcontainer relies on certificates baked into the container. Depending on the particular definition, this could be quite old, and if the container was prebuilt by another part, not in the developer's control. This also causes some difficulties with things like MitM interceptors in corporate settings, where certificates are often present on the host, but for obvious reasons not present in standard certificate stores.

  • Injection during devcontainer build is necessary to account for dynamic feature build, as otherwise features need to use certificates already present in lower layers in the container. The common-utils feature does install the common platform root certificates, and it's possible to write a custom install-first feature for things like MitM roots, but both of these generally end up baking the certificates into the root image, which is precisely the problem. Injecting the certificates during build alleviates both of these issues. Note that these certificates would be intended to be some form of temporary mount, to prevent baking them into the image.
  • Injection during devcontainer up would be necessary to provide "live" certificate updates.

I'd prefer some way to do one or all of the following;

  • If no options are specified, inject all root certificates from the host standard store into the container.
  • A way to specify a particular host store. On linux this would probably be automatic via standard OpenSSL environment variables, but on Windows this would probably be one of the special store names.
  • A way to supply one or more certificate bundle names/paths.

It would be anticipated that the certificates would be placed in the in-container OS's standard certificate store; or, for the more common base distros, at least. These are well-known locations, and generally have ways to add user-supplied certificates outside of the distro-provided root certificates.

Activity

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions