Noeud final de cloud

Par défaut, les clients source de votre emplacement Satellite ne peuvent pas atteindre les ressources de destination qui s'exécutent en dehors de l'emplacement car l'adresse IP de la ressource de destination n'est pas routable à partir de l'emplacement. Consultez le diagramme d'architecture et les étapes suivants, qui montrent comment Satellite Link établit la communication entre les emplacements Satellite et les services qui s'exécutent en dehors des emplacements par l'intermédiaire des noeuds finaux Satellite.

Trafic

1. Lorsque vous créez un point de terminaison pour votre ressource de destination, un port est ouvert pour le connecteur Satellite Link sur vos nœuds du plan de contrôle d' Satellite. Les demandes provenant des sources de votre emplacement Satellite sont effectuées sur le connecteur Satellite Link dont le nom d'hôte et le port ressemblent à nae4dce0eb35957baff66-edfc0a8ba65085c5081eced6816c5b9c-c000.us-east.satellite.appdomain.cloud:30819. Ce nom d'hôte et ce port Link sont mappés au domaine et au port de la ressource de destination.

2. Le connecteur Satellite transfère la requête vers le serveur de tunnel Satellite sur le plan de gestion Satellite via une connexion sécurisée TLS.

3. Le serveur de tunnel Satellite Link résout la demande en adresse IP et en port de destination, puis transfère la demande à la ressource de destination.

Noeud final d'emplacement

Par défaut, les clients source connectés au réseau privé IBM Cloud ne peuvent pas atteindre les ressources de destination qui s'exécutent dans votre emplacement Satellite car l'adresse IP de la ressource de destination n'est pas routable depuis l'extérieur de l'emplacement. Consultez le diagramme d'architecture et les étapes suivants, qui montrent comment Satellite Link établit la communication entre les services connectés au réseau privé IBM Cloud et les emplacements via les noeuds finaux Satellite.

Trafic

1. Lorsque vous créez un noeud final pour une ressource qui s'exécute dans votre emplacement Satellite, un port est ouvert sur le serveur de tunnel Satellite Link et ajouté dans la configuration du noeud final. Les demandes provenant de sources connectées au réseau privé IBM Cloud sont envoyées au nom d'hôte du serveur de tunnel Satellite Link et à ce port, par exemple c-01.us-east.link.satellite.cloud.ibm.com:30819. Ce nom d'hôte et ce port Link sont mappés au domaine et au port de la ressource de destination.

2. Le serveur de tunnel Satellite Link résout la demande en nom d'hôte du connecteur Satellite Link et en port de noeud final, puis transfère la demande au connecteur Satellite Link via une connexion TLS sécurisée.

3. Le connecteur Satellite Link résout la demande en adresse IP et en port de destination, puis transfère la demande à la ressource de destination.

Que se passe-il si Satellite Link devient indisponible ?

Vos charges de travail sur l'emplacement continuent de s'exécuter de manière indépendante, même si la connectivité de l'emplacement à IBM Cloud est indisponible. Toutefois, si des applications utilisent un noeud final Link pour communiquer avec IBM Cloud, la communication entre ces applications et IBM Cloud est interrompue. De plus, toutes les modifications demandées qui sont apportées à votre emplacement Satellite, telles que l'ajout d'hôtes ou de demandes de contrôle d'accès aux services IBM via Cloud Identity and Access Management, sont interrompues. Une fois la connectivité rétablie, les journaux et les événements sont envoyés vers vos instances d' IBM Cloud Logs. Notez que Satellite Link dépend de la connectivité sous-jacente du réseau local de vos hôtes pour surveiller les services gérés pour votre emplacement Satellite et assurer leur maintenance.

Dois-je autoriser le trafic entrant unique entre les ports accessibles sur Internet via des pare-feux et mon emplacement ?

Non. Satellite Link utilise les ports de sécurité Web standard pour créer une communication chiffrée depuis votre emplacement vers IBM Cloud pour la gestion de l'emplacement. Satellite crée des entrées DNS publiques uniques pour chaque emplacement et affecte des ports de la gamme 32768-52768 pour TCP afin que les adresses de destination puissent être résolues de manière prévisible par IBM Cloud. Les canaux de communication sur les noeuds finaux Link entre votre emplacement Satellite et IBM Cloud sont autorisés par l'intermédiaire de vos règles de pare-feu sortantes existantes pour les hôtes.

Si IBM est propriétaire du tunnel Link, comment puis-je m'assurer que nos données sont inaccessibles ? La politique de sécurité de mon organisation ne permet pas les tunnels de nos réseaux.

Satellite Link utilise un modèle Confiance Zéro selon lequel IBM Cloud n'a pas d'accès à vos charges de travail par défaut. Toute gestion de l'infrastructure dans votre emplacement initiée par des ingénieurs de fiabilité des sites (SRE) IBM sur Satellite Link est isolée de vos charges de travail et des connexions réseau, telles que les noeuds finaux Link, utilisées par vos charges de travail. Pour plus d'informations sur les types d'accès dont dispose IBM Cloud à votre emplacement Satellite, voir Accès opérationnel IBM. Pour toute autre connexion dans votre emplacement exigée par vos applications, vous pouvez utiliser Satellite Link pour créer des communications de couche 4 en configurant un noeud final pour chaque ressource de destination dans votre emplacement. Toutes les connexions via vos nœuds finaux sont toujours sous votre contrôle, y compris les nœuds finaux complètement désactivés.

