Credentials

Attention

Ne mettez jamais de credentials dans imglife.yaml. Toute l’authentification se fait via des variables d’environnement.

imglife utilise deux ensembles de credentials :

1. Package Registry — pour stocker/lire les métadonnées de build (GitLab, Gitea, ou S3).
2. Registries OCI — pour tirer/pousser des images Docker.

Credentials Package Registry

Provider	Variable	Scopes requis
GitLab	GITLAB_TOKEN	api, read_packages, write_packages, read_registry, write_registry
Gitea	GITEA_TOKEN	scope package, write:repository (pour git push en CI)
S3 / Garage	AWS_ACCESS_KEY_ID + AWS_SECRET_ACCESS_KEY	s3:GetObject, s3:PutObject, s3:DeleteObject, s3:ListBucket

# GitLab
export GITLAB_TOKEN=glpat-xxxxxxxxxxxxxxxxxxxx

# Gitea
export GITEA_TOKEN=giteatoken...

# S3
export AWS_ACCESS_KEY_ID=AKIA...
export AWS_SECRET_ACCESS_KEY=secret...

Credentials registries OCI

Les credentials OCI utilisent une convention de nommage basée sur le hostname normalisé :

Règle de normalisation : hostname → majuscules → remplacer les caractères non-alphanumériques par _.

Hostname	Normalisé	Préfixe variable
docker.io	DOCKER_IO	IMGLIFE_DOCKER_IO_
quay.io	QUAY_IO	IMGLIFE_QUAY_IO_
ghcr.io	GHCR_IO	IMGLIFE_GHCR_IO_
registry.example.com	REGISTRY_EXAMPLE_COM	IMGLIFE_REGISTRY_EXAMPLE_COM_
registry:5000	REGISTRY_5000	IMGLIFE_REGISTRY_5000_

Trois méthodes d’authentification :

Utilisateur + mot de passe

export IMGLIFE_DOCKER_IO_USERNAME=monuser
export IMGLIFE_DOCKER_IO_PASSWORD=monmotdepasse

Token (variable unique)

export IMGLIFE_QUAY_IO_TOKEN=montoken
export IMGLIFE_GHCR_IO_TOKEN=ghp_...

Login Docker CLI (fallback)

Si aucune variable IMGLIFE_* n’est définie pour un hôte, imglife se rabat sur ~/.docker/config.json. Un docker login préalable fonctionne donc automatiquement.

Rate limiting Docker Hub

Docker Hub impose des limites sur les téléchargements pour les comptes anonymes et gratuits. Fournissez toujours des credentials Docker Hub :

export IMGLIFE_DOCKER_IO_USERNAME=monuser
export IMGLIFE_DOCKER_IO_PASSWORD=dckr_pat_...

En CI, stockez-les comme variables CI masquées :

• GitLab : Settings > CI/CD > Variables
• Gitea : Repository Settings > Secrets

Token CI GitLab

Dans GitLab CI, le CI_JOB_TOKEN intégré est automatiquement utilisé pour le registry de votre projet ($CI_REGISTRY). Vous n’avez pas besoin de définir des variables IMGLIFE_* pour celui-ci.

Pour un accès cross-projet au registry, utilisez un token de compte de service dédié.

Registries source privés

Pour les entrées de sync qui tirent depuis des registries privés :

sync:
  entries:
    - source: quay.io/prometheus/prometheus
      # ...

export IMGLIFE_QUAY_IO_TOKEN=montoken

Registries non sécurisés (HTTP)

Pour le développement local avec des registries en HTTP simple :

registry:
  url: http://registry.local:5000
  insecure_registries:
    - registry.local:5000

# Credentials pour le registry non sécurisé
export IMGLIFE_REGISTRY_LOCAL_5000_USERNAME=admin
export IMGLIFE_REGISTRY_LOCAL_5000_PASSWORD=password

Scopes minimaux des tokens

Suivez le principe du moindre privilège :

Opération	Scopes requis
sync	Lire source, écrire target OCI ; pas d’accès Package Registry
build	Écrire target OCI ; pas d’accès Package Registry
cleanup	Supprimer OCI ; pas d’accès Package Registry
register	Écrire Package Registry ; pas d’accès OCI
status	Lire Package Registry ; pas d’accès OCI
check	Lire Package Registry ; pas d’accès OCI
eol update	Écrire Package Registry (si eol_target: pkgregistry) ; pas d’accès OCI

Pour un pipeline base-images typique, un seul token avec tous les scopes suffit. Pour les projets applicatifs (check + register uniquement), un token en lecture seule plus l’écriture de packages suffit.