Périmètre réseau

Le modèle réseau de Scrydon repose sur un principe : le cluster client est la frontière de confiance. Tout ce qui se trouve à l'intérieur est appliqué par mTLS et des vérifications de capacité ; tout ce qui se trouve à l'extérieur est considéré comme non fiable.

Trafic entrant

Le trafic entrant se termine à Traefik. Trois classes de routes :

Il n'existe pas de points de terminaison publics exposant des données client. Le point de terminaison /health ne renvoie que la disponibilité de la plateforme — il ne divulgue pas la version, la configuration ni les données du tenant.

Voir Renforcement de l'ingress pour les règles de suppression d'en-têtes et de terminaison TLS.

Trafic sortant

Le trafic sortant se répartit en quatre catégories :

Rien d'autre ne quitte le cluster. Pas de télémétrie, pas de rapport d'erreurs à Scrydon, pas d'analytics anonymes. Les appels LLM de l'assistant IA (Chat/Cortex) sont acheminés en interne via le fournisseur configuré par l'organisation — ils font partie de la catégorie Appels aux fournisseurs ci-dessus, sans egress séparé hébergé par Scrydon. Si votre politique de sécurité requiert une liste d'autorisation d'egress strictement limitée, le point de terminaison de licence, votre serveur de messagerie et ce que les intégrations installées déclarent constituent la liste complète.

Limiter le trafic des modèles à un seul fournisseur

Une NetworkPolicy Kubernetes agit sur les adresses IP et les ports, pas sur les noms d'hôte : elle ne peut pas distinguer api.openai.com d'un autre point de terminaison HTTPS public. Lorsque les politiques réseau et l'exécution gérée des extensions sont activées, le chart autorise l'hôte d'extensions à joindre les adresses publiques sur le port 443 et laisse le choix de la destination au broker fournisseur. Le broker n'admet que les hôtes déclarés par chaque extension installée.

Pour limiter le trafic des modèles (LLM, parole, embeddings) à un seul fournisseur, installez et activez donc uniquement l'extension de ce fournisseur. Pour ajouter un contrôle au niveau réseau, faites passer le trafic sortant par un proxy d'egress ou un pare-feu qui filtre par nom d'hôte, et restreignez networkPolicies.providerEgress.ipBlocks à la plage d'adresses de ce proxy.

L'e-mail n'est couvert par aucune règle du chart. Lorsque networkPolicies.enabled est activé, ajoutez une NetworkPolicy qui autorise les pods auth, platform et api-agentic à joindre l'adresse et le port de votre serveur de messagerie.

Mode air-gap

Pour les déploiements vraiment isolés, vous pouvez :

• Fonctionner hors ligne uniquement : ignorer le heartbeat de licence. Les opérations se poursuivent sous votre licence contractuelle ; le phone-home est désactivé.
• Limiter les intégrations de fournisseurs aux seuls fournisseurs auto-hébergés. Aucun appel de fournisseur sortant ne se produit. Si aucun fournisseur LLM accessible n'est configuré, l'assistant IA (Chat/Cortex) n'a pas de modèle à appeler et sera indisponible ; le reste de la plateforme n'est pas affecté.

Voir Déploiement → Air-gap pour la procédure complète.

Liste d'autorisation d'egress

Pour les déploiements non air-gappés, la politique d'egress recommandée est :

ALLOW  license.scrydon.com:443                # required
ALLOW  <endpoints declared by installed integrations>
DENY   *                                       # everything else

Les appels LLM de l'assistant IA sont dirigés vers le fournisseur configuré par l'organisation (par ex. api.openai.com) et sont couverts par la ligne « intégrations installées » ci-dessus.

La plateforme n'effectue jamais d'appels sortants vers des destinations qui ne figurent pas dans cette liste. La liste est auditable depuis Paramètres → Plateforme → Extensions (chaque intégration installée liste ses points de terminaison d'egress déclarés).

Politique d'egress de l'organisation

Paramètres → Gouvernance → Trafic sortant contrôle les destinations atteintes par les notebooks isolés et par les intégrations de workflow revues qui utilisent la récupération contrôlée de Scrydon. En mode liste d'autorisation, une destination doit correspondre à un domaine configuré (ou à une valeur par défaut Scrydon activée) avant qu'une connexion soit ouverte. Pour ces requêtes, une politique absente, invalide ou temporairement indisponible refuse la requête ; les interrogations déclaratives de sources de données traitent une politique absente différemment (voir ci-dessous).

Une destination correspond à une entrée de la liste d'autorisation ou de refus quels que soient la casse, un point final ou des crochets IPv6, du côté de l'entrée comme de la destination : Feed.Example. et feed.example désignent donc le même domaine.

Une entrée peut indiquer un port, par exemple feed.example:8443 :

• Dans la liste d'autorisation, une entrée avec un port n'autorise le domaine que sur ce port. Une entrée sans port autorise tous les ports. Une URL sans port utilise le port de son schéma : feed.example:443 autorise donc https://feed.example, mais rien sur https://feed.example:8443.
• Dans la liste de refus, le port est ignoré : feed.example:8443 bloque feed.example sur tous les ports.
• Certaines connexions ne passent jamais que par le port 443 : les appels d'une extension via le broker d'egress des extensions, et le trafic sortant d'une sandbox microVM. Une entrée de la liste d'autorisation limitée à un autre port n'autorise rien pour elles.
• Une entrée qui ne peut correspondre à rien — un port égal à 0 ou supérieur à 65535, ou plus d'un port — est refusée à l'enregistrement de la politique.

Les redirections ne contournent pas cette décision. Scrydon évalue le nouveau nom d'hôte et répète la validation DNS et d'adresse avant chaque connexion redirigée. Les refus de politique sont enregistrés comme événements d'audit egress.blocked, sans en-têtes de requête, corps, identifiants ni URL complètes.

La même politique régit les interrogations déclaratives de sources de données, décidées avant toute résolution d'identifiants et toute requête DNS. Les interrogations suivent la liste d'autorisation et la liste de refus, mais les domaines de paquets par défaut de Scrydon ne s'y appliquent pas, et les Domaines déclarés par l'intégration ne peuvent pas admettre un hôte d'interrogation. Les interrogations ne suivent aucune redirection : une interrogation qui en reçoit une échoue au lieu de réévaluer le nouvel hôte. Sans aucune politique, les interrogations ne sont limitées que par les règles HTTPS public (les URL locales, d'hôte privé et HTTP simple sont toujours refusées). Une politique illisible refuse l'interrogation. Une interrogation refusée échoue avec le message « Outbound request blocked by organization egress policy » et la raison est enregistrée sur la source. Une récupération à la demande depuis une source qui désigne un hôte refusé reçoit CAPABILITY_NOT_CONFIGURED (409), la même réponse qu'un endpoint de connexion non approuvé, car un administrateur corrige les deux en ajoutant l'hôte à la liste d'autorisation.

