\"/
\"/ \"/    

Infrastruktura META Centra

Miroslav Ruda, Aleš Křenek, Luděk Matyska, FI MU, ÚVT MU
Ročník X - číslo 2, prosinec 1999
Citace: M. Ruda, A. Křenek, L. Matyska. Infrastruktura META Centra. Zpravodaj ÚVT MU. ISSN 1212-0901, 1999, roč. X, č. 2, s. 9-14.
Tematické zařazení: Superpočítače a gridy
 předchozí článek | následující článek 

V České republice jsou nejvýkonnější počítače v akademické sféře rozmístěny na centrálních pracovištích pěti velkých univerzit - Karlovy univerzity a Českého vysokého učení technického v Praze, Západočeské univerzity v Plzni, Vysokého učení technického a Masarykovy univerzity v Brně - a v Českém hydrometeorologickém ústavu v Praze. Uvažujeme-li pouze techniku instalovanou na vysokých školách, pak k dispozici je na 72 procesorů MIPS R10000/195MHz, 54 procesorů IBM Power (v tom 16 nejvýkonnějších procesorů Power3) a 16 procesorů Alpha (z toho 8 nejnovějších typů na 525MHz). Teoretickým výkonem to odpovídá cca 512 procesorovému superpočítači Cray T3E, praktické využití v agregované podobě je však velmi obtížné. Všechny odpovídající počítače jsou vzájemně dostupné prostřednictvím vysokorychlostních lokálních, metropolitních i národní počítačové sítě, přitom kapacitně "nejslabší" propojení v současné době představuje spojení Praha-Plzeň s kapacitou "pouze" 34Mb/s.

Projekt META Centrum, sdružující všech 5 výše uvedených škol, vznikl v roce 1996 a od roku 1999 je součástí výzkumného záměru sdružení CESNET, kdy na jeho realizaci pracují zejména lidé ze ZČU, UK a MU. Hlavním cílem tohoto projektu je vytvoření virtuálního distribuovaného META Počítače a odpovídajícího podpůrného prostředí. To by mělo přispět jak k podstatně efektivnějšímu využití instalované techniky, tak i k možnosti využít výše uvedené výpočetní zdroje pro řešení i velmi náročných výpočetních úloh, jejichž zvládnutí je nad možnosti kteréhokoliv samostatného pracoviště v ČR.

Podstatnou součástí realizace projektu je vytvoření vhodné infrastruktury, tj. prostředí, které uživatelům umožní bezproblémový přístup k jednotlivým počítačům i jejich shlukům a současně zajistí snadnou a přitom bezpečnou správu na všech úrovních. Cílem tohoto článku je proto seznámit s řešením bezpečné autentizace (tj. ověření totožnosti) v prostředí META Centra pomocí systému Kerberos 5 a současně představit vyvinutý nástroj na efektivní správu výpočetních zdrojů - systém Perun. Oba systémy přitom mohou být v principu pro podobné účely použity i mimo vlastní META Centrum.

1  Kerberos

1.1  Historie

Kerberos je síťový protokol pro ověření totožnosti (autentizaci) v prostředí s nezabezpečenou sítí. Vznikl v polovině 80. let na Massachusetts Institute of Technology v rámci projektu Athena. Cílem bylo zajistit spolehlivou autentizaci, kdy všechny citlivé údaje budou uloženy na jednom bezpečném místě a nikdy se nevyskytnou na síti nechráněně.

První veřejně dostupná verze 4 byla uvolněna v roce 1988 [SNS88]. Přestože byl Kerberos navržen pro specifické prostředí MIT, prosadil se i do jiných organizací. V roce 1991 byla vydána specifikace verze 5 [KN93]. V této verzi byly jednak vyřešeny některé slabiny [BM91] předchozích verzí a jednak do ní byla zapracována rozšíření, která umožňují snazší použití systému Kerberos i v jiných prostředích, než bylo na MIT. Verze 5 byla rozšířena o podporu dalších kryptografických algoritmů pro šifrování a ověření integrity, pre-autentizaci založenou na základě časových razítek nebo speciálních hardwarových zařízení generujících klíč, podporu dalších síťových protokolů, jednotné kódování zpráv podle syntaxe ASN.1, možnost přenášení a prodlužování lístků a snazší správu důvěry mezi administrovanými doménami. Standard je zároveň poměrně obecný a otevřený a umožňuje dodefinovat další mechanismy (jako je např. použití asymetrické kryptografie).

