Gitea Runner 3.0.0 est désormais disponible, avec des améliorations majeures pour la sécurité et la gestion des workflows. Cette version introduit la prise en charge native des actions standard de cache et d'artefacts de GitHub Actions, rendant ainsi inutile le fork « gitea-upload-artifact ». Elle met également en œuvre un renforcement de la sécurité contre les échappements de conteneurs en supprimant les options Docker potentiellement dangereuses des workflows non privilégiés. De plus, le runner applique désormais la règle « un processus par fichier .runner » afin d'éviter les annulations de tâches causées par des conflits d'identifiants.Gitea est un logiciel de forge permettant d'héberger le contrôle de version du développement logiciel à l'aide de Git, ainsi que d'autres fonctionnalités collaboratives telles que le suivi des bogues, la révision de code, l'intégration continue, les tableaux Kanban, les tickets et les wikis. Il prend en charge l'auto-hébergement et fournit également une instance publique gratuite gérée par l'éditeur. Il s'agit d'un fork de Gogs, écrit en Go et en TypeScript. Gitea peut être hébergé sur toutes les plateformes prises en charge par Go, notamment FreeBSD, Linux, macOS, OpenBSD et Windows. Le projet est financé sur Open Collective.
Gitea est un service Git open source issu d'un fork de Gogs en 2016. Bien que Gogs fût open source, son dépôt était contrôlé par un seul responsable. Face à ces limites, les développeurs de Gitea ont décidé de créer un fork de Gogs en novembre 2016, instaurant ainsi un modèle de développement piloté par la communauté. La version officielle 1.0 de Gitea a été lancée en décembre 2016.
En octobre 2022, les responsables Lunny Xiao et Matti Ranta ont fondé la société Gitea Limited dans le but de proposer des services d'hébergement utilisant des versions spécialisées et propriétaires de Gitea, répartissant ainsi les variantes prises en charge de Gitea entre l'installation fournie par Gitea Limited et la version originale sous licence MIT. En réponse, Codeberg, l'une des principales plateformes de gestion de projets utilisant Gitea à l'époque, a créé un fork de Gitea appelé Forgejo.
Gitea Runner 3.0.0 est désormais disponible et introduit la prise en charge native des actions standard de cache et d'artefacts de GitHub Actions, rendant ainsi inutile le fork « gitea-upload-artifact ». Cette version met également en œuvre un renforcement de la sécurité contre les échappements de conteneurs en supprimant les options Docker potentiellement dangereuses des workflows non privilégiés. De plus, le runner applique désormais la règle « un processus par fichier .runner » afin d'éviter les annulations de tâches causées par des conflits d'identifiants.
Voici l'annonce de la sortie de Gitea Runner 3.0.0 :
Sortie de Gitea Runner 3.0.0
La principale nouveauté de cette version est le service de cache v2 : les actions standard actions/upload-artifact, actions/download-artifact et actions/cache fonctionnent désormais avec un Gitea Runner sans le fork gitea-upload-artifact. Par ailleurs, la version 3.0.0 ajoute un renforcement de la sécurité « container-escape », le masquage des secrets encodés, des hooks de tâches et la propagation par proxy, ainsi qu’une protection empêchant deux démons de partager un même fichier de runner.
Il s’agit d’une version côté runner. Elle reste compatible au niveau de la communication avec les versions existantes de Gitea ; l’augmentation du numéro de version majeur reflète trois changements de compatibilité ascendante plutôt qu’une nouvelle dépendance serveur.
Nouveautés de la version 3.0.0
Actions sur les artefacts et le cache par défaut — aucun fork requis
Gitea Runner prend désormais en charge l'API github.actions.results.api.v1.CacheService(v2) de GitHub Actions, en plus de l'API de cache v1 existante, en partageant le même stockage, ainsi que le sous-ensemble du protocole Blob d'Azure utilisé par l'outil de téléchargement @actions/toolkit.
Concrètement, cela signifie que les actions en amont non modifiées fonctionnent :
Les actions actions/upload-artifact et actions/download-artifact (à partir de la version 4.4.0) ainsi que actions/cache ne nécessitent plus le fork gitea-upload-artifact ni de solutions de contournement personnalisées. Le runner applique des correctifs aux bundles d’actions au moment du chargement afin d’ouvrir la passerelle GHES et de lire le point de terminaison du cache à partir de ACTIONS_CACHE_URL ; cela a été validé sur 118 bundles réels couvrant 16 actions.
Renforcement de la sécurité contre les évasions de conteneur
Lorsque le mode privilégié est désactivé, les options de conteneur contrôlées par le workflow ne sont plus intégrées telles quelles dans le fichier HostConfig de Docker. Le runner supprime désormais les options pouvant être utilisées pour contourner l’isolation du conteneur :
PidMode, IpcMode, UTSMode, CgroupnsMode, UsernsMode, CapAdd, SecurityOpt, Devices, DeviceCgroupRules, DeviceRequests, VolumesFrom, Runtime, CgroupParentet Sysctls.
Ces options sont conservées lorsqu’un administrateur active explicitement le mode privilégié, car cela signifie déjà l’acceptation d’un accès étendu à l’hôte. Il s’agit d’un changement rompant pour les workflows qui s’appuyaient sur ces options sur un runner non privilégié.
Masquage des secrets encodés
Auparavant, seule la valeur brute d’un secret était masquée ; ainsi, un secret divulgué par une action qui le sérialisait restait lisible dans les journaux. Chaque secret et chaque valeur ::add-mask:: sont désormais également masqués sous leurs formes encodées, conformément aux encodeurs de valeurs utilisés par le runner de GitHub :
- JSON — valeurs échappées via toJSON(secrets)
- Base64 — par exemple, les secrets contenus dans un en-tête Authorization
- Encodage URL en pourcentage — secrets intégrés dans des URL
Les encodages qui laissent la valeur inchangée sont ignorés ; ainsi, un jeton en clair ne nécessite toujours qu’une seule paire de remplacement.
Hooks de tâche
Les opérateurs peuvent désormais exécuter un script hôte au sein de l'environnement de la tâche à deux moments clés de son cycle de vie, à l'instar des hooks ACTIONS_RUNNER_HOOK_JOB_STARTED et ACTIONS_RUNNER_HOOK_JOB_COMPLETED de GitHub :
La fonction job_started s’exécute avant la première étape du job et la fonction job_completed après la dernière. Toutes deux analysent leur sortie à la recherche de commandes de workflow, relisent les variables $GITHUB_ENV et $GITHUB_PATH, et font échouer le job en cas de code de sortie différent de zéro. Cela s’avère utile pour précharger les caches, provisionner des identifiants ou générer des données de télémétrie pour chaque job.
Propagation du proxy
Le runner définit désormais les variables http_proxy, https_proxy et no_proxy (en minuscules et en majuscules) afin que tous les éléments qu’il contrôle les utilisent : les jobs, les conteneurs de service et les builds d’actions Dockerfile. Les hôtes sensibles sont automatiquement ajoutés à la liste no_proxy pour les tâches : le serveur de cache, les adresses de bouclage, les conteneurs du service de tâches et le démon Docker (afin que « docker-in-docker » continue de fonctionner). Lorsque vous utilisez une image dind, le démon lit les mêmes variables de proxy, et le runner affiche un avertissement au démarrage s’il détecte une incompatibilité de...
La fin de cet article est réservée aux abonnés. Soutenez le Club Developpez.com en prenant un abonnement pour que nous puissions continuer à vous proposer des publications.