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

Aperta
  • Qualcosa non va?
#1,334 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
docker, typescript
Ambito
devtools, infrastructure

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
TypeScript
Stelle
3k
Fork
473
Merge medio
10h 31m
PR unite (30g)
9

Preparare l'ambiente

Apri in Codespaces

Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di devcontainers/cli

Tutte le issue di devcontainers/cli

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.