La fonctionnalité mTLS Apigee renforce la sécurité des communications entre les composants de votre périphérie pour le cluster de cloud privé.
Présentation de l'architecture
Pour assurer des communications sécurisées entre les composants, Apigee mTLS utilise un maillage de services qui établit des connexions TLS sécurisées et authentifiées mutuellement entre les composants.
L'image suivante montre les connexions entre les composants Apigee sécurisés par le protocole mTLS d'Apigee (in red). Les ports indiqués dans l'image sont des exemples. Reportez-vous à la section Utilisation des ports pour obtenir la liste des plages que chaque composant peut utiliser.
(Notez que les ports indiqués par un "M" sont utilisés pour gérer le composant et doivent être ouverts sur le composant pour que le serveur de gestion puisse y accéder.)
Comme vous pouvez le voir dans le schéma ci-dessus, Apigee mTLS renforce la sécurité des connexions entre la plupart des composants du cluster, y compris:
Source | Destination | |
---|---|---|
Serveur de gestion | Nœuds Routeur, MP, QPid, LDAP, Postgres, Zookeeper et Cassandra | |
Routeur | Bouclage avec les nœuds Qpid, Zookeeper et Cassandra | |
Processeur de messages | Bouclage avec les nœuds Qpid, Zookeeper et Cassandra | |
ZooKeeper et Cassandra | Autres nœuds Zookeeper et Cassandra | |
Interface utilisateur périphérique | SMTP (pour l'IdP externe uniquement) | |
Postgres | Autres nœuds Postgres, Zookeeper et Cassandra |
Chiffrement/déchiffrement des messages
Le maillage de services Apigee mTLS se compose de serveurs Consul qui s'exécutent sur chaque nœud ZooKeeper de votre cluster, ainsi que des services Consul suivants sur chaque nœud du cluster:
- Un proxy de sortie qui intercepte les messages sortants sur le nœud hôte Ce service chiffre les messages sortants avant de les envoyer à leur destination.
- un proxy d'entrée qui intercepte les messages entrants sur le nœud hôte ; Ce service déchiffre les messages entrants avant de les envoyer à leur destination finale.
Par exemple, lorsque le serveur de gestion envoie un message au routeur, le service proxy de sortie intercepte le message sortant, le chiffre, puis l'envoie au routeur. Lorsque le nœud du routeur reçoit le message, le service proxy d'entrée le déchiffre, puis le transmet au composant de routeur pour traitement.
Tout cela se produit de manière transparente pour les composants Edge: ils ignorent le processus de chiffrement et de déchiffrement effectué par les services proxy Consul.
En outre, Apigee mTLS utilise l'utilitaire iptables
, un service de pare-feu Linux qui gère la redirection du trafic.
Conditions requises
Apigee mTLS offre une méthode standard pour configurer et installer le maillage de services. Il permet la gestion des packages et l'automatisation de la configuration.
Étant donné que les services proxy Consul sont étroitement couplés en tant qu'attributions de ports pour des processus individuels, la modification d'un nœud affecte tous les autres nœuds. Par conséquent, si votre topologie change, vous devez reconfigurer et réinitialiser les services sur chaque nœud du cluster.
Pour que vous puissiez installer Apigee mTLS, votre environnement doit répondre aux exigences suivantes décrites dans cette section.
Voici les éléments à déterminer :
- Version Edge pour le cloud privé
- Un ensemble d'utilitaires installés et activés
- Un compte utilisateur avec le niveau d'autorisation approprié
- Une machine d'administration (recommandé)
Exigences liées à Edge pour le cloud privé
Apigee mTLS est compatible avec la version d'Edge suivante pour le cloud privé (mais pas sur toutes les plates-formes compatibles, comme décrit dans la section Configuration requise pour le système d'exploitation):
- 4.19.06
- 4.19.01
Apigee mTLS nécessite que votre cluster de cloud privé utilise une topologie incluant au moins trois nœuds Zoookeeper. Par conséquent, vous ne pouvez installer Apigee mTLS que sur les topologies utilisant 5, 9, 12 (centres de données multiples) ou 13 nœuds. Pour en savoir plus, consultez la section Topologies d'installation.
Configuration requise pour le système d'exploitation
Apigee mTLS est compatible avec les plates-formes suivantes pour votre cluster de cloud privé (le système d'exploitation compatible avec mTLS dépend de la version du cloud privé):
Système d'exploitation | Version du cloud privé compatible | ||
---|---|---|---|
v4.19.06 | v4.50.00 | v4.51.00 | |
CentOS RedHat Enterprise Linux (RHEL) Oracle Linux |
7,5, 7,6, 7,7 | 7,5, 7,6, 7,7, 7,8, 7,9 | 7,5, 7,6, 7,7, 7,8, 7,9, 8,0 |
Utilitaires/Packages
Apigee mTLS nécessite que les packages suivants soient installés et activés sur chaque machine de votre cluster, y compris votre machine d'administration, avant de commencer le processus d'installation:
Utilitaire/Package | Description | Possibilité de les supprimer après l'installation ? |
---|---|---|
base64 |
Vérifie les données dans les scripts d'installation. | |
gnu-bash gnu-sed gnu-grep |
Utilisé par le script d'installation et d'autres outils courants. | |
iptables |
Remplace le pare-feu par défaut, firewalld . |
|
iptables-services |
Fournit des fonctionnalités à l'utilitaire iptables . |
|
lsof |
Utilisé par le script d'installation. | |
nc |
Vérifie les routes iptables . |
|
openssl |
Signe les certificats localement lors du processus d'amorçage initial. |
Lors de l'installation, vous installez également le package Consul sur la machine d'administration afin de pouvoir générer des identifiants et la clé de chiffrement.
Le package apigee-mtls
installe et configure les serveurs Consul, y compris les proxys d'entrée et de sortie sur les nœuds ZooKeeper du cluster.
Autorisations du compte utilisateur
Le compte qui exécute l'installation mTLS Apigee sur chaque nœud du cluster doit pouvoir:
- Démarrer, arrêter, redémarrer et initialiser les composants Apigee
- Définir des règles de pare-feu
- Créer un compte utilisateur OS/système
- Activer, désactiver, démarrer, arrêter et masquer des services avec
systemctl
Machine d'administration (recommandé)
Apigee vous recommande de disposer d'un nœud dans le cluster que vous pouvez utiliser pour effectuer diverses tâches décrites dans ce document, y compris:
- Installez HashiCorp Consul 1.6.2.
- Générez et distribuez une paire certificat/clé et une clé de chiffrement de rumeurs.
- Mettez à jour et distribuez le fichier de configuration.
La machine d'administration requiert que:
- Vous avez téléchargé et installé les utilitaires
apigee-service
etapigee-setup
, comme décrit dans la section Installer l'utilitaire de configuration d'Edge. - Dispose d'un accès
scp/ssh
à tous les nœuds du cluster. Pour distribuer votre fichier de configuration et vos identifiants, vous devez disposer d'un accèsscp/ssh
à tous les hôtes du cluster. - Vous disposez d'un accès racine à la machine d'administration.
Utilisation et attribution des ports
Cette section décrit l'utilisation et les attributions de ports pour prendre en charge les communications Consul avec Apigee mTLS.
Utilisation des ports: tous les nœuds exécutant apigee-mtls
Tous les nœuds du cluster qui utilisent le service apigee-mtls
doivent autoriser les connexions à partir des services sur l'hôte local (127.0.0.1). Cela permet aux proxys Consul de communiquer avec les autres services lorsqu'ils traitent les messages entrants et sortants.
Utilisation du port: nœuds du serveur Consul (nœuds exécutant ZooKeeper)
Vous devez ouvrir la plupart des ports suivants sur les nœuds du serveur Consul (nœuds exécutant ZooKeeper) pour accepter les requêtes de tous les nœuds du cluster:
Nœud | Port du serveur Consul | Description | Protocole | Autoriser les agents mtls externes * |
---|---|---|---|---|
Serveur Consul (nœuds ZooKeeper) | 8300 |
Connecte tous les serveurs Consul du cluster. | RPC | |
8301 |
Gère les messages d'abonnement et de diffusion dans le cluster. | UDP/TCP | ||
8302 |
Port WAN qui gère les messages d'adhésion et de diffusion dans une configuration de plusieurs centres de données. | UDP/TCP | ||
8500 |
Gère les connexions HTTP aux API du serveur Consul à partir de processus sur le même nœud.
Ce port n'est pas utilisé pour la communication ou la coordination à distance. Il n'écoute que sur localhost. |
HTTP | ||
8502 |
Gère les connexions gRPC+HTTPS vers les API du serveur Consul à partir d'autres nœuds du cluster. | gRPC+HTTPS | ||
8503 |
Gère les connexions HTTPS aux API du serveur Consul à partir d'autres nœuds du cluster. | HTTPS | ||
8600 |
Gère le DNS du serveur Consul. | UDP/TCP | ||
* Apigee vous recommande de limiter les requêtes entrantes aux membres du cluster (y compris entre les datastores). Pour ce faire, utilisez iptables .
|
Comme le montre ce tableau, les nœuds exécutant le composant consul-server
(nœuds ZooKeeper) doivent ouvrir les ports 8301, 8302, 8502 et 8503 à tous les membres du cluster qui exécutent le service apigee-mtls
, même entre les centres de données. Les nœuds qui n'exécutent pas ZooKeeper n'ont pas besoin d'ouvrir ces ports.
Attributions de ports pour tous les nœuds Consul (y compris les nœuds exécutant ZooKeeper)
Pour accepter les communications Consul, les nœuds exécutant les composants Apigee suivants doivent autoriser les connexions externes aux ports situés dans les plages suivantes:
Composant Apigee | Plage | Nombre de ports requis par nœud |
---|---|---|
mTLS Apigee | 10 700 à 10 799 | 1 |
Cassandra | 10 100 à 10 199 | 2 |
Processeur de messages | 10 500 à 10 599 | 2 |
OpenLDAP | 10 200 à 10 299 | 1 |
Postgres | 10 300 à 10 399 | 3 |
QPID | 10 400 à 10 499 | 2 |
Routeur | 10 600 à 10 699 | 2 |
ZooKeeper | 10 001 à 10 099 | 3 |
Consul attribue des ports de manière simple et linéaire. Par exemple, si votre cluster comporte deux nœuds Postgres, le premier nœud utilise deux ports. Consul lui attribue donc les ports 10300 et 10301. Le deuxième nœud utilise également deux ports. Consol lui attribue donc les ports 10302 et 10303. Cela s'applique à tous les types de composants.
Comme vous pouvez le constater, le nombre réel de ports dépend de la topologie. Si votre cluster comporte deux nœuds Postgres, vous devez ouvrir quatre ports (deux nœuds multipliés par deux ports chacun).
Veuillez noter les points suivants :
- Les proxys Consul ne peuvent pas écouter sur les mêmes ports que les services Apigee.
- Consul n'a qu'un seul espace d'adressage de port. Les attributions de ports du proxy Consul doivent être uniques au sein du cluster, y compris dans les centres de données. Cela signifie que si le proxy A de l'hôte A écoute sur le port 15 000, le proxy B de l'hôte B ne peut pas écouter sur le port 15 000.
- Le nombre de ports utilisés varie en fonction de la topologie, comme décrit précédemment.
Dans une configuration multicentre de données, tous les hôtes exécutant mTLS doivent également ouvrir le port 8302.
Vous pouvez personnaliser les ports par défaut utilisés par Apigee mTLS. Pour savoir comment procéder, consultez la section Personnalisation de la plage de ports du proxy.
Limites
Apigee mTLS présente les limites suivantes:
- Ne chiffre pas les communications Cassandra entre les nœuds (port 7000).
- La configuration ne sont pas idempotentes. Cela signifie que si vous effectuez une modification sur un nœud, vous devez effectuer la même modification sur tous les nœuds. Le système ne récupère pas cette modification et ne l'applique pas à d'autres nœuds à votre place. Pour en savoir plus, consultez la section Modifier une configuration apigee-mtls existante.
Terminologie
Cette section utilise la terminologie suivante:
Terme | Définition |
---|---|
Cluster | Groupe de machines qui constituent votre périphérie pour l'installation du cloud privé. |
Consul | Maillage de services utilisé par Apigee mTLS. Pour découvrir comment Consul sécurise vos communications dans le cloud privé, consultez la page sur le modèle de sécurité de Consul. |
mTLS | Authentification mutuelle TLS. |
maillage de services | Réseau superposé (ou réseau au sein d'un réseau). |
TLS | Sécurité par couche de transaction Protocole d'authentification standard dans l'industrie pour des communications sécurisées. |