Comment sécuriser mes données en transit ?

Les noeuds finaux Link entre votre emplacement et IBM Cloud sont sécurisés via deux niveaux de chiffrement : le chiffrement haute sécurité à partir du connecteur de l'emplacement vers IBM Cloud fourni par IBM, et une couche de chiffrement supplémentaire facultative entre les ressources source et cible.

Toutes les données transportées via Satellite Link sont chiffrées à l'aide des normes TLS 1.3. Ce niveau de chiffrement est géré par IBM.

Lorsque vous créez un noeud final, vous pouvez éventuellement fournir un autre niveau de chiffrement en spécifiant des protocoles de chiffrement de données pour la connexion de noeud final entre la source du client et la ressource de destination. Par exemple, même si le trafic n'est pas chiffré côté source, vous pouvez spécifier le chiffrement TLS pour la connexion qui passe par Internet. Vous pouvez fournir vos propres certificats signés afin d'assurer à la fois la sécurité interne et l'auditabilité opérationnelle sans exposer de contenu de données. IBM transporte uniquement la connexion chiffrée et vos ressources doivent être configurées pour les protocoles de chiffrement de données que vous spécifiez.

TCP et TLS

Si votre ressource de destination ne requiert pas de demandes avec un en-tête de nom d'hôte HTTP ou HTTPS spécifique, ou peut accepter des demandes directes sur son adresse IP au lieu de son nom d'hôte, utilisez les protocoles TCP ou TLS. Satellite Link utilise le même protocole que la demande de transfert du paquet de requête vers la destination.

HTTP et HTTPS

Si votre ressource de destination est configurée pour écouter un en-tête de nom d'hôte HTTP ou HTTPS spécifique, utilisez le protocole HTTP ou HTTPS. En utilisant le remappage d'en-tête HTTP et HTTPS, Satellite Link est en mesure d'acheminer correctement les demandes pour plusieurs ressources de destination via les ports TCP 80 (HTTP) et 443 (HTTPS).

Noeud final de cloud

Les demandes source de votre emplacement Satellite vers votre ressource de destination qui s'exécute en dehors de l'emplacement contiennent un en-tête HTTP tel que linkconnector_hostname:port. Lorsque la demande est envoyée depuis le connecteur Satellite Link au serveur de tunnel Satellite Link, le serveur de tunnel Satellite Link remplace l'en-tête HTTP de la demande par le nom d'hôte et le port de destination, par exemple dest_hostname:dest_port. Le serveur de tunnel Satellite Link utilise ensuite le nom d'hôte et le port de destination pour transférer la demande vers la ressource de destination appropriée.

Noeud final d'emplacement

Les demandes source provenant de clients qui s'exécutent en dehors de l'emplacement vers votre ressource de destination dans votre emplacement Satellite contiennent un en-tête HTTP tel que linkserver_hostname:endpoint_port. Le serveur de tunnel Satellite Link remplace l'en-tête HTTP de la demande par le nom d'hôte et le port de destination, tels que dest_hostname:dest_port, puis envoie la demande au connecteur Satellite Link. Le connecteur Satellite Link utilise ensuite le nom d'hôte et le port de destination pour envoyer la demande à la ressource de destination appropriée.

Tunnel HTTP

Lorsque vous souhaitez que les connexions TLS soit transmises sans interruption de la source à votre ressource de destination, pour transmettre un certificat à la destination à des fins d'authentification mutuelle par exemple, utilisez le protocole de tunnel HTTP.

La source du client effectue une demande de connexion HTTP au serveur de tunnel ou au composant de connecteur Satellite Link, selon que la destination s'exécute en dehors ou à l'intérieur de votre emplacement Satellite. Le composant Link établit ensuite la connexion à la ressource de destination. Une fois la connexion initiale établie, le composant Link relaie sans interruption la connexion TCP entre la source et la destination.

Le composant Satellite Link n'étant pas impliqué dans la résiliation TLS pour le trafic chiffré, la ressource de destination doit mettre fin à la connexion TLS. Par exemple, si votre ressource de destination exige une authentification mutuelle, le protocole de tunnel HTTP permet à votre source de client de transmettre le certificat d'authentification requis directement à la destination.

Authentification de certificat côté serveur pour TLS et HTTPS

Si vous sélectionnez les protocoles TLS ou HTTPS, vous pouvez éventuellement exiger une vérification côté serveur du certificat de la destination. Le certificat doit être valide pour le nom d'hôte de la destination et signé par une autorité de certification de confiance.

