Politique d’authentification

La page de politique d’authentification regroupe les réglages, à l’échelle de l’organisation, qui déterminent comment vos membres s’authentifient auprès de Git et de l’API REST. Chaque option est indépendante ; les valeurs par défaut sont les plus permissives, afin que les membres existants ne se retrouvent pas exclus par surprise lors de votre première visite sur la page. Resserrez-les une à une à mesure que votre posture de sécurité mûrit.

Elle se trouve sous Sécurité › Accès › Politique d’authentification (<your-org>/_admin/security/access/authentication ; l’ancienne adresse <your-org>/_admin/auth-policy y redirige). La page commence aussi par les informations sur l’authentification à deux facteurs qui figuraient sur l’ancienne page des politiques de périphérie, aujourd’hui supprimée : l’authentification à deux facteurs est toujours exigée, pour chaque membre.

Regroupement du 2026-05-26 : l’onglet autonome Autorité de certification SSH a été intégré à cette page, sous forme de sous-section de « Autoriser le protocole SSH » (elle n’a de sens que lorsque SSH est activé, elle apparaît donc en même temps que l’option). Les liens directs vers /admin/ssh-ca/ redirigent désormais ici. Les mêmes actions d’écriture sont conservées (coller des clés d’autorité, exiger un certificat) sans quitter la vue de la politique d’authentification.

Politiques

Contraintes sur les clés SSH

Lorsque cette option est activée, fremforge refuse l’ajout de nouvelles clés SSH qui ne sont pas matérielles. C’est l’algorithme de la clé OpenSSH qui l’indique : seuls sk-ssh-ed25519@openssh.com et sk-ecdsa-sha2-nistp256@openssh.com sont admis ; les clés ssh-ed25519 et ssh-rsa ordinaires sont refusées dans le formulaire Ajouter une clé.

Une clé matérielle est une clé dont la partie privée réside dans une puce de sécurité (Secure Enclave de macOS, TPM, YubiKey, authentificateur FIDO). Elle ne peut pas être extraite de l’ordinateur portable. Touch ID, un code PIN ou une pression sur le matériel est exigé à chaque push. C’est le modèle pratique le plus proche d’une « MFA sur git push » sans mettre en place une autorité de certification SSH complète.

Les clés existantes NE sont PAS rejetées rétroactivement : seuls les nouveaux ajouts de clés sont contrôlés. Activer cette option sur une organisation saine est sans risque ; les membres peuvent continuer à pousser avec leurs clés existantes, mais l’ajout d’un nouvel ordinateur impose une configuration matérielle. Combinez-la avec l’autorité de certification SSH ci-dessous pour l’état final le plus solide (plus aucune clé ordinaire).

Actions du journal d’audit : tenant.auth_policy.hardware_keys.enabled / tenant.auth_policy.hardware_keys.disabled.

Autorité de certification SSH

(Visible uniquement lorsque le protocole SSH est activé ci-dessus : conditionner une primitive SSH à l’activation de SSH est la manière naturelle de l’afficher.)

L’authentification par certificat SSH est la méthode de connexion SSH la plus solide en pratique. Un certificat de courte durée, émis par votre propre autorité et lié au flux MFA de votre IdP, remplace la clé publique de longue durée présente sur chaque ordinateur de développeur. fremforge prend en charge ce modèle nativement : c’est la même primitive que GitHub Enterprise Cloud appelle « SSH certificate authority ».

Prérequis : depuis le 2026-05-22, fremforge crée les nouvelles organisations avec SSH désactivé (l’option ci-dessus). Si votre organisation conserve ce réglage par défaut, vous n’avez pas du tout besoin d’une autorité SSH : le chemin HTTPS + Git Credential Manager vous apporte la MFA à chaque push via votre IdP, sans aucune autorité à configurer. Si votre organisation a explicitement réactivé SSH (pour une raison précise, comme un outillage de CI ancien ou une forte préférence des développeurs), cette section constitue la couche de durcissement suivante pour ce chemin SSH choisi.

Quand utiliser une autorité SSH

