blog.bressure.net

Mon infra dockerisée est la suivante:

Elle me permet de limité l’utilisation des ressources en éteignant les conteneurs staging si besoin. L’environnement de staging n’est pas accessible depuis internet mais tout service qui est dans la VM de production ou sur l’infra est accessible depuis internet. Cette accès est « automatique »et le guidage se fait sur le nom de domaine.

L’objectif est d’installer une Selenium Grid qui sera utilisé dans l’intégration continue pour faire des tests IHM.

Avertissement Selenium

La documentation de Sélenium indique clairement qu’il ne faut pas compter sur lui pour assurer la sécurité. Particulièrement il est recommandé que l’infra empêche tout accès depuis l’extérieur en utilisant un firewall par exemple.

Dans mon architecture, je vais utiliser les ports 88, respectivement 99 comme entrée de selenium hub de production , respectivement de staging. Ces derniers correspondent aux port des Traefik de production, respectivement de staging.

Afin de protéger mon Selenium hub je vais ajouter une règle dans le haproxy pour bloquer l’accès sur le domaine selenium.bressure.net. Ainsi le flux sera coupé et n’atteindra pas Traefik.

acl host_selenium  hdr_dom(host) selenium.bressure.net
http-request deny if host_selenium 

En testant l’accès via le port du haproxy de staging sur le port 7171, j’obtiens bien un refus:

Ça marche sur staging (qui est inaccessible depuis internet), on peut appliquer la méthode sur le haproxy de production (accessible depuis internet) et tester le refus:

Installation dockerisée de sélenium

Je modifie à la marge le fichier d’exemple trouvé sur le github de la version dockerisée de Sélenium en supprimant l’exposition du port 4444 (merci à Traefik !).

version: "3.7"
services:
  selenium-hub:
    image: selenium/hub:4
    container_name: selenium-hub
  chrome:
    image: selenium/node-chrome:4
    volumes:
      - /dev/shm:/dev/shm
    depends_on:
      - selenium-hub
    environment:
      - HUB_HOST=selenium-hub
  firefox:
    image: selenium/node-firefox:4
    volumes:
      - /dev/shm:/dev/shm
    depends_on:
      - selenium-hub
    environment:
      - HUB_HOST=selenium-hub
  opera:
    image: selenium/node-opera:4
    volumes:
      - /dev/shm:/dev/shm
    depends_on:
      - selenium-hub
    environment:
      - HUB_HOST=selenium-hub

Les fichiers complémentaires pour Traefik sont accessible depuis mon dépôt Git:

• docker-compose.staging.yml
• docker-compose.infra.yml

Nom de domaine en HSTS

Comme dans mon architecture c’est le frontal apache qui fait le TLS, je n’ai plus de HTTPS quand je passe directement sur Traefik. J’ai bien un certificats dans Traefik mais ce dernier ne correspond pas au domaine pour sélénium et je veux minimiser les problème de configuration. L’accès au hub pour la communication de tâches de test IHM doit se faire en clair… de toute façon je suis bien à l’intérieur de ma propre infra à ce stade.

Or comme mon domaine est estampillé HSTS, *.bressure.net finit par être marqué comme devant être accédé uniquement en HTTPS. Cela va poser problème pour la suite. Donc il vaut mieux pour moi d’utiliser un nom de domaine interne ou un autre disons selenium.bressure.infra. Ce nom n’est pas géré par mon frontal TLS et sera dirigé vers l’hôte virtuel par défaut correspondant à la page d’accueil de mon serveur web si on y accède depuis internet. Pour rappel, le Vitual Host par défaut est celui qui arrive en premier dans la configuration de apache. Je garde la protection sur le haproxy car un mauvais ordre des Virtual Host dans la configuration de apache et voilà que le flux pourrait être dirigé vers le HAProxy. Deux protections valent mieux qu’une !

Test d’accès

Les protections mises en place plus haut sont là pour empêcher l’accès par le frontal TLS et le HAProxy. Le seul moyen pour accéder à sélénium est alors le Traefik sur le port 99 en staging et 88 en production. Il faut rentrer l’URL /wd/hub/status