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

Aberta
  • Algo errado?
#1,334 0 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
5/5
Tempo estimado
Mais de uma semana
Facilidade para iniciantes
35/100
Tipo de issue
Funcionalidade
Clareza
Razoavelmente clara
Status de atividade
Ativa
Stack de tecnologia
docker, typescript
Domínio
devtools, infrastructure

Direção de pesquisa

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.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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.

Linguagem predominante
TypeScript
Estrelas
3k
Forks
473
Merge médio
10h 31min
PRs com merge (30d)
9

Preparar o ambiente

Abrir no Codespaces

Inicia o contêiner de desenvolvimento do projeto no navegador, com a sua própria conta do GitHub.

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de devcontainers/cli

Todas as issues de devcontainers/cli

Issues semelhantes

Mais issues de TypeScript

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.