Utilisez l’authentification par certificat SSH si votre organisation a réactivé SSH ET si l’une des situations suivantes s’applique :

• Vous voulez que chaque push Git soit soumis à un nouveau défi MFA de l’IdP (pas de « portable perdu → l’attaquant pousse pendant 90 jours jusqu’à ce que l’on remarque la clé SSH »)
• Vous migrez depuis GitHub Enterprise Cloud et vos développeurs s’attendent au flux d’autorité SSH de GHEC
• Votre RSSI a demandé spécifiquement une « MFA sur git push » ET tient au transport SSH ; notez toutefois que la réponse la plus propre est le chemin HTTPS + GCM par défaut
• Vous disposez déjà d’une autorité qui émet des certificats OpenSSH (Smallstep, moteur de secrets SSH de HashiCorp Vault, émetteur sur mesure lié à OIDC) et vous voulez que fremforge fasse confiance aux certificats qu’elle signe

Si vous n’êtes dans aucune de ces situations, les clés SSH matérielles (Touch ID, Secure Enclave, YubiKey : option ci-dessus) sont une voie plus simple pour une sécurité comparable. Consultez Connexion sécurisée pour la grille de choix.

Mise en place

Étape 1 : préparez votre autorité. Options classées par facilité :

1. Smallstep step ca : open source, compatible avec un hébergement dans l’UE, prise en charge des provisioners OIDC prête à l’emploi. Liez-la à votre IdP et step ssh login devient un flux MFA en une ligne.
2. Moteur de secrets SSH de HashiCorp Vault : si vous utilisez déjà Vault pour vos secrets, le moteur de secrets SSH ajoute l’émission de certificats OpenSSH avec un contrôle d’accès fondé sur des politiques.
3. ssh-keygen -s manuel : uniquement pour une preuve de concept.

Générez la paire de clés de l’autorité si vous n’en avez pas :

ssh-keygen -t ed25519 -f acme-ssh-ca -C "acme-ssh-ca@example.com"

Cela produit acme-ssh-ca (privée : gardez-la secrète et distribuez-la à votre infrastructure d’émission) et acme-ssh-ca.pub (publique : à coller ensuite dans fremforge).

Étape 2 : enregistrez l’autorité. Collez acme-ssh-ca.pub dans la zone de texte Clés publiques de l’autorité (une par ligne) de cette page, une autorité par ligne. Jusqu’à 8 autorités sont acceptées (utile pour la rotation : ajouter la nouvelle, distribuer la nouvelle clé privée, retirer l’ancienne). Cliquez sur Save CA keys. Une tâche automatique de la plateforme propage la modification dans la couche SSH de Forgejo. Entrée du journal d’audit : tenant.ssh_ca.keys.updated.

Étape 3 : faites enregistrer leurs principals par les membres. Chaque certificat SSH porte un ou plusieurs principals, de courtes chaînes qui désignent son titulaire. Un certificat signé par une autorité de confiance connecte un membre lorsque l’un de ses principals correspond à un principal que ce membre a enregistré sur sa propre page de paramètres des clés SSH (la section Manage SSH certificate principals). fremforge y accepte n’importe quelle chaîne ; émettez donc des certificats dont le principal désigne l’utilisateur sans ambiguïté, par exemple son nom d’utilisateur fremforge.

Supprimé le 2026-10-14 : le réglage « Principal policy » (Username / Email / Anything). Il était enregistré mais jamais appliqué : Forgejo vérifie la forme d’un principal par rapport à un réglage unique pour toute la plateforme, et non par organisation, et un membre peut appartenir à plusieurs organisations. PUT /orgs/{org}/ssh-ca dans l’API accepte toujours principal_policy, afin que les scripts et configurations Terraform existants continuent de fonctionner, mais l’ignore, et GET ne le renvoie plus.

