Upstreams sécurisés

Un upstream sécurisé permet à une Route publique d’atteindre une charge de travail gérée privée sans publier le port d’hôte de la charge de travail. Un Secure Link est le transport privé authentifié d’Opfield entre le côté Ingress et le côté charge de travail, via Relay. La charge de travail ne garde aucun port d’hôte ouvert, et la Route suit l’identité gérée de la charge de travail au fil des redémarrages et des recréations.

Utilisez-le lorsque l’application ne doit être publique qu’à travers l’ingress d’Opfield. L’authentification et la santé de l’application restent du ressort de l’application. La configuration est terminée lorsque la charge de travail n’a aucun port public inutile, que le lien est prêt et qu’une vraie requête réussit via le nom d’hôte canonique.

Sélectionnez une cible Docker gérée dans l’éditeur de Route ou d’Additional Route. Opfield valide la propriété de la charge de travail, votre accès à la cible Docker et le service ou le port choisi, crée le Secure Link appartenant à la Route et réconcilie l’état du connecteur via Relay.

Les liaisons appartenant à une Route suivent le cycle de vie de la Route. Elles peuvent être examinées, mais pas supprimées indépendamment. Les liaisons supplémentaires gérées par l’utilisateur sont destinées à la configuration nginx avancée et ont leur propre cycle de vie.

Une liaison supplémentaire peut aussi cibler un stockage objet managé prêt (Managed S3 storage) : du S3 privé via Relay, sans réseau Docker partagé ni port S3 publié. Les clients ont toujours besoin d’identifiants S3. Référencez-la dans la configuration avancée sous la forme {{additionalSecureLinks.<name>}}, qui inclut déjà le schéma, par exemple proxy_pass {{additionalSecureLinks.<name>}}; ; une liaison encore référencée par la configuration avancée ne peut pas être supprimée. Sa création nécessite le droit de modifier la Route et de consulter le stockage, et un stockage managé ne peut pas être l’upstream principal d’une Route.

Vérifiez la santé du connecteur, la santé de la Route et le comportement de l’application. Lorsqu’une charge de travail est recréée, Opfield reconnecte le lien par l’identité stable de la ressource. Lorsqu’une Route est supprimée, Opfield met hors service la liaison qu’elle détient.

Ne contournez pas un lien en échec en publiant un port interne de charge de travail tant que vous n’avez pas compris la panne. Vérifiez d’abord la santé de Relay, les connexions des deux nœuds, l’identité de la cible, l’autorisation de périmètre et les journaux du connecteur.

Prérequis

• Les nœuds Ingress et Docker sont en ligne et compatibles avec le contrat Relay actuel.
• Le Container, le Deployment ou le service Compose cible appartient à Opfield et possède une identité de ressource stable.
• Le port applicatif sélectionné est celui sur lequel le processus écoute réellement, et non un port d’hôte publié sans rapport.
• L’appelant peut lire la cible et modifier la Route.
• Relay est sain et les deux nœuds peuvent joindre le point de terminaison Relay qui leur est attribué.

Créer un upstream géré

1. Ouvrez l’éditeur de Route ou d’Additional Route.
2. Choisissez le type de cible Docker gérée.
3. Sélectionnez le nœud et la ressource au lieu de saisir une adresse de conteneur éphémère.
4. Sélectionnez le service ou le port applicatif et le protocole. Avec un démon Docker 2.11, la boîte de dialogue renseigne le port sur lequel le conteneur écoute réellement, y compris pour les images qui ne déclarent aucun port (pas d’EXPOSE) ; les démons plus anciens ne proposent que les ports déclarés.
5. Enregistrez la Route et attendez à la fois la réconciliation du Secure Link et la validation de la configuration nginx.
6. Vérifiez le badge de la cible, la télémétrie Link Runtime, la santé de la Route et une requête externe.

Le conteneur connecteur utilisé pour le trafic de nginx vers la charge de travail appartient à Opfield. Il est masqué des opérations de cycle de vie ordinaires et est publié avec Relay. Recréer la charge de travail applicative ne doit ni transférer la propriété de ce connecteur ni exiger une nouvelle Route.

Comportement du cycle de vie

• 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 met à jour la charge de travail active derrière la même identité de Deployment.
• L’application de Compose résout le service sélectionné à partir de la révision active du projet.
• Désactiver une Route arrête son service, mais préserve sa configuration et la relation qu’elle détient.
• Supprimer une Route met hors service la liaison qu’elle détient après réconciliation.
• Une liaison supplémentaire gérée par l’utilisateur a un cycle de vie indépendant et doit être retirée explicitement. Sa suppression est refusée tant que la configuration avancée ou brute de la Route, ou la configuration avancée d’une Additional Route, y fait encore référence, soit via sa variable {{additionalSecureLinks.<name>}}, soit par son nom d’upstream généré.

Diagnostic des échecs

Si la Route s’enregistre mais que le trafic échoue, vérifiez dans cet ordre :

1. la Route est activée et n’est pas en maintenance ;
2. la révision de configuration nginx est appliquée ;
3. la disponibilité de Relay ;
4. la connectivité des nœuds Ingress et Docker ;
5. l’état d’exécution de la ressource cible et le port sélectionné ;
6. l’état du connecteur Secure Link et les erreurs d’admission ;
7. les journaux de l’application et le comportement du protocole.

Ne publiez un port d’hôte que lorsque l’accès public ou direct est lui-même une exigence produit, et non comme mécanisme de reprise non documenté.

Implications en matière de sécurité et de propriété

Un upstream géré évite d’exposer la charge de travail sur un port d’hôte ordinaire, mais il ne rend pas automatiquement l’application digne de confiance. La Route définit toujours la frontière des requêtes publiques, nginx termine ou transmet toujours le protocole sélectionné, et l’application doit authentifier les requêtes lorsque son contrat produit l’exige. Le Secure Link protège le transport privé et la sélection de la cible ; ce n’est pas une couche d’autorisation applicative.

Le connecteur généré et ses identifiants appartiennent à Opfield. Les opérateurs ne doivent pas recréer, renommer, s’attacher à ce connecteur ni l’utiliser via les API de cycle de vie Docker ordinaires. L’accès à la ressource de la charge de travail n’accorde pas la propriété de la ressource de transport. Cette séparation empêche un opérateur de charge de travail de substituer une image de connecteur ou de lire du matériel de transport qui appartient au plan de contrôle.

N’accordez aux utilisateurs que les scopes de Route et de charge de travail nécessaires à leur travail. Une personne qui peut modifier à la fois la Route publique et la charge de travail cible peut rediriger le trafic de production même sans accès direct aux éléments internes du connecteur ; traitez donc cette combinaison de permissions comme une autorité de déploiement en production.

Procédure de modification et de reprise

Avant de recréer ou de promouvoir une cible, consignez la Route, la ressource stable sélectionnée, le port applicatif et la santé actuelle du lien. Effectuez l’opération sur la charge de travail via son propriétaire, attendez que la nouvelle exécution soit prête, puis confirmez que le Secure Link s’est réconcilié avec la même identité stable. Vérifiez une requête externe ; un badge de charge de travail au vert ne prouve pas à lui seul que le chemin de la Route fonctionne.

Si la réconciliation reste en échec alors que les deux nœuds et Relay sont sains, conservez l’opération en échec et les journaux du connecteur, puis relancez l’action de réconciliation prise en charge. Recréer la Route est un dernier recours, car cela modifie la propriété et supprime un historique utile. Si le trafic client doit rester indisponible pendant la réparation, utilisez le mode maintenance plutôt que de publier le port privé.