Využití systému Kerberos mimo území USA je však zproblematizováno vývozními omezeními USA na šifrovací technologie. Kerberos 4 byl proto z USA vyvezen ve formě zdrojových textů, ze kterých byly odstraněny veškeré kryptografické funkce, včetně jejich volání (tzv. forma Bones). Mimo území USA byly do tohoto balíku zařazeny opět všechny potřebné funkce pro šifrování. Takto vytvořená verze (nazývaná eBones) se stala základem většiny dalších distribucí verze 4. Verze 5 takto vyvezena nebyla a evropská verze je vyvíjena zcela znovu, v rámci projektu Heimdal na Královském technologickém institutu ve Stockholmu - Kungliga Tekniska Högskolan (KTH), pouze se snahou o co největší kompatibilitu se standardem a implementací z MIT.

1.2  Základní mechanismus

Kerberos je systém s tzv. třetí důvěryhodnou stranou. Tato důvěryhodná služba - autentizační server (AS) ověřuje totožnost jednotlivých uživatelů a vydává jim tzv. lístky pro jednotlivé služby. Kerberos používá symetrickou kryptografii, tj. každý uživatel má jedno heslo, které zná i Kerberos, a tímto heslem se prokazuje. Protokol je navržen tak, aby se heslo uživatele nikdy neposílalo po síti.

Lístek je navržen tak, aby byl použitelný pouze pro uživatele, který o něj požádal, a pro službu, pro niž byl určen. Server poskytující službu může po předložení lístku ověřit totožnost uživatele a na jejím základě rozhodnout o poskytnutí či neposkytnutí služby. Uživatel i server jsou schopni si ověřit identitu druhé strany a jsou schopni veškerou komunikaci šifrovat (ve verzi 5 se používá algoritmus Triple-DES) a mít ověřenu integritu této komunikace.

Základní princip komunikace je zobrazen na obrázku. Klient c žádá o lístek pro službu s. AS vrátí klientovi klíč pro komunikaci se serverem (Kc,s) zašifrovaný heslem uživatele (Kc) a lístek (Tc,s) pro službu s zašifrovaný heslem služby (Ks). Lístek obsahující mimo jiné klíč pro komunikaci klienta se serverem (Kc,s) umí dešifrovat pouze služba s. Tento lístek pak klient posílá vedle své žádosti o službu (c,s) serveru.

Princip protokolu Kerberos

1. Klient c -- > AS: idc , ids
2. AS -- > Klient: {Kc,s} Kc , {Tc,s} Ks
3. Klient -- > Server: {c,s} Kc,s , {Tc,s} Ks

Obrázek 1: Princip protokolu Kerberos

Systém je centrálně spravován, v jediné databázi jsou spravovávána hesla všech uživatelů a služeb. Na Kerbera se s žádostí o ověření hesla obracejí všechny služby, které normálně heslo ověřují - vzdálené přihlášení přes telnet, rsh, ssh, lokální přihlášení pomocí programů login, xdm, protokol ftp, servery pro protokoly elektronické pošty POP a IMAP, WWW servery a další. Centrální správa uživatelů výrazně usnadňuje a urychluje správu účtů. Z důvodu lepší dostupnosti této služby poskytuje Kerberos mechanismus pro replikaci serverů. Udržení konzistence jednotlivých databází hesel je plně v režii Kerbera. Systém umožňuje rozdělit administrovanou organizaci na několik částí, tzv. realmů (spravovaných různými lokálními správci) a definovat vztahy důvěry mezi těmito částmi.

Správa systému Kerberos vyžaduje od správců systému hlubší znalost zde popsaných mechanismů, ale podle našich zkušeností není po jistém "zkušebním období" o nic složitější než správa jiných systémů pro centrální správu účtů. Na druhou stranu centrální ovládání platnosti účtů a hesel pro celou doménu je velmi výhodné a výrazně usnadňuje administraci většího počtu strojů a uživatelů.

