Fórum Root.cz
Hlavní témata => Server => Téma založeno: czechsys 11. 09. 2019, 10:08:35
-
Ahoj,
mam naimplementovanou distribuci certifikatu pro TLS sluzby. Jenze mam problem, jak tohle udelat v pripade letsencrypt automaticky. Kdybych mel puppet, tak by si z hlediska klienta sam overoval, zda ma shodne soubory jako na cetralnim node, ale jak tohle udelat v ansible? Rad bych se vyhnul vsemoznym cron/syncthing apod metodam nastavenych primo na danych serverech. Metoda by byla dns-01 (http-01 je nepouzitelna v tomhle rozsahu). Jenze to, jake certifikaty ktera sluzba potrebuje, mam defaultne definovane v ramci group_vars/project, ale ne v ramci host_vars/fqdn, coz to dela slozitejsi.
Jake je rozmne reseni? Uzuz jsem rozhodnut pro zakoupeni potrebneho wildcard certfikatu, ktery pokryje problem vyse, ale to vyresi jen danou (sub)domenu.
Diky.
-
s ansible uz par rokov nerobim, takze bohuzial ti neporadim. ale tie nervy s LE poznam a preto som presiel na CloudFlare kde mas 10 rocny wildcart certifikat zdarma nemusis riesit tieto LE hovadiny s certifikatmi ktorych zivotnost je naprosto smiesna.
-
Rad bych se vyhnul vsemoznym cron/syncthing apod metodam nastavenych primo na danych serverech.
Pokud se vyhneš nejjednodušší a nejpřímočařejší cestě, zbudou ti jenom horší, zbytečně komplikovaná řešení.
A vůbec nejjednodušší cesta je terminovat TLS na jednom stroji. Ale to asi víš.
-
Rad bych se vyhnul vsemoznym cron/syncthing apod metodam nastavenych primo na danych serverech.
Pokud se vyhneš nejjednodušší a nejpřímočařejší cestě, zbudou ti jenom horší, zbytečně komplikovaná řešení.
A vůbec nejjednodušší cesta je terminovat TLS na jednom stroji. Ale to asi víš.
Jo, pokud to bezi na jednom stroji, tak to je brnkacka. Ale nam uz vice veci bezi v HA, takze treba ty certifikaty pro tu samou domenu potrebuji na vice strojich najednou...A to uz ta brnkacka neni.
-
Ale nam uz vice veci bezi v HA, takze treba ty certifikaty pro tu samou domenu potrebuji na vice strojich najednou...A to uz ta brnkacka neni.
Tak je to otázka jednoho účtu a jednoho řádku v crotabu :)
Pokud tím HA myslíš master-master a zároveň nechceš nic řešit při výpadku ručně, tak to brnkačka není. Ale pokud fakt máte tenhle setup, tak máte určitě bambilion daleko složitějších problémů než tenhle :)
-
Já asi nerozumím, jak to souvisí s Ansible – to chcete periodicky spouštět Ansible? Pokud ano, přijde mi to jako ohýbání Ansiblu…
-
Ten popis problemu je docela zmateny, ptas se jak distribuovat LE certifikaty na jine servery?
- name: Copy certificates
hosts: "{{hosts['ssl-enabled-host.tld']}}"
tasks:
synchronize:
src: "{{ item }}"
dest: "{{ item }}"
mode: pull
delegate_to: "{{hosts['certbot.tld']}"
with_items:
- "/etc/ssl/lets_cert.crt"
Ber to s rezervou, psal jsem to z hlavy.
-
Ber to s rezervou, psal jsem to z hlavy.
Musí se to ale dělat pravidelně a automaticky - po každém obnovení certifikátu. Ne ručně ansiblem...
-
My to resime cronem a ansiblem, ktery proste synchronizuje centralni ulozni misto s klientama. Pouzivame dehydrated pro plneni challengu, coz je ciste bashovska implementace certbota. (tady me trochu znejistila otazka vyse). Puvodne jsme to delali z centralniho nodu, ale ted se nam velmi osvedcilo dynamicke pridavani DNS TXT zaznamu. A do budoucna planujeme generovat DNS klic pro kazdej stroj a budou si to delat cele samy.
-
Já asi nerozumím, jak to souvisí s Ansible – to chcete periodicky spouštět Ansible? Pokud ano, přijde mi to jako ohýbání Ansiblu…
Co je na tom k ohybani? Pokud si rekneme, ze pravidelne spousteny certbot/dehydrated aktualizuje certifikaty, tak na zaklade toho se muze spustit reconfig pomoci ansible (klasicky CI postup).
Problem se odviji zhruba od tohoto:
1] ansible potrebuje mit pristup k aktualnim crt pripadne inicializovat vytvoreni i pro konfiguraci
2] je potreba deploy na ruzne typy serveru, ktere jsou redundantni (napr. haproxy, web servery atd), nemluve o pripadny kontejnerech - ruzny format certifikatu
3] neni centralni seznam domen a serveru. Kazdy projekt ma v group_vars/project_name ulozene domeny. Mohl bych to ukladat do host_vars/fqdn, coz by resilo chybejici centralni seznam, ale zase bych duplikoval veskere parametry mezi vice konfigy(co je mensi zlo..., resp. co je asi tak optimal zpusob ukladani seznamu kombinace domena/server)
4] neni mozne spoustet certbot primo ze serveru - viz 1] a 2]
-
My to resime cronem a ansiblem, ktery proste synchronizuje centralni ulozni misto s klientama. Pouzivame dehydrated pro plneni challengu, coz je ciste bashovska implementace certbota. (tady me trochu znejistila otazka vyse). Puvodne jsme to delali z centralniho nodu, ale ted se nam velmi osvedcilo dynamicke pridavani DNS TXT zaznamu. A do budoucna planujeme generovat DNS klic pro kazdej stroj a budou si to delat cele samy.
Zhruba takhle to vidim. Ale prave ten deployment...jak resite vazbu vztah certifikat/typ sluzby/konkretni server?
-
na zaklade toho se muze spustit reconfig pomoci ansible (klasicky CI postup).
Spis CD, ale to je jedno.
Jsi si jisty, ze automaticke spousteni Ansiblu v ostrem modu je to, co chces? Ma to minimalne dva problemy:
1. jakakoli chyba v konfiguraci se automaticky promitne na servery (je potreba kontrolovat, co zmena zpusobi, bokem)
2. server s ansiblem musi mit permanentne k dispozici root pristup na vsechny konfigurovane servery - jeho kompromitace znamena kompromitaci vseho
Slo by samozrejme omezit scope pomoci tagu, ale pak by ansible efektivne delal to, co by delal ten rsync, a moc nevidim duvod jeho pouziti.
-
inak nebude pre teba lepsie pouzit skor etcd+confd namiesto ansiblu?
-
My to resime cronem a ansiblem, ktery proste synchronizuje centralni ulozni misto s klientama. Pouzivame dehydrated pro plneni challengu, coz je ciste bashovska implementace certbota. (tady me trochu znejistila otazka vyse). Puvodne jsme to delali z centralniho nodu, ale ted se nam velmi osvedcilo dynamicke pridavani DNS TXT zaznamu. A do budoucna planujeme generovat DNS klic pro kazdej stroj a budou si to delat cele samy.
Zhruba takhle to vidim. Ale prave ten deployment...jak resite vazbu vztah certifikat/typ sluzby/konkretni server?
Uplne nevim jestli odpovim presne, protoze jsem asi nepochopil otazku... Mam proste yaml soubor co rika:
1) jaka domena
2) jake aliasy
3) kam se ma certifikat na cili nahrat a s jakymi opravneni
+ jsem dobastlil skript, co vyrobi i mene tradicni formaty, jako .pks a ty javovsky hruzy.
Nejsem si jistej, ze je to ale dobrej zpusob, ale funguje nam to ::) Psal jsem to na zacatku sveho pocinani na soucasnem pracovisti s malou zkusenosti s ansiblem.
-
K tem wildcard certifikatum ... je to zlo. Stejna vec plati pro naduzivani jednoho keypairu obecne. Pokud je moznost, nedelal bych to.
Krome pohodli je nutny taky myslet na to, co se stane, pokud klic leakne, a co se stane mezi tim a momentem nez na to prijdete a napravite.
Cim na vic je na serverech jeden keypair, nebo nedejboze wildcard cert, tim zranitelnejsi celou infra mate a tim vic adidas to je.
Nekdy to nejde jinak. Ale na to, jestli to je ta Vase situace si odpovite urcite sam.
-K-
-
+ bych dodal, že v některých případech jsou nepoužitelné. V poslední době jsem narazil na případy, kdy se natvrdo ověrovalo, jestli je FQDN v SAN certifikátu (tzn. aaa.root.cz != *.root.cz -> FAIL) - konkrétně jdk8 od nějaké verze, supplicanty pro radius