Si votre ressource de destination possède un certificat, vous n'avez pas besoin de le fournir lorsque vous créez le noeud final. Toutefois, si vous testez l'accès à une ressource de destination qui est toujours en cours de développement et que vous n'avez pas encore de certificat digne de confiance, vous pouvez transférer un certificat autosigné pour vérification. Ce fichier ssl.crt doit contenir le certificat public codé en Base64 pour le nom d'hôte de votre ressource et ne doit pas contenir la clé de certificat ssl.key privée. Pour créer un certificat auto-signé à des fins de test à l'aide d' OpenSSL,, consultez ce tutoriel sur les certificats auto-signés SSL.

Restriction de l'accès avec des listes de sources

Par défaut, après avoir configuré un noeud final, n'importe quel client peut se connecter à la ressource de destination via le noeud final. Par exemple, pour un noeud final d'emplacement, n'importe quel client connecté au réseau privé IBM Cloud peut utiliser le noeud final pour se connecter à la ressource de destination qui s'exécute dans votre emplacement Satellite. Pour limiter l'accès à la ressource de destination, vous pouvez spécifier une liste de plages d'adresses IP source de sorte que seuls les clients dignes de confiance puissent accéder au noeud final. Notez que vous ne pouvez actuellement créer des listes de sources que pour les noeuds finaux de type location. Vous ne pouvez pas créer de listes de sources pour les noeuds finaux de type cloud.

Audit d'événements initiés par l'utilisateur

Une fois les listes de sources configurées pour les points de terminaison, vous pouvez configurer l’audit afin de surveiller les événements déclenchés par les utilisateurs pour les points de terminaison Link. L’ IBM Cloud Satellite s’intègre à IBM Cloud Logs pour collecter et envoyer les événements d’audit concernant tous les points de terminaison Link de votre site vers votre instance IBM Cloud Logs. Pour vous initier à l'audit, voir Audit d'événements pour les actions de noeud final.

Puis-je utiliser les nœuds finaux de lien pour

Connecter des ressources au sein du même emplacement Satellite ?

Non. Les nœuds finaux de lien ne peuvent pas être créés entre les ressources du même emplacement. Les ressources peuvent toutefois accéder directement l'une à l'autre. Par exemple, une application s'exécutant dans un cluster Red Hat OpenShift au sein d' Satellite n'a pas besoin de passer par Satellite pour accéder à une base de données située au même emplacement; elle peut y accéder directement via le réseau privé de cet emplacement.

Comment exposer des applications ou des services s'exécutant dans un cluster d' Red Hat OpenShift s dans l' Satellite?

Pour afficher les options disponibles, voir Exposition d'applications dans des clusters Satellite.

Router des réseaux au sein du réseau public IBM Cloud, tel que le spanning VPC ?

Non. Utilisez plutôt la solution de pontage qui est recommandée pour la configuration de votre réseau. Vous pouvez par exemple utiliser Virtual Private Network (VPN) for VPC ou IBM Cloud® Direct Link.

Me connecter à d'autres clouds publics ?

Oui. Avec Satellite Link, vous pouvez créer des noeuds finaux cloud pour les ressources qui s'exécutent dans d'autres clouds publics.

Exemple : Connexion d'un emplacement Satellite à un service dans un autre fournisseur de cloud

Vous souhaitez envoyer des données à partir d'un serveur qui s'exécute sur un hôte de votre emplacement Satellite vers un service qui s'exécute dans Amazon Web Services. Le service doit être accessible au public de sorte que le tunnel Satellite Link, qui se termine au sein du réseau IBM Cloud, puisse accéder au service dans le réseau AWS.

Pour établir cette connexion, commencez par créer un noeud final de cloud. Spécifiez le service qui s'exécute dans AWS comme ressource de destination. Ensuite, le serveur de votre hôte sur site se connecte directement au nom d’hôte du connecteur Satellite Link sur les nœuds du plan de contrôle de votre site. Satellite Link transfère cette requête vers le point de terminaison cloud que vous avez créé pour le service s’exécutant dans AWS.

Exemple : Activation et audit d'un accès limité à un emplacement Satellite depuis IBM Cloud

Vous exécutez une base de données dans votre emplacement Satellite plutôt que dans IBM Cloud, car la base de données est soumise à une réglementation exigeant son exécution dans votre centre de données sur site dans un pays spécifique. Cependant, vous devez tout de même vous connecter à la base de données de votre emplacement Satellite à partir du réseau privé IBM Cloud.

Pour établir cette connexion, commencez par créer un noeud final de location. Spécifiez la base de données qui s'exécute dans votre emplacement Satellite comme ressource de destination. Ensuite, le client du réseau privé IBM Cloud se connecte directement au nom d'hôte du serveur de tunnel Satellite Link. Satellite Link transmet cette demande au nœud final d'emplacement que vous avez créé pour votre base de données sur site.

Enfin, pour assurer la sécurité de l'entreprise et la conformité de l'audit, vous spécifiez une liste de plages d'adresses IP source de sorte que seuls les clients de confiance dans le cloud public puissent accéder à votre base de données sur site via le noeud final. Vous configurez ensuite une instance IBM Cloud Logs de sorte à collecter automatiquement les journaux d'audit pour tous les noeuds finaux de votre emplacement Satellite.