dynamic overlays
- Langage dominant
- Rust
- Étoiles
- 2.3k
- Forks
- 230
- Merge moyen
- 3 j 3 h
- PR mergées (30 j)
- 36
Description
This overlaps with https://github.com/containers/bootc/issues/7 some.
Here, the basic idea is something like:
```
bootc config add [--root=/etc] examplecorp.com/config:latest
```
Where `config.yml` is a standard [Kubernetes ConfigMap](https://kubernetes.io/docs/concepts/configuration/configmap/). By default, we "mount" the keys to `/etc`. Then, `bootc upgrade` looks for updates to all provided configmaps - if any change, it triggers the same upgrade logic as the base image.
We also fetch and handle secret objects in the same way. It'd be cool though to support something like handling encrypted secrets (and configmaps) which need to be decrypted via a key (which could be in a TPM or so).
We also need to think carefully about file permissions; mode 0644 for all configmap files and 0600 for secrets may make sense. In addition we could support special annotations to override these.
(This should also work to be invoked immediately after `bootc install` to have it ready on the first boot, i.e. we also have a `--root` argument or so)
Guide de contribution
Ouvrir le guide de contribution
Piste de recherche
L’issue n’indique aucun fichier ni test ; commencez par localiser les points d’entrée des commandes pour bootc config add, bootc install et bootc upgrade. Définissez le périmètre de la récupération de ConfigMap et des secrets, du montage sous --root, des mises à niveau déclenchées par les mises à jour, des permissions et de la gestion du premier démarrage avant l’implémentation.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Évaluation
- Stack technique
- kubernetes, rust
- Domaine
- cli, operating-systems, security
- Type d'issue
- Fonctionnalité
- Difficulté
- 5/5
- Temps estimé
- Plus d'une semaine
- Activité
- À l'abandon
- Clarté
- À clarifier
- Accessibilité débutants
- 20/100