Fermer

avril 18, 2022

Accès sécurisé à Opensearch sur AWS


Chez Buffer, nous avons travaillé sur un meilleur tableau de bord d'administration pour notre équipe de défense des clients. Ce tableau de bord d'administration comprenait une fonctionnalité de recherche beaucoup plus puissante. À l'approche de la fin de la chronologie du projet, nous avons été invités à remplacer Elasticsearch géré sur AWS par Opensearch géré. Notre projet a été construit sur des versions plus récentes du client elasticsearch quidu coup n'a pas supportéOuvrir la recherche.

Pour ajouter de l'huile sur le feu, les clients OpenSearch pour les langages que nous utilisons ne prenaient pas encore en charge les signatures AWS Sigv4 transparentes. La signature AWS Sigv4 est une exigence pour s'authentifier auprès du cluster OpenSearch à l'aide des informations d'identification AWS.

Cela signifiait que la voie à suivre était criblée de l'une de ces options

  • Laissez notre cluster de recherche ouvert au monde sans authentification, cela fonctionnerait avec le client OpenSearch. Inutile de dire que c'est un énorme NO GO pour des raisons évidentes.
  • Refactoriser notre code pour envoyer des requêtes HTTP brutes et implémenter nous-mêmes le mécanisme AWS Sigv4 sur ces requêtes. C'est irréalisable, et nous ne voudrions pas réinventer nous-mêmes une bibliothèque client !
  • Créez un plug-in/middleware pour le client qui implémente la signature AWS Sigv4. Cela fonctionnerait au début, mais Buffer n'est pas une grande équipe et avec des mises à niveau de service constantes, ce n'est pas quelque chose que nous pouvons maintenir de manière fiable.
  • Basculez notre infrastructure pour utiliser un cluster elasticsearch hébergé sur le cloud d'Elastic. Cela a nécessité d'énormes efforts lorsque nous avons examiné les conditions d'utilisation d'Elastic, les tarifs, les exigences pour une configuration réseau sécurisée et d'autres mesures chronophages.

Il semblait que ce projet était coincé pour le long terme! Ou était-ce?

En regardant la situation, voici les constantes que nous ne pouvons pas changer de manière réaliste.

  • Nous ne pouvons plus utiliser le client elasticsearch.
  • Le passage au client OpenSearch fonctionnerait si le cluster était ouvert et ne nécessitait aucune authentification.
  • Nous ne pouvons pas laisser le cluster OpenSearch ouvert au monde pour des raisons évidentes.

Ne serait-il pas agréable que le cluster OpenSearch soit ouvert UNIQUEMENT aux applications qui en ont besoin ?

Si cela peut être accompli, alors ces applications pourraient se connecter au cluster sans authentification leur permettant d'utiliser le client OpenSearch existant, mais pour tout le reste, le cluster serait inaccessible.
Avec cet objectif final à l'esprit, nous avons conçu la solution suivante.

S'appuyer sur notre récente migration de Kubernetes autogéré vers Amazon EKS

Nous avons récemment migré notre infrastructure de calcul d'un cluster Kubernetes autogéré vers un autre cluster géré par Amazon EKS.
Avec cette migration, nous avons échangé notre interface réseau de conteneurs (CNI) de flannel vers VPC CNI. Cela implique que nous avons éliminé la division des réseaux superposés/sous-jacents et que tous nos pods obtenaient désormais des adresses IP routables VPC.
Cela deviendra plus pertinent à l'avenir.

Bloquer l'accès au cluster depuis le monde extérieur

Nous avons créé un cluster OpenSearch dans un VPC privé (pas d'adresses IP accessibles sur Internet). Cela signifie que les adresses IP du cluster ne seraient pas accessibles via Internet, mais uniquement vers les adresses IP routables du VPC interne.
Nous avons ajouté trois groupes de sécurité au cluster pour contrôler les adresses IP VPC autorisées à atteindre le cluster.

Construire des automatisations pour contrôler ce qui est autorisé à accéder au cluster

Nous avons construit deux automatisations fonctionnant en tant qu'AWS lambdas.

  • Gestionnaire de groupe de sécurité : cette automatisation peut exécuter deux processus à la demande.
  • -> Ajouter une adresse IP à l'un de ces trois groupes de sécurité (celui avec le moins de règles au moment de l'ajout).
  • -> Supprimer une adresse IP partout où elle apparaît dans ces trois groupes de sécurité.
  • Auditeur du cycle de vie des pods : cette automatisation s'exécute dans les délais et nous verrons ce qu'elle fait dans un instant.