Vyčerpávající srovnání (zejména co do bezpečnosti a efektivity použitých kryptografických algoritmů) systému Kerberos s programy obdobného určení založenými na asymetrické kryptografii, zejména Secure Shell (ssh), by rozsahem přesahovalo možnosti tohoto článku. Systémy se liší zejména v prvotním určení - Kerberos je určen zejména k centrálně spravované autentizaci uživatelů (tj. ověření totožnosti). Autorizací (tj. ověřením práva přístupu) se sám o sobě nezabývá, jednotlivé služby ji na základě Kerberem ověřené identity implementují samy. Na druhé straně úlohou ssh je (kromě šifrování) především autorizace, za autentizovaného uživatele je považován každý, kdo má přístup k příslušnému soukromému klíči. Výhoda centrální správy hesel (resp. klíčů) v systému Kerberos se projeví zejména ve větších organizačních jednotkách, kde jsou, dle našeho názoru, nároky na údržbu centrální databáze klíčů vyváženy úsporou jinak nutného udržování konzistentních soukromých adresářů .ssh všech uživatelů. Oba systémy se přitom mohou vzájemně doplňovat. Standardní distribuce ssh je připravena pro autentizaci a přenášení lístků systému Kerberos, samotná autorizace a šifrování už probíhá standardními mechanismy ssh. V rámci META Centra používáme modifikovanou verzi ssh1, která lépe spolupracuje s implementací Heimdal a zejména vůči lístkům systému Kerberos a autentizaci do AFS se chová konzistentně s ostatními nástroji používanými v META Centru.

1.3  Kerberos v Meta Centru

V projektu Meta Centrum byla na počátku použita verze 4, ale stalo se tak zejména proto, že v té době neexistovala dostupná implementace verze 5. Potřeba nových vlastností verze 5, zejména hierarchické správy administrovaných subdomén a možnosti přenášení a prodlužování lístků, spolu s rostoucí podporou protokolu verze 5 i v dalších programech nás v tomto roce přiměla k přechodu na verzi 5. Přestože je implementace Heimdal [DW98] poměrně nová, v současné době stále ještě ve vývoji a zejména na začátku nebyla dostatečně stabilní, rozhodli jsme se pro její použití. Její výhodou je vedle evropského "původu" její velmi dobrá spolupráce s původní (a námi používanou) verzí 4. Dalším kladem je také ochota švédských autorů ke spolupráci - celá řada námi navržených rozšíření a úprav se stala součástí nových verzí Heimdalu.

Vedle všech programů používajících už protokol verze 4 (telnet, rsh, login, ftp, AFS) jsme zprovoznili nebo modifikovali řadu programů navržených pro MIT implementaci protokolu verze 5 - vzdálené přihlašování pomocí programu ssh, autentizaci pomocí systému Kerberos v databázi Oracle, autentizaci ve WWW serveru Apache, autentizaci pomocí systému Kerberos v protokolu SSL, nástroj pro řízenou výměnu kerberovských lístků (NCSA krb525 démon) a další. Další námi navržené programy (např. program Perun) již používají pro autentizaci Heimdal.

V současné době používáme autentizaci pomocí protokolu Kerberos 5 pro veškeré přihlašování na stroje META Centra (protokoly telnet, rsh, ssh, ftp, xdm) a pro autentizaci do souborového systému AFS. Dávkové systémy LSF a NQE prodlužují kerberovské lístky po celou dobu běhu úloh spuštěných přes tyto systémy. Kerberovská autentizace je využita i pro zpřístupnění dokumentace v HTML formátu přes WWW server Brněnského superpočítačového centra. Na konci tohoto roku plánujeme znemožnění jiné autentizační metody pro všechny služby META Centra. Současný stav je popsán na WWW stránkách Brněnského superpočítačového centra.

