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

Abierto
  • ¿Algo no está bien?
#1,334 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
35/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
docker, typescript
Área
devtools, infrastructure

Línea de trabajo

Start by reading the CLI entry points and build and up flows that handle image builds and container startup. The issue describes host certificate injection during both flows, including temporary mounts, live updates, host store selection, and support for common container distributions. Done means an approach is defined for these cases and certificates are available in the target container's standard store.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
TypeScript
Estrellas
3k
Forks
473
Merge medio
10 h 31 min
PR fusionados (30 d)
9

Preparar el entorno

Abrir en Codespaces

Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de devcontainers/cli

Todos los issues de devcontainers/cli

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.