Rôle Ansible "papanito.cloudflared"

Ce rôle Ansible télécharge et installe cloudflared sur l'hôte et, en option, installe argo-tunnel en tant que service.

Changements majeurs avec la version 3.0.0

Il s'agit d'un changement important pour refléter le nouveau comportement des tunnels nommés

Le rôle doit gérer le nettoyage si vous avez utilisé le rôle avant la version 3.0.0. Cependant, vous devez mettre à jour la configuration (variables) dans votre projet Ansible. J'ai renommé les variables - elles sont généralement préfixées par cf_ afin de les rendre uniques au rôle. Si elles ne sont pas uniques, il peut arriver que des variables utilisant le même nom dans différents rôles aient des effets secondaires indésirables.

Cloudflared et connexion des applications aux tunnels

Selon 1, pour créer et gérer des Tunnels, vous devez d'abord :

1. Télécharger et installer cloudflared sur votre machine
2. Authentifier cloudflared

Une fois cloudflared installé et authentifié, le processus pour mettre votre premier Tunnel en fonction comprend 3 étapes principales :

3. Créer un Tunnel
4. Router le trafic vers votre Tunnel
5. Exécuter votre Tunnel

Les étapes 4-5 sont exécutées une fois par Tunnel, normalement par un administrateur, et l'étape 6 est exécutée chaque fois que le Tunnel doit être démarré, généralement par le propriétaire du Tunnel (qui peut être différent de l'administrateur).

Que fait le rôle ?

Le rôle a en réalité deux objectifs :

• Installation du démon côté serveur
• Configuration du client SSH

Installation du démon côté serveur

Le rôle s'occupe uniquement de configurer le service sur les nœuds, c'est-à-dire les étapes 1, 2, 4 et 5 ci-dessus, car

La création de tunnels et l'activation du routage sont des tâches qui doivent être effectuées par un administrateur et non par le rôle ¹

Vous pouvez configurer un ou plusieurs [tunnels nommés] ainsi qu'un [service unique] - cependant, avec les [tunnels nommés], vous n'avez généralement besoin que d'un seul démon. Le rôle exécute réellement ces étapes :

1. Télécharger et installer le binaire selon [les téléchargements]

2. Installer/configurer le démon - voir Authentifier le démon

3. Pour les [tunnels nommés], un [fichier de credentials] est créé sous {{ cf_credentials_dir }}/{{ tunnel_id }}.json semblable à ceci

   {"AccountTag":"{{ account_tag }}","TunnelSecret":"{{ tunnel_secret }}","TunnelID":"{{ tunnel_id }}","TunnelName":"{{ cf_tunnels.key }}"}
   

4. Pour chaque clé dans cf_tunnels, créez une configuration de tunnel dans /etc/cloudflare

   Le fichier est nommé {{ tunnel }}.yml et contiendra la configuration minimale comme suit :

   tunnels nommés

   tunnel: {{ cf_tunnels.key }}
   credentials-file: {{ cf_credentials_dir }}/{{ tunnel_id }}.json
   ingress:
     {{ item.value.ingress }}
   

   service unique

   hostname: {{ hostname }}
   url: {{ url }}
   

   Des paramètres supplémentaires sont configurés à l'aide des paramètres de configuration du tunnel

