Dies ist eine alte Version des Dokuments!


Ansible - erweiterte Konfigurationsbeispiele: Ansible-Controll-Node und SSH-Jumphosts

Bild: Ansible Logo

In verteilten und getrennten Netz(werk)umgebungen ist es sehr oft nicht ohne Aufwand möglich zu Administrations- und Orchestrierungsaufgaben alle Hosts zu erreichen.

Schauen wir uns hierzu einfach mal nachstehende exemplarische Skizze an.


state Firewall_A {
Firewall_A : -----------
Firewall_A : A-Firewall
Firewall_A : -----------
}

state Internet {
state fremdgehostetes_System
fremdgehostetes_System : Host beim Housing-Provider
fremdgehostetes_System : Hostname
fremdgehostetes_System : IP-Adresse: aa-bb-cc-dd
}

state DMZ {
state bredmz {
bredmz : EDMZ-Netzwerkswitch (bredmz)
bredmz : Netz:10.0.0.0/24
}
state bridmz {
bridmz : EDMZ-Netzwerkswitch (bridmz)
bridmz : Netz:10.10.0.0/24
}
state edmz_switch {
edmz_switch : EDMZ-Switch
edmz_switch : Netgear Typ: x
}


state FWB {
FWB : FQDN: vml000010.dmz.nausch.org
FWB : ------------------------------------
FWB : Services: iptables
}
state FWC {
FWC : FQDN: vml000020.dmz.nausch.org
FWC : ------------------------------------
FWC : Services: iptables
}

state DMZ_HOSTs {
state IDMZ_Repository_Host {
IDMZ_Repository_Host : FQDN: vml000050.dmz.nausch.org
IDMZ_Repository_Host : CNAME : syslog, tftp, install
IDMZ_Repository_Host : IP (IDMZ) : eth0 - 52:54:00:19:08:67 - 10.0.0.50
IDMZ_Repository_Host : Services : syslog, httpd, rpm-repository, tftp/pxe
}
state EDMZ_Repository_Host {
EDMZ_Repository_Host : FQDN: vml100080.dmz.nausch.org
EDMZ_Repository_Host : CNAME : mail
EDMZ_Repository_Host : IP (EDMZ) : eth0 - 52:54:00:14:12:71 - 10.0.0.50
EDMZ_Repository_Host : Services : syslog, httpd, rpm-repository, tftp/pxe
}
}
}


state Intranet {
state Switch {
Switch : Physikalischer Netzwerk-Switch
Switch : Netz 10.10.10.0/26
}
state Workstation {
Workstation : Gerät: Djangos Admin-Workstation
Workstation : Hostname: pml010040
Workstation : CNAME: office-work
Workstation : MAC:
Workstation : IP:10.10.10.40
}
}

FWB -down-> edmz_switch

bredmz -down-> FWB
FWC -up-> bredmz
FWC -up-> bridmz
bredmz -up-> EDMZ_Repository_Host

bridmz -up-> IDMZ_Repository_Host

Switch -up-> FWC

Workstation -up-> Switch

edmz_switch --> Firewall_A
Firewall_A -right-> fremdgehostetes_System

Von der Admin-Workstation bzw. dem Ansible-Controll-Node aus, wollen wir nun nicht nur zum nächstgelegenen Host erreichen, sondern auch zum übernächsten oder gar zu einem Host im Internet, den wir aber aus Sicherheitsgründen nicht direkt erreichen dürfen und auch können.

Die Komfortabelste Variante ist nun die Nutzung der Option ProxyCommand. Bei „nur“ einem Jump-Host kann man dies im Inventory noch recht bequem und einfach abbilden. Weitaus schwieriger wird die Sache, bei Umgebungen, bei denen mehrere Jumphost beteiligt sind. Hier bietet es sich an, die SSH-Client Konfiguration des Ansible Control- bzw Admin-Users zu verwenden!