Étape 4 : exigez éventuellement l’authentification par certificat. Dès qu’au moins une autorité est configurée, activez Exiger un certificat signé par l’autorité pour refuser l’authentification SSH par clé publique ordinaire. C’est l’état final le plus propre : les clés ~/.ssh/id_* de longue durée cessent complètement de fonctionner, et chaque push Git doit passer par votre autorité (et donc par le flux MFA de votre IdP). Activer cette option sans autorité opérationnelle exclurait tout le monde ; le formulaire refuse la modification tant qu’aucune autorité n’est configurée. Entrées du journal d’audit : tenant.ssh_ca.require_cert.enabled / tenant.ssh_ca.require_cert.disabled.

Étape 5 : émettez le premier certificat de chaque utilisateur. Avec Smallstep :

step ssh login user@example.com --provisioner=your-oidc-provisioner
# Browser opens → IdP login + MFA → cert issued + cached ~1 hour.

git clone git@frem.sh:<org>/<repo>.git
# OpenSSH presents the cert; fremforge checks the trusted CA and the user's registered principals.

Pour Vault, consultez la documentation du moteur de secrets SSH de HashiCorp Vault. Pour ssh-keygen -s manuel (preuve de concept uniquement) : ssh-keygen -s acme-ssh-ca -I "alice-cert-2026-05-22" -n alice -V +1h alice-id_ed25519.pub → distribuez alice-id_ed25519-cert.pub à l’utilisateur avec sa clé privée ; OpenSSH le prend en compte automatiquement.

Rotation de l’autorité

Pour remplacer une autorité existante sans interruption : générez une nouvelle paire de clés d’autorité → ajoutez la nouvelle clé publique dans la zone de texte à côté de l’existante (jusqu’à 8 acceptées) → configurez votre infrastructure d’autorité pour émettre avec la nouvelle clé → attendez l’expiration des certificats émis par l’ancienne autorité (généralement 1 heure) → retirez l’ancienne autorité de la zone de texte.

Désactiver l’authentification par autorité

Retirez toutes les clés d’autorité de la zone de texte et enregistrez. L’entrée du journal d’audit tenant.ssh_ca.keys.updated consigne next_key_count: 0. Si Exiger un certificat signé par l’autorité était activé, l’option se désactive automatiquement (elle exige au moins une autorité). Les membres reviennent à l’authentification SSH par clé publique ordinaire.

Durée de vie des PAT

Durée de vie maximale autorisée pour les jetons d’accès personnels nouvellement créés. Les jetons existants NE sont PAS raccourcis rétroactivement : le plafond ne s’applique qu’à l’émission.

Recommandation : 90 jours pour commencer. Descendez à 30 si vous avez un programme actif d’analyse des identifiants qui détecte les jetons divulgués à l’intérieur des fenêtres de rotation.

Action du journal d’audit : tenant.auth_policy.max_pat_lifetime.updated.

Autoriser les clés de déploiement de dépôt

Les clés de déploiement de dépôt sont des identifiants SSH de longue durée limités à un seul dépôt : un chemin d’identifiants machine de longue durée parallèle aux PAT des utilisateurs. Elles sont utiles pour les clients de CI externes ou de miroir qui ne peuvent pas se fédérer via OIDC. Par défaut : désactivé, conformément à la posture sécurisée par défaut de ssh_disabled=true et allow_user_pats=false. Les identifiants machine de longue durée restent désactivés tant que vous ne les activez pas.

Lorsque la politique est désactivée (par défaut), trois couches interviennent :

1. Bannière dans l’interface Forgejo : lorsqu’un administrateur de dépôt ouvre Dépôt → Paramètres → Clés de déploiement, la page passe par api-intercept, qui insère au-dessus de l’en-tête Forgejo standard une bannière au style Fomantic expliquant que les clés de déploiement sont désactivées par la politique de l’organisation. La navigation et la barre latérale de Forgejo sont conservées (l’utilisateur n’est jamais renvoyé hors du dépôt). L’envoi du formulaire Add deploy key est bloqué au niveau de l’api (le POST est redirigé en 303 vers le GET pour que l’utilisateur voie l’explication de la bannière).
2. Blocage de l’API REST : POST /api/v1/repos/<owner>/<repo>/keys renvoie 403 avec error: use_fremforge_admin et un redirect_to pointant ici. DELETE et GET sont toujours transmis (les administrateurs peuvent nettoyer et auditer les clés existantes quelle que soit la politique).
3. Audit sans blocage : chaque clé de déploiement active existante émet un événement d’audit tenant.auth_policy.deploy_key_violation lors du prochain passage du mécanisme d’application. Les clés existantes NE sont PAS révoquées automatiquement ; l’administrateur décide lesquelles supprimer via les paramètres du dépôt dans Forgejo (le chemin de suppression reste ouvert).