5. En fonction de votre système d'init - contrôlé par cf_init_system - le rôle effectue les actions suivantes :

   • Systemd

     Crée un [modèle d'unité systemd] cloudflared@{{ tunnel }}.service et démarre une instance pour chaque service dans la liste de cf_tunnels

     cloudflared tunnel --config {{ tunnel }}.yml
     

   • Systèmes Init-V

     1. Installez le service cloudflared dans /etc/init.d/{{ systemd_filename }}-{{ tunnel_name }}
     2. Lien du script d'arrêt vers /etc/init.d/{{ systemd_filename }}-{{ tunnel_name }}
     3. Lien du script de démarrage vers /etc/init.d/{{ systemd_filename }}-{{ tunnel_name }}

6. Si vous utilisez [tunnels nommés], le rôle créera également une [route dns].

Configuration du client SSH

Depuis lequel vous accédez à vos nœuds via ssh proxy par cloudflared, vous devez suivre le [guide ssh-client]. Vous devez ajouter ce qui suit

Host xxx.mycompany.com
  ProxyCommand /usr/bin/cloudflared access ssh --hostname %h

Vous pouvez réaliser cette configuration si vous activez cf_ssh_client_config. En plus, vous devez également spécifier cf_ssh_client_config_group. Supposons que votre inventaire ressemble à ceci :

all:
  children:
    servers:
      hosts:
        host001:
        host002:

Si vous spécifiez cf_ssh_client_config_group: servers, vous obtiendrez une entrée pour host001 et host002.

Exigences

aucune

Variables du rôle

Paramètres d'installation et de désinstallation

Les paramètres suivants contrôlent l'installation et/ou la désinstallation.

Paramètres de service Cloudflared

Ce sont des paramètres requis pour créer le service système.

Il est recommandé d'utiliser des [tunnels nommés] pour cf_tunnels qui nécessitent paramètres de tunnel nommé Cloudflare mais vous pouvez également utiliser des paramètres de tunnel hérités Cloudflare

Paramètres de tunnel nommé Cloudflare

  ...
    cf_tunnels:
      test:
        routes:
          dns:
            - "{{ inventory_hostname }}"
          cidr:
            - "192.168.42.0/24"
          lb:
            - hostname: website.mycompany.com
              poolname: bzh-west1.website.mycompany.com
        account_tag:  !vault....
        tunnel_secret: !vault....
        tunnel_id: !vault....
        ingress:
          - hostname: website.mycompany.com
            service: http://localhost:1313
          - hostname: hello.mycompany.com
            service: hello_world
          - hostname: ssh.mycompany.com
            service: ssh://localhost:22
          - service: http_status:404

La clé du tunnel doit correspondre à celle de tunnel_id.

Routes

DNS

Les routes dns s'attendent à une liste de CNAME à créer comme décrit ici. Si le CNAME existe déjà, la tâche sera ignorée mais aucune erreur ne sera lancée. N'ajoutez également que des CNAME, pas un FQDN, car le FQDN est déterminé par cloudflared.

Réseau Privé

Les routes réseau privé s'attendent à une liste de CIDR à créer comme décrit ici. Le playbook boucle sur la liste pour exécuter cloudflared tunnel route ip add {{ cf_cidr_entry }} {{ cf_tunnel.key }}. Si le CIDR existe déjà, une erreur sera lancée mais ignorée.

Équilibreur de Charge

Les routes lb s'attendent à une liste de balancers de charge cloudflared existants (ainsi que son pool) sur lequel router le tunnel comme décrit ici. Le playbook boucle sur la liste pour exécuter cloudflared tunnel route lb {{ cf_tunnel.key }} {{ cf_lb_entry.host_name }} {{ cf_lb_entry.pool_name }}. Si le tunnel est déjà lié au pool, une erreur ignorée sera lancée.

Paramètres de service unique Cloudflare

Comme avec les versions précédentes de ce rôle, vous pouvez utiliser le [style de configuration de service unique][service unique]

Si vous devez proxy le trafic vers un seul service local, vous pouvez le faire en utilisant le fichier de configuration. En alternative, vous pouvez configurer une configuration de service unique.

cf_tunnels:
  ssh:
    hostname: xxx
    url: ssh.mycompany.com

Paramètres de configuration du tunnel

Ceux-ci sont utilisés pour configurer les paramètres par service cloudflared. Vous pouvez toujours configurer des configuration par règle pour les tunnels nommés dans le cadre de l'ingress sous cf_tunnels.

Dépendances

aucune

Exemples de Playbooks

L'exemple suivant installe un service unique pour un tunnel ssh pour chaque serveur.

- hosts: servers
  vars:
    cf_systemd_user: root
    cf_systemd_group: root
    cf_cert_location: /home/papanito/cert.pem
    services:
      ssh:
        hostname: "{{ inventory_hostname }}.mycompany.com"
        url: ssh://localhost:22
  roles:
    - papanito.cloudflared

L'exemple suivant installe un [tunnel nommé] servers avec un ingress à {{ inventory_hostname }}.mycompany.com pour ssh et un hello world si vous accédez à hello-{{ inventory_hostname }}.mycompany.com via le navigateur.

- hosts: servers
  remote_user: ansible
  become: true
  vars:
    cf_cert_location: /home/papanito/.cloudflared/cert.mycompany.com.pem
    cf_tunnels:
      test:
        account_tag: !vault...
        tunnel_secret: !vault...
        tunnel_id: !vault...
        routes:
          dns:
          - "{{ inventory_hostname }}"
          - "hello-{{ inventory_hostname }}"
        ingress:
        - hostname: "hello-{{ inventory_hostname }}.mycompany.com"
          service: hello_world
        - hostname: "{{ inventory_hostname }}.mycompany.com"
          service: ssh://localhost:22
        - service: http_status:404
  roles:
    - papanito.cloudflared

L'exemple suivant télécharge simplement cloudflared sur votre machine locale et configure le fichier ssh-config :

- hosts: localhost
  remote_user: papanito #votre utilisateur local ayant des droits d'admin
  vars:
    cf_install_only: true
    cf_ssh_client_config: true
    cf_ssh_client_config_group: servers
  roles:
    - papanito.cloudflared

Test

ansible-playbook tests/test.yml -i tests/inventory

Informations Supplémentaires

Authentifier le démon

Selon [authentifier-le-démon-cloudflare], lors de l'authentification du démon, une fenêtre de navigateur s'ouvre ou - si cela n'est pas possible - il faut mettre le lien manuellement. Pendant ce temps, le démon attend. Je n'ai pas trouvé de solution pour automatiser ce comportement, alors j'ai mis en place l'implémentation suivante.

• Si rien n'est spécifié, Ansible appelle cloudflared login et continuera lorsque l'authentification sera terminée - cela a du sens si vous utilisez le rôle pour installer le démon localement sur votre machine où vous avez une fenêtre de navigateur.

• Si cf_cert_location est défini, le certificat est effectivement copié depuis cf_cert_location, ou si cf_cert_content est défini alors le certificat est créé directement à partir de la valeur stockée. Vous pourriez donc vous connecter une fois à Cloudflare depuis votre nœud maître (où vous exécutez Ansible) ou d'un emplacement distant.

  Vous pouvez chiffrer cert.pem avec ansible vault et le stocker quelque part en sécurité.

Références :

• [téléchargements] - instructions de téléchargement de cloudflared
• [guide-ssh] - connexions ssh avec cloudflared
• cli-args - arguments de ligne de commande
• config - Le format du fichier de configuration utilise la syntaxe YAML

Licence

C'est un logiciel libre, publié sous les termes de la licence Apache v2.

Informations sur l'auteur

Écrit par Papanito - Gitlab / Github