Rola Ansible "papanito.cloudflared"

Ta rola Ansible pobiera i instaluje cloudflared na hoście i opcjonalnie instaluje [argo-tunel] jako usługę.

Zmiany przełamujące z wersji 3.0.0

To jest zmiana przełamująca, aby odzwierciedlić nowe zachowanie nazwanych tuneli

Rola powinna zająć się czyszczeniem, jeśli korzystałeś z roli przed wersją 3.0.0. Jednak musisz zaktualizować konfigurację (zmienne) w swoim projekcie Ansible. Zmieniłem nazwy zmiennych - zazwyczaj z prefiksem cf_, aby były unikalne dla roli. Jeśli nie są unikalne, może zdarzyć się, że zmienne o tej samej nazwie w różnych rolach mogą prowadzić do niepożądanych skutków ubocznych.

Cloudflared i łączenie aplikacji z tunelami

Zgodnie z 1, aby utworzyć i zarządzać tunelami, musisz najpierw:

1. Pobierz i zainstaluj cloudflared na swoim komputerze
2. Uwierzodfnij cloudflared

Po zainstalowaniu i uwierzytelnieniu cloudflared, proces uruchomienia pierwszego tunelu obejmuje 3 główne kroki:

3. Utwórz tunel
4. Kieruj ruch do swojego tunelu
5. Uruchom swój tunel

Kroki 4-5 są wykonywane raz na tunel, zazwyczaj przez administratora, a krok 6 jest wykonywany za każdym razem, gdy tunel ma być uruchomiony, zazwyczaj przez właściciela tunelu (który może być inny niż administrator).

Co robi ta rola?

Rola ma dwa cele:

• Instalacja demona po stronie serwera
• Konfiguracja klienta SSH

Instalacja demona po stronie serwera

Rola zajmuje się jedynie konfiguracją usługi na węzłach, tzn. krokami 1, 2, 4 i 5 powyżej, ponieważ

Tworzenie tuneli i włączanie routingu to zadanie, które powinno być wykonywane przez administratora, a nie rolę ¹

Można skonfigurować od jednego do wielu [nazwanych tuneli] oraz [jednostkowej usługi] - z tym, że przy [nazwanych tunelach] zwykle potrzebny jest tylko jeden demon. Rola wykonuje następujące kroki:

1. Pobiera i instaluje binarkę zgodnie z [pobieraniem]

2. Instaluje/konfiguruje demona - patrz Uwierzytelniaj demona

3. Dla [nazwanych tuneli] tworzony jest [plik uwierzytelniający] w {{ cf_credentials_dir }}/{{ tunnel_id }}.json, podobny do tego

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

4. Dla każdego klucza w cf_tunnels tworzona jest konfiguracja tunelu w /etc/cloudflare

   Plik nazywa się {{ tunnel }}.yml i zawiera minimalną konfigurację, która wygląda następująco

   nazwane tunel

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

   jednostkowa usługa

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

   Dodatkowe parametry są konfigurowane za pomocą parametrów konfiguracji tunelu

5. W zależności od Twojego systemu inicjacji - kontrolowanego przez cf_init_system - rola wykonuje następujące czynności

   • Systemd

     Tworzy [szablon jednostki systemd] cloudflared@{{ tunnel }}.service i uruchamia instancję dla każdej usługi z listy cf_tunnels

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

   • Systemy Init-V

     1. Instalacja usługi cloudflared w /etc/init.d/{{ systemd_filename }}-{{ tunnel_name }}
     2. Link do skryptu zatrzymania w /etc/init.d/{{ systemd_filename }}-{{ tunnel_name }}
     3. Link do skryptu uruchamiania w /etc/init.d/{{ systemd_filename }}-{{ tunnel_name }}

6. Jeśli używasz [nazwanych tuneli], rola utworzy również [trasę DNS].

Konfiguracja klienta SSH

Skąd uzyskujesz dostęp do swoich węzłów przez ssh, który jest przesyłany przez cloudflared, musisz postępować zgodnie z [przewodnikiem ssh-klienta]. Musisz dodać następujące

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

Możesz osiągnąć tę konfigurację, jeśli włączysz cf_ssh_client_config. Dodatkowo musisz również określić cf_ssh_client_config_group. Załóżmy, że twoja inwentarz wygląda następująco:

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

Jeśli określisz cf_ssh_client_config_group: servers, otrzymasz wpis dla host001 i host002.

Wymagania

brak

Zmienne roli

Parametry instalacji i deinstalacji

Poniższe parametry kontrolują instalację i/lub deinstalację