Weitaus einfacher gestaltet sich o.g. Szenario in dem man auf die SSH-Clientkonfigurationsdatei ~/.ssh/config zurückgreift. Nachfolgendes Beispiel zeigt exemplarisch solch eine Clientspezifische Konfigurationsdatei:

 $ vim ~/.ssh/config
~/.ssh/config
# Default Werte
Host * 
    Port 22
    Protocol 2
    user admin
 
# Django : 2012-06-13
# ssh-jumps über mehrere Sprunghosts
 
# Erster Sprunghost (fwc) - direkt erreichbar
# Host -->  fwc
Host fwc
    Hostname firewall-c.idmz.nausch.org
    IdentityFile ~/.ssh/id_ed25519_idmz 
 
# Zweiter Sprunghost (fwb) - nur über fwc erreichbar
# Host -->  fwc --> fwb
Host fwb
    Hostname firewall-b.edmz.nausch.org
    IdentityFile ~/.ssh/id_ed25519_edmz
    ProxyCommand  ssh -A -q -W %h:%p fwc
 
# Dritter Sprunghost (fwa) - nur über fwb erreichbar
# Host --> fwc --> fwb --> fwa 
Host fwa
    Hostname firewall-a.nausch.org
    Port 22222
    user sysadmin
    IdentityFile ~/.ssh/id_ed25519_edmz
    ProxyCommand  ssh -A -q -W %h:%p fwc
 
# externer Server im Internet nur über externe Firewall "A" erreichbar
# also: Host --> fwc --> fwb --> fwa --> daxie
Host s1u7
    Hostname <was-das-auch-immer-für-ein geiler-FQDN-sein-mag>
    Port 42422
    user n3rd
    IdentityFile ~/.ssh/id_ed25519_n3rd
    ProxyCommand  ssh -A -q -W %h:%p fwa

Nun können wir ganz einfach direkt einen Tunnel zu unserem Zielhost aufspannen, genauso also würden wir den Zielhost direkt „sehen“.

 $ ssh fwa

Auch können wir nun ohne grossen Aufwand Dateien von einem Ende zum anderen Ende kopieren bzw. Ansible dies ermöglichen.

 $ scp ~/Downloads/enigmail-1.4-sm+tb.xpi 51u7:/tmp/
 $ scp 51u7:/home/8483/51lv14/04x.png .

Somit ist natürlich auch Ansible in der Lage die definierten Zielhost aus dem Inventory ohne Probleme zu erreichen, da hier die SSH-Client-Konfiguration unseres Admin-Accounts auf unserem Ansible-Controll-Node verwendet wird.

Die Pflege der Konfigurationsdatei ~/.ssh/config überlassen wir nun natürlich nicht jedem Admin einzeln, da dies viel zu fehleranfällig bzw. zeitaufwändig wäre.

Die aktuelle SSH-Clientconfigurationsdatei auf Djangos-Ansible-Controll-Node hat immerhin eine stattliche Anzahl an Konfigurationszeilen, Bsp.:

 $ cat ~/.ssh/config | wc -l
1860

Das will sicherlich niemand, auch wenn er noch so fleissig und gewissenhaft ist, per Hand erledigen! 8-)

Wir werden dies mit den Informationen aus dem zentral gepflegten Inventory und einem Ansible-Playbook bewerkstelligen. Somit ist sichergestellt, dass auf jedem Ansible-Controll-Node und jedem Admin die betreffende Datei zur Verfügung steht und somit die Ansible- Playbooks auch überall unter den gleichen (Labor-)Bedingungen laufen können!

:KRIT: FIXME :KRIT:

Diese Website verwendet Cookies. Durch die Nutzung der Website stimmen Sie dem Speichern von Cookies auf Ihrem Computer zu. Außerdem bestätigen Sie, dass Sie unsere Datenschutzbestimmungen gelesen und verstanden haben. Wenn Sie nicht einverstanden sind, verlassen Sie die Website.Weitere Information
  • linux/ansible/playbook_example_10.1663940263.txt.gz
  • Zuletzt geändert: 23.09.2022 13:37.
  • von django