Plnohodnotné klienty protokolu Kerberos 5 máme implementovány pro námi používané unixové platformy (Irix, Solaris, Digital Unix, Linux, NetBSD) a pro Windows NT. Klienty pro získaní kerberovského lístku (kinit) a pro přihlášení (telnet) je možné použít i na strojích mimo META Centrum. Návod a potřebné programy lze najít na WWW stránce ( http://www.ics.muni.cz/scb/popisy/travelkit.html).

2  Perun

2.1  Motivace

S přibývajícím počtem serverů a pracovních stanic i programového vybavení a komplikujícími se vztahy oprávněného přístupu uživatelů k těmto prostředkům vznikla v Brněnském superpočítačovém centru nutnost jejich striktně centralizované správy.

Výchozí požadavky na systém realizující centralizovanou správu lze shrnout do následujících bodů:

V první etapě jsme uvažovali o použití a případných modifikacích systému Moira [RGL88] vyvinutého na MIT v rámci projektu Athena. Nakonec jsme však jeho nasazení z několika důvodů odmítli. Návrh tohoto systému nepředpokládá využití technologií, které nabízejí současné komerční relační databáze (deklarativní integritní omezení, databázové triggery, signalizace událostí), což se odráží v implementaci integritních omezení poměrně těžkopádným procedurálním rozhraním. Systém také neumožňuje okamžitou propagaci změn. Tyto a další důvody vedly k rozhodnutí implementovat pro správu výpočetních prostředků zcela nový systém.

2.2  Architektura systému

Systém Perun2 je vyvíjen na ÚVT MU od roku 1996. V následujícím textu popíšeme jeho základní vlastnosti, zejména mechanismus propagace změn na řízené počítače.

Systém je postaven nad relační databází Oracle, současná produkční implementace nad verzí databáze 7.3, další vývoj už probíhá nad verzí 8.0.5. Protože systém využívá řady vyšších rysů této databáze, je jeho přenositelnost na jiný databázový systém problematická, i když pravděpodobně ne zcela vyloučena.

2.3  Datové schéma

Současné datové schéma obsahuje cca 50 tabulek. Jedním z hlavních cílů jeho návrhu bylo zajištění konzistence dat přímo na úrovni databáze, zejména použitím deklarativních integritních omezení. V případech, kde to kvůli omezeným možnostem relačního modelu není možné, je integrita dat vynucena databázovými triggery (procedura, která je spouštěna asynchronně na základě určité databázové události, např. vložení nebo smazání záznamu v tabulce, a jejíž úspěšné dokončení podmiňuje úspěch celé operace, která její vyvolání způsobila). Uživateli - správci je tak umožněn přístup k datům veškerými prostředky jazyka SQL, přitom je ale prakticky vyloučeno databázi modifikovat tak, aby obsahovala nekonzistentní data.

2.4  Služby

Ze systému Moira byla převzata koncepce tzv. služeb. Službou rozumíme jistou přesně definovanou, pokud možno minimální a nezávislou, konzistentní jednotku správy počítačových zdrojů. Např. služba PASSWD pokrývá soubory /etc/passwd (seznam uživatelů na konkrétním počítači) a /etc/shadow (jejich hesla a doba platnosti účtů). Je zřejmé, že nemá smysl tuto službu dále dělit a měnit každý z těchto souborů zvlášť. Obecně je samozřejmě specifikace každé služby výsledkem kompromisu, vzhledem ke značné provázanosti nelze téměř nikdy vyčlenit zcela nezávislou službu, na druhou stranu při zachování přijatelného rozsahu není třeba z důvodů efektivity dělit služby na příliš malé úseky.

2.5  Propagace změn

Provedení libovolné změny v databázi je okamžitě sadou triggerů vyhodnoceno na požadavek změny konkrétní služby na konkrétním počítači a tento požadavek je uložen do fronty. Po definitivním potvrzení (commit) transakce, která změnu vyvolala, je o vzniklých požadavcích vyrozuměn hlavní proces aplikace. Ten na základě logiky implementované už na klientské straně (tj. mimo vlastní databázi) požadavky vyhodnocuje, generuje příslušné konfigurační soubory a bezpečnou a autentizovanou cestou je předává servisním démonům na řízených počítačích. Spolu s konfiguračními soubory je předáván i skript pro aktualizaci příslušné služby, který je po ověření integrity na řízeném počítači proveden, zpravidla s identitou privilegovaného uživatele.

2.7  Uživatelské rozhraní

Přístup do databáze je možný, s ohledem na implementaci integritních omezení přímo v databázi, libovolným klientským programem podporujícím připojení k databázi Oracle na požadované bezpečnostní úrovni. V současné verzi je implementováno několik formulářů aplikace Oracle Forms, které poskytují grafické uživatelské rozhraní pro nejčastější operace (např. přidání uživatele). Tyto formuláře je možno spouštět teoreticky na celé řadě platforem, včetně libovolného WWW browseru s podporou Javy. Vzhledem k omezené kapacitě vývojového týmu ale zůstává primárním přístupovým nástrojem řádkový interpret jazyka SQL.

Díky popsanému systému generování konfiguračních souborů a jejich propagace na řízené počítače není kromě přístupu do databáze nutná a ani žádoucí žádná jiná interakce uživatelů - správců se systémem (např. spouštění dalších programů, signalizace událostí démonům apod.).

2.7  Bezpečnost

Zabezpečení systému se obecně opírá o autentizační systém Kerberos verze 5. Pomocí tohoto systému je jednak ověřována identita uživatelů při přihlášení do databáze (adekvátní bezpečnostní úrovně lze ale dosáhnout i jinými prostředky poskytovanými Oraclem) a zejména je jím zabezpečena propagace změn na řízené počítače.

Požadujeme, aby databázový server a hlavní proces aplikace běžely na počítači, který považujeme za zabezpečený. Na lokálním disku tohoto počítače jsou uloženy důvěryhodné verze skriptů pro aktualizaci služeb a klíče pro autentizaci.

Hlavní proces se v okamžiku aktualizace konkrétní služby krátkodobě autentizuje systému Kerberos na základě bezpečně uloženého klíče, získá lístek, kterým se prokáže servisnímu démonovi na řízeném počítači, a zabezpečeným komunikačním kanálem mu předá vygenerované konfigurační soubory a důvěryhodný aktualizační skript.

Servisní démon převezme konfigurační soubory a skript, uloží je na lokální disk, podle lokálního konfiguračního souboru ověří, zda je oprávněn aktualizovat danou službu, a po ověření integrity získaných souborů skript spustí s identitou privilegovaného uživatele.

Z bezpečnostního hlediska je kritický především kód servisního démona, ten je ale udržován v minimálním možném rozsahu (dohromady méně než 1000 řádků zdrojového kódu v jazyce C), a je tedy poměrně snadno ověřitelná jeho bezpečnost.

Další potenciální riziko představují skripty, ale zde už je (modulo bezpečnost samotného servisního démona) vyloučena možnost úmyslného útoku. Skripty samy jsou také, mimo jiné i vhodným návrhem služeb, udržovány co nejjednodušší (zpravidla méně než 100 řádků skriptu pro sh nebo awk) a jsou navrženy tak, aby možnost zanechání služby v nekonzistentním stavu byla minimalizována i v případě výpadku během provádění skriptu.

2.8  Použití v praxi

Systém Perun je v současné době používán v Brněnském superpočítačovém centru pro řízení uživatelských účtů na serverech i pracovních stanicích. Kromě toho slouží také jako autoritativní databáze oprávněných uživatelů META Centra používaná správci všech zapojených uzlů. Záměrně není koncipován jako obecný nástroj pro personalistické účely, s ohledem na použité databázové technologie ale může být s takovými systémy poměrně hladce propojen.

V současné době probíhá příprava nasazení systému na správu části počítačů provozovaných na Přírodovědecké fakultě MU, která přinese podstatný nárůst objemu dat i zátěže celého systému. Vypovídající údaje o použitelnosti sytému v takových podmínkách očekáváme do konce roku 1999.

V tomto kontextu začíná vystupovat nutnost synchronizace systému s jinými datovými zdroji. Rozsáhlé a relativně frekventované změny probíhají zejména mezi uživateli - studenty. Správcům je třeba maximálně usnadnit zřízení přístupu nových uživatelů k výpočetním zdrojům a naopak efektivně blokovat neoprávněný přístup bývalých studentů a zaměstnanců. V případě Masarykovy univerzity je většina potřebných údajů dostupná v centrálním informačním systému. Ve spolupráci s vývojovým týmem tohoto systému pracujeme na vzájemném přímém propojení datových schémat.

V budoucnu je plánováno další rozšíření systému Perun o služby zajišťující správu programového vybavení a přístupu uživatelů k němu.

Literatura

[BM91] S.M. Bellovin and M. Merritt. Limitations of the Kerberos Authentication System. In Usenix Conference Proceedings, 1991.
... zpět do textu
[DW98] J. Danielsson and A. Westerlund. Heimdal - an Independent Implementation of Kerberos 5. In Usenix Conference Proceedings, 1998.
... zpět do textu
[KN93] J. Kohl and C. Neuman. The Kerberos Network Authentication Service (V5), 1993. Network Working Group RFC 1510.
... zpět do textu
[RGL88] Mark A. Rosenstein, Daniel E. Geer and Peter J. Levine. The Athena Service Management System (Moira). In Proc. Winter Usenix, 1988.
... zpět do textu
[SNS88] J. G. Steiner, C. Neuman and J. I. Schiller. Kerberos: An Authentication Service for Open Network Systems. In Usenix Conference Proceedings, 1988.
... zpět do textu
setting
1 Za její zprovoznění vděčíme především Danielu Kouřilovi.
... zpět do textu
2 Jméno, za které vděčíme Tomáši Urbánkovi, jsme použili záměrně jako slovanskou protiváhu Moiře, řecké bohyni osudu. Jméno záhadného, všemocného, náladového a nevyzpytatelného boha s jistou nadsázkou i vystihuje chování prvních experimentálních verzí systému.
... zpět do textu
3 Tento článek je mírně modifikovanou verzí příspěvku, který byl přednesen na konferenci Rufis'99, konané v září 1999 v Brně.
Zpět na začátek
ÚVT MU, poslední změna 14.11.2011