Secure Links

Les Secure Links relient des ressources prises en charge et gérées par Opfield sans transformer la destination en point de terminaison public général.

Le terme désigne une connectivité privée étroitement délimitée, dont la propriété durable revient à Opfield. Il n’implique pas que chaque chemin privé utilise le même composant d’exécution. Les liens vers les upstreams d’ingress et les liaisons de bases de données managées ont des propriétaires, des identifiants, des enregistrements de cycle de vie et des signaux de diagnostic différents.

Prérequis et frontière de confiance

Les deux extrémités doivent être des ressources prises en charge, gérées par Opfield et dotées d’identités stables, et leurs nœuds propriétaires doivent être en ligne avec des capacités compatibles. Relay doit être sain et joignable depuis les nœuds participants. L’appelant doit avoir la permission de lire la ressource cible et de modifier la ressource qui détient la relation.

Sélectionnez le service ou le port applicatif sur lequel le processus écoute réellement. Un port d’hôte publié n’est pas nécessaire pour créer un lien privé, et en ouvrir un ne répare pas un chemin privé en échec. Opfield ne crée pas de règles de pare-feu sur l’hôte et ne rend pas joignables des réseaux arbitraires.

Liaisons de bases de données

Une liaison de base de données managée relie un Container, un Deployment ou un service Compose éligible à une base de données managée. Opfield crée un utilisateur ou un rôle distinct dans le moteur pour la liaison et n’accorde que les permissions de base de données nécessaires. Il fournit à la charge de travail des éléments de connexion propres à la liaison ; l’identifiant du propriétaire de la base n’est pas exposé.

La charge de travail joint la base de données via le connecteur secure-link partagé de son nœud Docker, sur un petit réseau privé propre à la liaison. Il n’existe ni Container connecteur par liaison ni écouteur sur l’hôte à redémarrer, inspecter ou remplacer. Le lien et l’identité dans le moteur sont des enregistrements distincts mais coordonnés : la rotation des identifiants, la modification des permissions ou la suppression concernant une charge de travail n’altère donc pas silencieusement une autre liaison.

Recréer la charge de travail laisse la liaison disponible, car l’autorisation suit l’identité stable de la ressource Opfield plutôt qu’un identifiant de Container transitoire. Opfield réconcilie le lien et injecte à nouveau les paramètres de connexion actuels. Supprimer la liaison retire le lien et met hors service son identité dans le moteur au sein d’un seul cycle de vie enregistré ; le chemin normal ne doit pas laisser de rôles ou d’utilisateurs orphelins.

Pour une liaison de base de données en échec, vérifiez la base managée et le nœud Storage, puis le nœud Docker cible et la charge de travail, l’état souhaité de la liaison, le connecteur secure-link du nœud, l’identité et les permissions dans le moteur, et enfin la configuration de l’application. Ne supprimez pas manuellement le rôle, le réseau du lien ou le connecteur comme réparation générique. Cela peut transformer une incohérence récupérable en identité orpheline ou en échec des réconciliations futures.

Liens entre conteneurs

Un lien entre conteneurs donne à un Container, un Deployment ou un service Compose un accès privé à un port d’une autre charge de travail, sur le même nœud ou sur un autre. Le consommateur joint la cible sous la forme alias:port ; la cible n’a besoin d’aucun port publié, et le lien n’ouvre que ce port, dans un seul sens. Les liens au sein d’un même nœud restent sur ce nœud ; les liens entre nœuds transitent par Relay.

Connecteur partagé et réseaux de liens

À partir de 2.11.1, chaque nœud Docker exécute un seul connecteur secure-link partagé pour toutes ses liaisons de bases de données, tous ses liens de stockage et tous ses liens entre conteneurs. Il n’existe ni conteneurs connecteurs par lien ni écouteurs sur l’hôte. Chaque lien dispose de son propre petit réseau privé, que le consommateur rejoint ; le connecteur y répond à l’alias du lien.

Les nouveaux réseaux de liens prennent leurs adresses dans une plage dédiée, 10.213.x.x (un /16) par défaut, à raison d’un /26 par lien ; les liens n’épuisent donc jamais les pools d’adresses que Docker attribue à vos propres réseaux. Les réseaux créés avant 2.11.1 conservent leurs adresses. Le démon ignore les sous-réseaux déjà utilisés par des réseaux Docker ou par les routes propres de l’hôte. Si la plage chevauche un réseau que le nœud joint par sa route par défaut, comme un réseau de site ou un VPN derrière un routeur, définissez une autre plage IPv4 de /26 ou plus dans le fichier de configuration du démon Docker, /etc/docker-daemon/config.yaml :

docker:
  secure_links:
    subnet_pool: "<IPv4 range in CIDR notation>"

Redémarrez le démon Docker après la modification. Seuls les nouveaux réseaux de liens utilisent la nouvelle plage ; les réseaux existants conservent la leur jusqu’à la recréation de leur lien.

Lorsque le connecteur lui-même est mis à jour, l’ancien connecteur transmet ses connexions ouvertes au nouveau, qui les poursuit sans reconnexion. Un connecteur antérieur à 2.11.4 ne peut pas les transmettre : il les conserve jusqu’à une heure, puis les ferme en une seule fois, et une troisième mise à jour dans cette heure ferme immédiatement les connexions du plus ancien connecteur.