Parametry usługi Cloudflared

To są parametry wymagane do utworzenia usługi systemowej

Zaleca się używanie [nazwanych tuneli] dla cf_tunnels, które wymagają parametrów nazwanych tuneli Cloudflare, ale można również użyć parametrów historycznych tuneli Cloudflare

Parametry nazwanych tuneli 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

Klucz tunelu powinien odpowiadać tunnel_id.

Trasy

DNS

Trasy dns oczekują listy CNAME, które mają być utworzone, jak opisano tutaj. Jeśli CNAME już istnieje, zadanie zostanie pominięte, ale żaden błąd nie zostanie zgłoszony. Dodawaj tylko CNAME, a nie FQDN, ponieważ FQDN ustala się przez cloudlfared.

Sieć prywatna

Trasy private network oczekują listy CIDR, które mają być utworzone, jak opisano tutaj. Playbook wykonuje pętlę po liście, aby wykonać cloudflared tunnel route ip add {{ cf_cidr_entry }} {{ cf_tunnel.key }}. Jeśli CIDR już istnieje, zgłoszony zostanie błąd, który zostanie zignorowany.

Równoważnik obciążenia

Trasy lb oczekują listy istniejących równoważników obciążenia cloudflared (plus jego pul) do routingu tunelowego, jak opisano tutaj. Playbook wykonuje pętlę po liście, aby wykonać cloudflared tunnel route lb {{ cf_tunnel.key }} {{ cf_lb_entry.host_name }} {{ cf_lb_entry.pool_name }}. Jeśli tunel jest już powiązany z pulą, zgłoszony zostanie błąd, który zostanie zignorowany.

Parametry jednostkowej usługi Cloudflare

Jak w poprzednich wersjach tych ról, można używać konfiguracji jednostkowej usługi

Jeśli musisz przesyłać ruch tylko do jednej lokalnej usługi, możesz to zrobić za pomocą pliku konfiguracyjnego. Alternatywnie możesz skonfigurować konfigurację jednostkową

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

Parametry konfiguracji tunelu

Te służą do konfigurowania parametrów dla każdego serwisu cloudflared. Możesz nadal konfigurować Konfigurację per-regułę dla nazwanych tuneli jako część ingress pod cf_tunnels.

Zależności

brak

Przykładowe Playbooki

Poniższy przykład instaluje pojedynczą usługę dla tunelu ssh dla każdego serwera

- 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

Poniższy przykład instaluje [nazwa tunelu] servers z połączeniem do {{ inventory_hostname }}.mycompany.com dla ssh i hello world, jeśli uzyskasz dostęp do hello-{{ inventory_hostname }}.mycompany.com przez przeglądarkę

- 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

Poniższy przykład po prostu pobiera cloudflared na lokalny komputer i konfiguruje plik ssh-config:

- hosts: localhost
  remote_user: papanito # twój lokalny użytkownik, który ma uprawnienia administratora
  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

Dodatkowe informacje

Uwierzytelnianie demona

Zgodnie z authenticate-the-cloudflare-daemon podczas uwierzytelniania demona otwiera się okno przeglądarki lub - jeśli to nie jest możliwe - należy ręcznie umieścić link. W tym czasie demon czeka. Nie mogłem wymyślić rozwiązania, jak zautomatyzować to zachowanie, więc wpadłem na poniższą implementację.

• jeśli nic nie jest określone, wtedy ansible wywołuje cloudflared login i będzie kontynuowane, gdy uwierzytelnienie zostanie zakończone - ma to sens, jeśli używasz roli do zainstalowania demona lokalnie na komputerze, gdzie masz okno przeglądarki

• jeśli cf_cert_location, certyfikat jest faktycznie kopiowany z cf_cert_location, lub jeśli cf_cert_content jest określony, wtedy certyfikat zostaje utworzony bezpośrednio z wartości, którą tam przechowano. Więc mógłbyś zalogować się raz do cloudflare z węzła macierzystego (gdzie uruchamiasz ansible) lub z lokalizacji zdalnej.

  Można zaszyfrować cert.pem za pomocą ansible vault i przechować go gdzie indziej.

Odniesienia:

• [pobierania] - instrukcje dotyczące pobierania cloudflared
• [przewodnik SSH] - połączenia SSH z cloudflared
• [argumenty CLI] - argumenty wiersza poleceń
• [konfiguracja] - Format pliku konfiguracyjnego używa składni YAML

Licencja

To jest oprogramowanie wolne, wydane na podstawie warunków licencji Apache v2.

Informacje o autorze

Napisane przez Papanito - Gitlab / Github