Nous avons ajouté unInitContainer à tous les pods ayant besoin d'accéder au cluster OpenSearch qui, au démarrage, exécutera l'automatisation du gestionnaire de groupe de sécurité et lui demandera d'ajouter l'adresse IP du pod à l'un des groupes de sécurité. Cela lui permet d'atteindre le cluster OpenSearch.
Dans la vraie vie, des choses se produisent et les pods sont tués et ils obtiennent de nouvelles adresses IP. Par conséquent, dans les délais, l'auditeur du cycle de vie des pods s'exécute et vérifie toutes les adresses IP de la liste blanche dans les trois groupes de sécurité qui permettent l'accès au cluster. Il vérifie ensuite quelles adresses IP ne doivent pas s'y trouver et réconcilie les groupes de sécurité en demandant au gestionnaire de groupe de sécurité de supprimer ces adresses IP.
Voici un schéma de la façon dont tout cela se connecte

Diagramme de notre solution pour résoudre les problèmes d'accès à Opensearch via une liste blanche automatisée, source : Peter Emil au nom de l'équipe d'infrastructure de Buffer
Diagramme de notre solution pour résoudre les problèmes d'accès à Opensearch via une liste blanche automatisée, source : Peter Emil au nom de l'équipe d'infrastructure de Buffer

Pourquoi avons-nous créé trois groupes de sécurité pour gérer l'accès au cluster OpenSearch ?

Parce que les groupes de sécurité ont une limite maximale de 50 règles d'entrée/sortie. Nous prévoyons que nous n'aurons pas plus de 70 à 90 pods à un moment donné ayant besoin d'accéder au cluster. Avoir trois groupes de sécurité fixe la limite à 150 règles, ce qui nous semble un endroit sûr pour commencer.

Dois-je héberger le cluster Opensearch dans le même VPC que le cluster EKS ?

Cela dépend de votre configuration réseau ! Si votre VPC possède des sous-réseaux privés avec des passerelles NAT, vous pouvez l'héberger dans n'importe quel VPC de votre choix. Si vous n'avez pas de sous-réseaux privés, vous devez héberger les deux clusters dans le même VPC car VPC CNI par défautNAT Trafic de pod externe au VPC à l'adresse IP du nœud d'hébergement qui invalide cette solution. Si vous désactivez la configuration NAT, vos pods ne peuvent pas accéder à Internet, ce qui est un problème plus important.

Si un pod reste bloqué dans l'état CrashLoopBackoff, l'énorme volume de redémarrages n'épuisera-t-il pas la limite de 150 règles ?

Non, car les plantages du conteneur dans un pod sont redémarrés avec la même adresse IP dans le même pod. L'adresse IP n'est pas modifiée.

Ces automatisations ne sont-elles pas un point de défaillance unique ?

Oui, c'est pourquoi il est important de les aborder avec un état d'esprit SRE. Une surveillance adéquate de ces automatisations combinées à des déploiements progressifs est cruciale pour avoir la fiabilité ici. Depuis que ces automatisations ont été mises en place, elles sont très stables et nous n'avons eu aucun incident. Cependant, je dors tranquillement la nuit en sachant que si l'un d'eux se casse pour une raison quelconque, je serai averti bien avant que cela ne devienne un problème notable.

Je reconnais que cette solution n'est pas parfaite, mais c'était la solution la plus rapide et la plus simple à mettre en œuvre sans nécessiter de maintenance continue et sans plonger dans le processus d'intégration d'un nouveau fournisseur de cloud.

À vous

Que pensez-vous de l'approche que nous avons adoptée ici? Avez-vous rencontré des situations similaires dans votre organisation ?Envoyez-nous un tweet!






Source link