Liens vers les upstreams d’ingress

Les Routes et les Additional Routes peuvent cibler des ressources Docker prises en charge via un Secure Link. Opfield valide la ressource et le port applicatif choisis, crée la relation et réconcilie un connecteur appartenant à Opfield via Relay. Le connecteur utilisé pour le trafic de nginx vers les charges de travail est un véritable composant d’exécution, mais il reste hors du champ des API de cycle de vie ordinaires des utilisateurs.

Un lien créé par une Route gérée appartient à cette Route. Il est visible pour le diagnostic mais ne peut pas être supprimé indépendamment ; désactiver la Route préserve sa configuration et sa relation, tandis que supprimer la Route met hors service la liaison qu’elle détient après réconciliation. Le redémarrage ou la recréation de la charge de travail conserve le lien, car la Route cible la ressource Opfield stable. La promotion d’un Deployment et les changements de révision Compose résolvent l’exécution active derrière la même identité de plus haut niveau.

En 2.11, les écouteurs Secure Link d’un nœud Ingress continuent d’accepter les connexions sous charge. Auparavant, à partir de 2.10.0, le démon nginx vérifiait chaque nouvelle connexion avec un dump complet de la configuration nginx ; un nœud Ingress se bloquait donc au-delà d’environ 100 nouvelles connexions Secure Link par seconde et continuait d’échouer des requêtes longtemps après la baisse de la charge. Désormais, la vérification utilise des informations de processus mises en cache : un nœud Ingress à un seul cœur gère des milliers de nouvelles connexions par seconde, les connexions au-delà de 1024 en cours d’établissement sont refusées immédiatement pour que nginx bascule rapidement au lieu de les mettre en file d’attente, les connexions qu’un client a déjà abandonnées sont écartées sans ouvrir de tunnel, et l’écouteur se rétablit dès que la charge baisse. Une erreur d’acceptation transitoire, comme l’épuisement des descripteurs de fichiers, n’arrête plus un écouteur jusqu’au redémarrage du démon.

Les configurations nginx avancées peuvent utiliser des liaisons supplémentaires gérées séparément, avec leur propre cycle de vie. Ne les confondez pas avec les liaisons appartenant à une Route. Avant de supprimer une liaison gérée par l’utilisateur, identifiez chaque configuration qui y fait référence.

Flux normal et vérification

Pour un upstream d’ingress, choisissez la cible gérée dans l’éditeur de Route ou d’Additional Route, sélectionnez le service ou le port applicatif et le protocole, enregistrez, et attendez à la fois la réconciliation du Secure Link et la validation de la configuration nginx. Vérifiez ensuite l’identité de la cible, l’état du connecteur, la santé de la Route et une vraie requête externe.

Pour une base de données managée, créez la liaison depuis la charge de travail et la base éligibles, choisissez un accès à privilèges minimaux, attendez l’identité dans le moteur et le lien, appliquez la configuration de la charge de travail si nécessaire, et exécutez une vraie requête applicative. Confirmez la télémétrie de la liaison et les journaux de la charge de travail comme de la base de données.

La vérification doit prouver le chemin prévu plutôt que la seule existence d’un enregistrement. Pour l’ingress, examinez la disponibilité de Relay, les connexions des deux nœuds, la latence d’établissement, les flux actifs, le débit, la bonne terminaison des flux, les refus d’admission, les journaux nginx et le comportement de l’application. Pour les liaisons de bases de données, examinez la disponibilité de la base, la réconciliation du lien, l’état du principal dans le moteur, la connectivité applicative et la configuration actuelle de la charge de travail.

Ce que les Secure Links ne font pas

• Ce ne sont pas un VPN ou un réseau overlay à usage général.
• Ils ne fournissent pas de redirection TCP ou SSH arbitraire.
• Ils n’ouvrent pas automatiquement les pare-feu des hôtes.
• Ils ne dispensent pas d’une authentification au niveau applicatif lorsque le protocole cible l’exige.

Ils ne transfèrent pas non plus la propriété de la ressource cible, ne rendent pas portables des charges de travail non prises en charge et n’autorisent pas un utilisateur qui n’a pas accès à l’une ou l’autre extrémité. Un Secure Link ne justifie pas d’exposer les interfaces de contrôle des démons, les ports du propriétaire d’une base de données ou les identifiants internes des connecteurs.

Défaillance et reprise en toute sécurité

Si une Route d’ingress s’enregistre mais que le trafic échoue, vérifiez l’activation et l’état de maintenance de la Route, la révision nginx, Relay, la connectivité des nœuds Ingress et Docker, l’exécution et le port de la cible, l’admission par le connecteur, puis les journaux de l’application et le comportement du protocole. Ne publiez pas un port interne de charge de travail comme contournement non documenté.

En cas d’interruption d’un nœud ou de Relay, rétablissez la connectivité et attendez une nouvelle réconciliation des capacités et de l’état souhaité avant de remplacer des identités. Préservez l’historique des opérations et les identifiants de requêtes. Si une suppression est interrompue, conservez l’enregistrement durable du propriétaire ou de la liaison pour qu’Opfield puisse terminer le nettoyage. La suppression manuelle de connecteurs, de réseaux ou de principaux de moteur appartenant à Opfield est une action de reprise exceptionnelle qui exige une procédure coordonnée, et non une première réponse.