Skip to content

build: passe l'image sur Docker Hardened Images (Python 3.14) - #19

Open
Mandrak-Kimigo wants to merge 1 commit into
mainfrom
feat/dhi-python-3.14
Open

Mandrak-Kimigo wants to merge 1 commit into
mainfrom
feat/dhi-python-3.14

Conversation

@Mandrak-Kimigo

Copy link
Copy Markdown
Collaborator

Pourquoi

L'image actuelle (python:3.12-slim) embarque un shell, apt et une bonne partie de Debian, que tokenlab n'utilise pas au runtime. Pour un outil qui manipule des tokens OIDC, c'est de la surface d'attaque et des CVE remontées par les scanners pour rien.

Les Docker Hardened Images (dhi.io/python:3.14-debian13) apportent :

  • une image runtime minimale, sans shell ni gestionnaire de paquets, avec quasi aucune CVE ;
  • SBOM, provenance SLSA et VEX signés ;
  • un utilisateur non-root par défaut (nonroot, uid 65532) ;
  • une image deux fois plus légère : 196 Mo contre 469 Mo.

Le passage à Python 3.14 se fait sans changer uv.lock : tous les paquets compilés ont déjà un wheel cp314 manylinux.

Changements

  • Dockerfile : build en deux stages.
    • build (dhi.io/python:3.14-debian13-dev) : uv sync --frozen --no-dev, avec UV_PYTHON_DOWNLOADS=never pour que le venv utilise le Python de l'image, et UV_COMPILE_BYTECODE=1 parce que l'image runtime est en lecture seule pour nonroot.
    • runtime (dhi.io/python:3.14-debian13) : on y copie seulement .venv et app/.
    • apt-get install ca-certificates (les certificats CA sont fournis par l'image) et la création de l'utilisateur 10001 sont supprimés.
    • HTTP_VERIFY_TLS=true reste figé au build, comme avant.
  • .github/workflows/build-image.yml : nouveau step Login to DHI, qui utilise les secrets d'organisation DOCKERHUB_USERNAME / DOCKERHUB_TOKEN (le pull depuis dhi.io exige une authentification).
  • .gitlab-ci.yml : kaniko reçoit les identifiants dhi.io en plus de ceux du registre GitLab ; le job ruff passe sur python:3.14-slim.
  • CONTRIBUTING.md :
    • nouveau pré-requis : docker login dhi.io pour builder en local ;
    • la section Sécurité dit maintenant que HTTP_VERIFY_TLS vaut true par défaut ;
    • correction MD032.

Tests en local

  • docker build OK
  • démarrage avec .env, GET / → 200
  • Python 3.14.10, uid 65532, pas de shell (sh: executable file not found)
  • certificats CA présents, appel HTTPS sortant OK
  • login Keycloak complet (standard flow) via host.docker.internal

Points d'attention

  • Debug : plus de kubectl exec ... sh possible, utiliser kubectl debug avec un conteneur éphémère.

🤖 Generated with Claude Code

L'image de base devient dhi.io/python:3.14-debian13 pour réduire la
surface d'attaque (pas de shell ni de gestionnaire de paquets au
runtime, quasi aucune CVE, SBOM et provenance signés) et diviser la
taille de l'image par deux (196 Mo contre 469 Mo).

- Dockerfile en deux stages : dépendances installées avec uv dans la
  variante -dev, seul le venv est copié dans l'image runtime.
  L'utilisateur nonroot (uid 65532) de DHI remplace l'utilisateur
  10001 créé à la main ; les certificats CA sont fournis par l'image.
- CI GitHub et GitLab : login sur dhi.io avec DOCKERHUB_USERNAME /
  DOCKERHUB_TOKEN (pull authentifié obligatoire), en plus du registre
  de publication.
- Job ruff GitLab aligné sur Python 3.14.
- CONTRIBUTING : docker login dhi.io requis pour builder en local ;
  section Sécurité corrigée (HTTP_VERIFY_TLS vaut true par défaut) ;
  ligne vide avant une liste (MD032).

Testé en local : build, démarrage, login Keycloak complet.

Signed-off-by: Mandrak-Kimigo <amaury.cormier@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant