URL externe

Permettre aux utilisateurs d’ajouter des fichiers depuis des URL externes sur un déploiement Kubernetes, tout en gardant les adresses internes du cluster hors de portée.

Les fichiers « From External URL » (ainsi que les fichiers téléchargés par l’API d’import et par web_fetch de l’assistant IA) sont récupérés par le service linked-url-proxy à l’intérieur de chaque pod Ayakaleaf Pro. Il refuse les adresses qui ne sont pas publiques, de sorte que les utilisateurs ne peuvent pas lire des services internes par son intermédiaire. La fonctionnalité et ses paramètres sont décrits dans URL externe.

Service	linked-url-proxy (127.0.0.1:3066 dans chaque pod) ; web affiche le menu lorsque url figure dans ENABLED_LINKED_FILE_TYPES
Pod → extérieur	les URL fournies par les utilisateurs, sur n’importe quel port, directement ou via OVERLEAF_LINKED_URL_OUTBOUND_PROXY
État	aucun
Tâches périodiques	aucune : un fichier n’est actualisé qu’à la demande d’un utilisateur

​

Configuration

30-config.yaml (additions)

  ENABLED_LINKED_FILE_TYPES: project_file,project_output_file,url
  # Public addresses of your nodes and load balancer, see below
  OVERLEAF_LINKED_URL_BLOCKED_NETWORKS: 203.0.113.0/24 198.51.100.7/32
  # optional
  # OVERLEAF_LINKED_URL_ALLOWED_RESOURCES: ^https?://www\.example\.com/public/
  # OVERLEAF_LINKED_URL_OUTBOUND_PROXY: http://proxy.example.com:3128

kubectl apply -f 30-config.yaml
kubectl -n overleaf rollout restart deployment/overleaf     # or statefulset/overleaf

​

Ce qui est bloqué sur Kubernetes

Le proxy refuse toute adresse qui n’est pas une adresse unicast publique : loopback, lien local (y compris l’adresse de métadonnées cloud 169.254.169.254), les plages privées 10.0.0.0/8, 172.16.0.0/12 et 192.168.0.0/16, la plage NAT de niveau opérateur (carrier-grade NAT) 100.64.0.0/10, ainsi que leurs équivalents IPv6. Les réseaux de pods et de Services situés dans ces plages, ce qui est le cas par défaut pour kubeadm, flannel, Calico et la plupart des clusters managés, sont donc bloqués sans aucun paramètre, tout comme les noms internes au cluster tels que redis ou git-bridge qui y sont résolus.

Les adresses publiques sont autorisées. Si vos nœuds ou votre répartiteur de charge possèdent des adresses publiques, ajoutez-les à OVERLEAF_LINKED_URL_BLOCKED_NETWORKS (séparées par des espaces ou des virgules), afin que les utilisateurs ne puissent pas accéder par leur intermédiaire aux NodePorts ou à une page de statut.

Lorsque OVERLEAF_LINKED_URL_OUTBOUND_PROXY est défini, les noms d’hôte sont résolus par le proxy ; seules les URL contenant une adresse IP sont donc vérifiées : le proxy doit lui-même bloquer vos réseaux internes.

​

Plusieurs réplicas

Rien de plus : chaque pod effectue les récupérations avec son propre linked-url-proxy et les mêmes paramètres.

​

Testé sur Kubernetes

Sur Kubernetes 1.37 avec trois réplicas, le réseau de pods de flannel 10.244.0.0/16 et le réseau de services de kubeadm 10.96.0.0/12, le proxy a refusé les téléchargements depuis la ClusterIP d’un Service, depuis les noms internes au cluster redis, garage et overleaf-1.overleaf-hl.overleaf.svc.cluster.local, et depuis l’adresse d’un nœud, sans aucun OVERLEAF_LINKED_URL_BLOCKED_NETWORKS. Nos tests de bout en bout réussissent également pour le refus du loopback et de l’adresse de métadonnées cloud via l’API d’import, et pour l’assistant IA ne lisant que les pages autorisées par OVERLEAF_LINKED_URL_ALLOWED_RESOURCES.