Quand l’activer : uniquement dans le cas marginal de clients de CI externes ou de miroir qui ne peuvent réellement pas se fédérer via OIDC. L’alternative prévue pour l’identité machine de la CI est la fédération OIDC des runners : des jetons de courte durée émis par l’émetteur OIDC de fremforge, fédérés avec la politique de confiance de votre cloud, sans secret de longue durée par dépôt. La plupart des intégrations de CI n’ont pas besoin de clés de déploiement.

Actions du journal d’audit : tenant.auth_policy.allow_repo_deploy_keys.enabled / .disabled (l’option) ; tenant.auth_policy.deploy_key_violation (par clé active tant que la politique est désactivée).

Exiger des commits signés

Lorsque cette option est activée, la branche par défaut de chaque dépôt de cette organisation porte une règle de protection de branche exigeant des commits signés. Les membres doivent configurer la signature des commits GPG ou SSH sur leurs machines ; les commits non signés vers la branche par défaut sont rejetés par Forgejo au moment du push.

Le réglage prend effet dès que vous l’enregistrez. fremforge commence immédiatement à l’appliquer aux dépôts existants de l’organisation, en arrière-plan, et la ligne sous l’option dans Sécurité › Politiques › Règles des dépôts indique la progression et le moment où l’application s’est terminée. Une vérification horaire maintient ensuite chaque branche par défaut en conformité, y compris pour les dépôts créés plus tard. Enregistrer à nouveau la même valeur lance une nouvelle vérification.

Le désactiver retire l’exigence, là aussi immédiatement, sur les règles que fremforge avait activées pour ce réglage. Une règle où un administrateur de dépôt a lui-même exigé des commits signés est laissée telle quelle, tout comme le reste de chaque règle : les approbations et les vérifications de statut ne sont pas modifiées, et aucune règle n’est supprimée. Si un administrateur a recoché à la main « require signed commits » sur une règle que fremforge avait déjà définie, fremforge ne peut pas distinguer les deux ; cette règle est désactivée avec les autres, et l’administrateur peut la réactiver.

Il s’agit d’un seul réglage, partagé avec la valeur par défaut des commits signés pour les nouveaux dépôts : l’enregistrer définit les deux, de sorte qu’un nouveau dépôt démarre avec la même exigence (voir Règles des dépôts).

L’option constitue le plancher au niveau de l’organisation : les dérogations de protection de branche par dépôt s’appliquent si elles sont définies.

Via l’API, PATCH /orgs/{org}/auth-policy avec require_signed_commits fait la même chose et répond signed_commits_applying: true.

Configuration de la signature par les membres :

# Generate a signing key (or use the existing SSH key)
ssh-keygen -t ed25519 -f ~/.ssh/git-signing-key -C "alice signing key"

# Configure git to sign with it
git config --global user.signingkey ~/.ssh/git-signing-key.pub
git config --global gpg.format ssh
git config --global commit.gpgsign true

# Upload the public key to frem.sh/user/settings/keys with usage:
# "Signing key" alongside the same key as an "Authentication key".

Actions du journal d’audit : tenant.auth_policy.signed_commits.enabled / tenant.auth_policy.signed_commits.disabled (le réglage) ; tenant.auth_policy.signed_commits.applied / tenant.auth_policy.signed_commits.reverted (par règle de dépôt modifiée par fremforge).

Autoriser le protocole SSH