Domaines déclarés par l'intégration

Une intégration déclare dans son manifeste les destinations que ses outils contactent. Lorsque l'option Domaines déclarés par l'intégration est activée (valeur par défaut), ces destinations sont autorisées sans devoir également figurer dans votre liste d'autorisation : installer une intégration n'exige donc pas de découvrir au préalable les hôtes dont elle a besoin.

Les domaines déclarés sont affichés sur l'écran de configuration de l'intégration, au-dessus des champs d'identifiants, afin que vous voyiez ce que vous autorisez avant de connecter un compte.

Les limites qui s'appliquent toujours :

• Un domaine présent sur votre liste de blocage reste bloqué. Un manifeste ne peut pas l'annuler.
• Seuls les domaines déclarés sont autorisés ; tout le reste est refusé comme auparavant.
• Les adresses privées, loopback, link-local et de métadonnées restent refusées.

Désactivez cette option si votre organisation exige que chaque destination soit explicitement approuvée. Vous listez alors vous-même les domaines de chaque intégration, et une intégration dont les domaines sont absents ne pourra pas les joindre.

Protection SSRF par outil

Les appels web-fetch et les appels sortants pilotés par des outils sont soumis à une vérification SSRF à l'exécution :

• La politique de domaines de l'organisation est appliquée avant la connexion.
• Les adresses RFC 1918 (privées) sont refusées.
• Le link-local (169.254.0.0/16) est refusé.
• L'IPv6 unique-local (fc00::/7) est refusé.
• Le loopback est refusé.
• Les noms d'hôtes internes au cluster (*.svc.cluster.local) sont refusés.

Pour ces outils et extensions, l'option réseaux privés n'atteint que les réseaux privés que votre opérateur Scrydon a ouverts à votre organisation (global.egress.privateNetworks), sur les ports de ces réseaux ; sans un tel réseau, elle n'ouvre rien. Le loopback n'est jamais joignable depuis eux : c'est le conteneur de la plateforme elle-même. Toute autre adresse qui n'est pas routable publiquement reste refusée, quoi que vous activiez : le link-local et les métadonnées cloud (169.254.169.254, les points de terminaison IPv6 AWS dans fd00:ec2::/64, l'adresse de plateforme Azure 168.63.129.16), l'espace d'adressage partagé (100.64.0.0/10), les plages de benchmark, de documentation et réservées, ainsi que le multicast.

Cela s'applique à l'outil intégré fetch-webpage, au bloc API, aux intégrations de workflow revues et aux outils de fournisseur dont le runtime gouverné autorise une récupération sortante.

L'auteur d'une intégration peut élargir l'ensemble des domaines accessibles à sa propre intégration, mais uniquement par le mécanisme des domaines déclarés ci-dessus, uniquement pour des destinations HTTPS publiques et uniquement tant que Domaines déclarés par l'intégration est activé. Aucune des protections au niveau des adresses décrites dans cette section ne peut être élargie par une intégration, et un domaine figurant sur la liste de blocage reste bloqué.

Récepteurs de logs et endpoints de fournisseurs OAuth

Deux adresses qu'un administrateur d'organisation configure sont appelées depuis les serveurs de Scrydon : l'URL d'un récepteur de logs et les endpoints du fournisseur OAuth d'une extension. Les deux sont épinglées par DNS, ne suivent jamais de redirection et n'atteignent que des adresses https:// publiques — sauf une adresse d'un réseau privé que l'opérateur a ouvert à cette organisation avec global.egress.privateNetworks, sur les ports de ce réseau et vérifiée avec les ancres de confiance de ce réseau lorsqu'il en désigne. Aucun paramètre d'organisation n'ouvre un réseau. Le loopback, le link-local, les métadonnées cloud (169.254.169.254, fd00:ec2::/64, 168.63.129.16), les plages propres au cluster (runtimePlane.blockedCidrs) et les autres plages réservées sont refusés quoi que l'opérateur ouvre. La même règle s'applique à l'enregistrement de l'adresse et à chaque appel.

Voir aussi

• Renforcement de l'ingress — le côté entrant de la frontière.
• SPIFFE / mTLS — authentification du maillage interne.
• Déploiement → Air-gap — mode déconnecté complet.