Liste d’IP autorisées

La liste d’IP autorisées limite votre organisation aux réseaux que vous indiquez. Lorsque la liste est définie, une requête provenant d’une adresse extérieure est refusée, même si l’identifiant est valide et que l’utilisateur s’est connecté par SSO.

Elle se trouve sous Sécurité › Accès › Liste d’IP autorisées (<your-org>/_admin/security/access/ip-allowlist). Seuls les propriétaires de l’organisation peuvent la modifier.

Où la liste s’applique

Il n’existe qu’une liste, et elle s’applique à chacune des surfaces ci-dessous :

Les dépôts publics restent lisibles par tous, puisque leur contenu est public de toute façon. Un membre connecté qui consulte un dépôt public est tout de même contrôlé lorsqu’il pousse, modifie des paramètres ou ouvre les pages de l’organisation. Les visiteurs anonymes ne voient jamais de refus : un dépôt privé leur apparaît exactement comme avant.

La page de sécurité affiche Où la liste s’applique en ce moment, avec une ligne par surface : Appliquée, Journalisée seulement (avec la raison) ou Non couvert. L’API renvoie les mêmes informations dans surfaces. Lorsque cette page de documentation et ce panneau divergent, c’est le panneau qui a raison.

Déploiement progressif. Une liste unique pour toutes les surfaces est activée progressivement. Tant que votre organisation n’a pas été basculée, le panneau peut afficher une surface comme Journalisée seulement — déploiement en cours. Les requêtes hors de la liste sont alors consignées dans le journal d’audit, mais pas refusées. L’administration web et Git sur HTTPS sont appliqués partout (pour une ancienne liste de portée web, seulement l’administration web ; voir plus bas).

Définir la liste

• Utilisez la notation CIDR : 203.0.113.0/24, 2001:db8::/48. Une adresse seule s’écrit /32, ou /128 en IPv6.
• Mettez une plage par ligne, ou séparez-les par des virgules. La limite est de 100 plages.
• /0 est refusé. Pour autoriser toutes les adresses, laissez la liste vide.
• Incluez les plages de vos bureaux et de votre VPN, ainsi que les adresses de sortie de tout système de CI qui ne tourne pas sur fremforge.
• La page affiche Votre adresse en ce moment, c’est-à-dire l’adresse que fremforge voit pour vous.

Vous ne pouvez pas vous bloquer vous-même en enregistrant. Si une liste appliquée ne contient pas votre propre adresse, l’enregistrement est refusé : ajoutez votre adresse, ou cochez d’abord Aperçu en audit seul.

Une modification prend effet sur toutes les surfaces en une minute environ.

Aperçu en audit seul

Avec Aperçu en audit seul activé, chaque surface consigne les requêtes qu’elle refuserait, mais les laisse passer. Une bonne façon d’introduire une liste :

1. Saisissez les plages et cochez Aperçu en audit seul. Enregistrez.
2. Utilisez l’organisation normalement pendant un jour ou deux, CI et intégrations comprises.
3. Examinez les événements ip_allowlist.would_block dans le journal d’audit. Chacun indique la surface, l’adresse, un exemple de chemin et le nombre de requêtes qu’il représente.
4. Ajoutez les plages légitimes que vous aviez oubliées.
5. Décochez Aperçu en audit seul. La liste est désormais appliquée.

Runners hébergés par fremforge

Les jobs de CI sur les runners de fremforge atteignent votre organisation depuis le réseau de fremforge, pas depuis le vôtre. Le jeton émis pour un job fonctionne toujours. Autoriser les runners hébergés par fremforge (activé par défaut) détermine si les autres identifiants utilisés depuis un runner, comme un PAT ou un jeton OAuth conservé dans un secret, fonctionnent aussi. Désactivez cette option si vous voulez qu’un PAT volé soit inutilisable même depuis un job de CI.

Les runners auto-hébergés et la CI externe sont contrôlés selon leur adresse de sortie, comme n’importe quel autre client. Ajoutez ces adresses à la liste.

Si un propriétaire est bloqué

Votre adresse peut changer : nouveau bureau, panne du VPN, déplacement. L’accès d’urgence (break-glass) bascule toutes les surfaces en simple journalisation pendant 24 heures. Rien n’est contourné définitivement, et chaque étape est consignée dans le journal d’audit.

• En libre-service pour le propriétaire. Ouvrez https://frem.sh/_app/ip-allowlist/break-glass?org=<your-org> depuis n’importe quel réseau, connecté en tant que propriétaire. Nous envoyons un lien signé à l’adresse e-mail de votre propre compte. Le lien est valable 30 minutes. Ouvrez-le et confirmez. Les pages de refus et les messages d’erreur Git de votre organisation affichent cette adresse.
• Le support fremverk peut activer le même accès d’urgence pour votre organisation sur demande.

