3 votes

Autoriser les exceptions (liste blanche) par le biais de l'IAP de Google Cloud Platform

Mon projet GCP dispose d'une instance qui exécute un serveur Jenkins derrière un système de gestion des données. IAP -Un équilibreur de charge protégé.

L'ajout de la protection IAP m'a causé 2 problèmes connexes que je n'ai pas réussi à résoudre (et je suppose que les deux pourraient être résolus de manière similaire) :

  1. J'avais l'habitude d'avoir un esclave Jenkins physique (qui doit être physique car il est connecté à un matériel spécial) qui était connecté au serveur cloud Jenkins. Maintenant que le serveur cloud est protégé par IAP, l'esclave Jenkins sur site ne peut plus s'y connecter car l'application JNLP de l'esclave ne sait pas comment s'autoriser avec l'interface de connexion Google. ( EDIT : J'ai fini par contourner ce problème spécifique en créant un tunnel SSH pour l'esclave directement sur la machine du serveur Jenkins. )

  2. J'avais l'habitude d'avoir un dépôt BitBucket-Cloud qui POST au serveur Jenkins via la fonctionnalité webhook de BitBucket. BitBucket ne sait pas non plus comment autoriser l'IAP, ce qui fait que cela ne fonctionne plus non plus.

Il semble que Google supporte autorisation par voie programmatique mais dans les deux cas, je n'ai aucun contrôle programmatique sur l'entité qui doit communiquer avec le serveur Jenkins.

Y a-t-il un moyen de contourner ce problème ? J'ai plusieurs pistes en tête, mais je ne suis pas sûr de la meilleure façon de procéder / si c'est même possible :

  • Existe-t-il un moyen de mettre sur liste blanche des URL spécifiques dans IAP afin qu'elles ne nécessitent aucune autorisation ? Par exemple, permettre à tout le monde d'accéder sans autorisation à https://my.jenkins.domain.com/bitbucket-scmsource-hook/notify BitBucket peut donc faire du webhook (je sais que la sécurité n'est pas optimale).

  • Existe-t-il un moyen de mettre sur liste blanche l'accès à partir d'IP spécifiques ? Permettez à toutes les requêtes provenant de BitBucket Cloud et à toutes les requêtes provenant de l'esclave physique de passer sans que l'IAP ne demande leur authentification. Il est évident que cela n'est pas non plus optimal en termes de sécurité.

  • Peut-être créer un autre load-balancer parallèle sans IAP qui route également vers le serveur Jenkins, que je configurerai spécifiquement pour mettre sur liste blanche les URL/IP comme je l'ai décrit ci-dessus et sur liste noire tout le reste, et faire en sorte que BitBucket et l'esclave physique s'y connectent au lieu du load-balancer normal. Mêmes considérations sur les problèmes de sécurité que les solutions ci-dessus, très compliqué, nécessitant un autre nom de domaine. Pas du tout optimal. Mais c'est la seule solution pratique à laquelle je pense.

Qu'en pensez-vous ? Avez-vous des idées meilleures, plus simples, plus sûres ? J'ai peut-être oublié un moyen évident de le faire ? Je n'ai rien trouvé dans la documentation de l'IAP sur la façon de réaliser quelque chose comme ça.

1voto

Eric Sherman Points 11

Donc la meilleure réponse ici est en fait ce que vous recherchez. J'ai une petite VM séparée avec un proxy inverse Nginx qui est uniquement utilisé pour gérer les webhooks. Il est dirigé vers le même backend Jenkins que mon équilibreur de charge Google IAP.

J'utilise GitHub pour mes webhooks mais j'imagine que cela fonctionne probablement de manière similaire pour Bitbucket.

En fait, j'aurais une tâche Jenkins qui s'exécuterait périodiquement (quotidiennement ?) et qui ferait ce qui suit récupérer les entrées CIDR d'ici et mettez à jour votre règle de pare-feu pour votre autre équilibreur de charge.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X