Cette option détermine si Git sur SSH est autorisé ou non. Désactivée (valeur par défaut pour les organisations créées après le 2026-05-22), elle fait refuser toute opération Git sur SSH dans les dépôts de l’organisation : push, clone et fetch, ainsi que Git LFS sur SSH. Le clone et le fetch sont refusés avant le démarrage de Git ; un push est refusé par le hook pre-receive. Un clone ou un fetch refusé affiche un message qui nomme ce réglage et indique l’URL de clonage HTTPS à utiliser à la place (voir Ce que voit un développeur refusé). Les membres utilisent HTTPS + Git Credential Manager, qui fait passer la MFA par l’IdP de votre organisation à chaque renouvellement de jeton. Activez l’option pour autoriser SSH (l’ancienne valeur par défaut, antérieure au 2026-05-22).

Pourquoi cette option existe : la liste d’adresses IP autorisées ne couvre pas Git sur SSH. SSH atteint fremforge via un répartiteur de charge qui remplace l’adresse source par celle de l’un de nos propres nœuds de cluster ; l’adresse depuis laquelle votre développeur se connecte ne nous est donc pas visible, et fremforge refuse de juger une connexion sur une adresse qu’il sait erronée. Les organisations qui veulent que chaque opération Git soit filtrée par IP désactivent SSH ici et utilisent HTTPS, que la liste couvre.

Ce que voit un développeur refusé

Un git clone ou git fetch sur SSH vers un dépôt d’une organisation où SSH est désactivé échoue avec :

$ git clone git@frem.sh:acme/web.git
Cloning into 'web'...
Forgejo: SSH is turned off for the organisation acme (Authentication policy: "Allow SSH protocol" is off), so SSH push, clone and fetch are refused. Use HTTPS instead: git clone https://frem.sh/acme/web.git

fatal: Could not read from remote repository.

Les clés SSH du développeur et son appartenance à l’organisation ne sont pas modifiées : réactiver l’option rétablit immédiatement l’accès SSH.

Chaque refus est consigné dans le journal d’audit sous git.ssh.tenant_disabled_blocked, pour les push comme pour les clones et les fetch.

Actions du journal d’audit : tenant.auth_policy.ssh_disabled.enabled / tenant.auth_policy.ssh_disabled.disabled.

Liste d’adresses IP autorisées

La liste d’adresses IP autorisées dispose désormais de sa propre page : Liste d’adresses IP autorisées. Une seule liste couvre maintenant toutes les surfaces HTTPS ; il n’y a donc plus de portée à choisir. Son aperçu en mode audit seul, son option pour les runners et son accès de secours y sont décrits.

Conservation du journal d’audit

Ce réglage contrôle la fenêtre de contenu interrogeable du journal d’audit. Le niveau de chaîne cryptographique (WORM sur 3 ans) n’est pas affecté ; seules les colonnes lisibles actor + fields_json sont concernées.

Le réglage s’applique lors du passage quotidien de caviardage (~02:30 UTC). Allonger la fenêtre garde les nouvelles lignes interrogeables plus longtemps ; la raccourcir caviarde de façon irréversible, au passage suivant, les lignes plus anciennes que la nouvelle fenêtre. Voir Journal d’audit → Conservation pour le fonctionnement complet.

Action du journal d’audit : tenant.auth_policy.audit_retention.updated.

Comment ces réglages interagissent

Qui applique quoi

Ces politiques sont appliquées au niveau de la plateforme, à chaque requête. L’interface d’administration fait foi pour ce que l’organisation a choisi.

Limites

• Le plafond de durée de vie des PAT s’applique à l’émission. Les jetons existants NE sont PAS raccourcis rétroactivement. Si vous resserrez le plafond, attendez-vous à ce que certains jetons de bots ou de CI survivent à la nouvelle politique ; ils continueront de fonctionner jusqu’à leur expiration d’origine.
• L’obligation de clés matérielles ne s’applique qu’aux NOUVEAUX ajouts de clés. Les membres conservent leurs clés existantes.
• Les commits signés sont appliqués aux dépôts existants lors de l’enregistrement du réglage, en arrière-plan ; une grande organisation prend une minute ou deux, et la progression s’affiche sous l’option. Les nouveaux dépôts créés après l’activation reçoivent la règle dès leur création.