L’accès d’urgence se termine de lui-même au bout de 24 heures et n’est jamais prolongé tant qu’il est actif. Corrigez la liste, puis mettez-y fin plus tôt avec Mettre fin à l’accès d’urgence sur la page de sécurité.

Actions du journal d’audit : ip_allowlist.break_glass.activated, ip_allowlist.break_glass.ended.

Listes créées avant qu’une liste unique couvre toutes les surfaces

Les anciennes listes avaient une portée : web (administration web seulement) ou web+git (plus Git sur HTTPS). Ces listes continuent de s’appliquer là où elles s’appliquaient. Sur les autres surfaces, elles consignent les refus qu’elles auraient prononcés pendant 30 jours après que nous avons prévenu les propriétaires de l’organisation, puis s’y appliquent aussi. La page de sécurité indique la date.

Pour ne pas attendre, utilisez Appliquer sur toutes les surfaces maintenant (action du journal d’audit security.ip_allowlist.enforce_all). Vous ne pouvez pas ramener une liste à une ancienne portée, et toute nouvelle liste couvre toutes les surfaces.

Git sur SSH n’est pas couvert

La liste d’IP autorisées ne filtre pas Git sur SSH. SSH atteint fremforge via un répartiteur de charge qui remplace l’adresse du client par celle de l’un de nos nœuds de cluster : l’adresse depuis laquelle votre développeur se connecte ne nous est donc pas visible. Nous ne jugeons pas une connexion d’après une adresse que nous savons fausse. Une liste qui bloquerait en silence tous les utilisateurs SSH, ou qui les laisserait tous passer en silence tout en prétendant filtrer, serait pire que de le dire clairement.

Si votre organisation a besoin que chaque opération Git soit filtrée par IP :

1. Désactivez Autoriser le protocole SSH sur la page Politique d’authentification. C’est le réglage par défaut pour les organisations créées après le 2026-05-22.
2. Demandez aux membres d’utiliser HTTPS avec Git Credential Manager (Connexion sécurisée). Git sur HTTPS est couvert par la liste.

Désactiver SSH refuse toute opération Git par SSH sur les dépôts de l’organisation : push, clone et fetch, ainsi que Git LFS sur SSH. Il s’agit d’un refus de SSH dans son ensemble, pas d’un contrôle d’IP : la page de sécurité continue donc d’afficher Git sur SSH comme Non couvert par la liste, et l’API renvoie ssh_covered: false.

Ce que voit une requête refusée

Chaque refus est consigné sous ip_allowlist.blocked, et chaque requête seulement journalisée sous ip_allowlist.would_block. Les répétitions depuis la même adresse sur la même surface sont regroupées en un seul événement avec un count, pour qu’une boucle de CI mal configurée n’inonde pas le journal.

API

La liste est aussi disponible via l’API fremforge, avec les portées policy:read et policy:write.

# Read: the list, the runner toggle, per-surface modes, break-glass state
curl -H "Authorization: Bearer $TOKEN" \
  https://frem.sh/_app/api/v1/orgs/<your-org>/security

# Replace the list
curl -X PUT -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
  -d '{"cidrs":["203.0.113.0/24","2001:db8::/48"],"audit_only":true,"allow_platform_runners":true}' \
  https://frem.sh/_app/api/v1/orgs/<your-org>/security/ip-policy

L’objet ip_allowlist contient cidrs, scope, audit_only, allow_platform_runners, surfaces (par surface : mode vaut enforce ou audit, plus une reason), new_surfaces_enforce_at, break_glass_until et ssh_covered.

Dans l’API, la protection contre le blocage s’applique à l’adresse de l’appelant. Erreurs : invalid-cidr pour une plage mal formée, invalid-allowlist pour plus de 100 plages, une plage /0 ou une liste qui bloquerait l’appelant, et invalid-scope pour une ancienne portée.

Limites

• Si le service Git de fremforge ne peut pas lire les politiques des organisations pendant plus de 24 heures, il cesse d’appliquer la liste plutôt que de refuser toutes les organisations. L’API fremforge et l’administration web ne sont pas concernées. Une telle panne est un incident de plateforme que nous traitons ; elle n’est pas attendue en fonctionnement normal.
• Les adresses sont jugées telles que la périphérie de fremforge les voit. Un proxy ou un NAT devant vos utilisateurs détermine de quelle adresse il s’agit : listez donc la plage de sortie du proxy.
• 100 plages au maximum.