Přeskočit na obsah

Servery a Conglomerate Host

Tato stránka je pro Ownery a IT Organizace, která pro Lazurio provozuje vlastní servery. Conglomerate Host je server, na kterém běží soukromá síť (Headscale) a trezor (Vaultwarden) pro Prostředí na serveru jedné nebo více Organizací.

Kde je níže pravidlo jen konvence, nic ho nekontroluje: nic neuděluje a kvůli němu se existující servery nepřejmenovávají ani nepřečíslují.

  • Virtualizační host: <org>-proxmox-NN, například example-proxmox-01. <org> je krátký štítek, který Owner zvolí jednou. Nemění se, když se změní GitHub login nebo DNS jméno Organizace, takže správce více Organizací rozliší své hosty v konzoli poskytovatele, v SSH i v tailnetu. Číslování začíná 01 a smí přerůst dvě číslice. Je to konvence.
  • Prostředí služeb: každý server Organizace má právě jedno services-NN s číslem svého serveru (<org>-proxmox-01 má services-01). Je to Pracovní Prostředí jen pro Ownery a Adminy a každá služba v něm běží ve vlastním kontejneru. Když mu nestačí výkon, zvětší se; druhé na tomtéž serveru nevzniká (rozhodnutí 0209).
  • Zařízení lidí v tailnetu: <login>-<zařízení>, například <login>-macbook. <login> je štítek síťového uživatele člověka: u účtu propojeného s GitHubem jeho GitHub login malými písmeny, zmrazený, takže pozdější přejmenování na GitHubu síťového uživatele nepřejmenuje. <zařízení> je krátký štítek zvolený jednou a stejný ve všech tailnetech. Druhý, headless klient na tomtéž zařízení je <login>-<zařízení>-cli a Osobní Prostředí na serveru <login>-personal-vm. Jméno nastavuje majitel na zařízení samém. Jméno nic neuděluje.
  • Každý Conglomerate Host dostane vlastní rozsah uvnitř 100.64.0.0/10, který se nepřekrývá s žádným jiným Conglomerate téhož provozovatele (rozhodnutí 0155). Jinak by každý tailnet rozdával stejné adresy 100.64.0.x a počítač správce by je nerozlišil.
  • Provozovatel, který Conglomeraty zakládá, si vede seznam rozsahů, které přidělil, jako pomůcku pro sebe. Není to centrální autorita ani registr cizích sítí.
  • Nový Conglomerate Host musí svůj rozsah určit při založení. Existující si rozsah ponechá, dokud ho nepřečísluje řízená migrace.

Správa Conglomerate Hostu

Sekce “Správa Conglomerate Hostu”

Správa hostu se dotýká všech Organizací, které obsluhuje. Pravidla níže jsou standard: sám nic neuděluje a nedokazuje, že ho Organizace nasadila. Konkrétní účty, zařízení, klíče, síťové vazby a důkazy patří do infrastrukturního repozitáře vlastníka hostu. Pro každého Ownera platí:

  • Vlastní cesta, vlastní klíče, tři druhy zdrojů. Po schváleném onboardingu může host spravovat každý aktivní GitHub Owner Organizace, která ho vlastní, a to jen:

    • ze svého osobního počítače výslovně povoleného pro správu;
    • ze svého Osobního Prostředí;
    • ze svého výslovně jmenovaného Pracovního Prostředí (rozhodnutí 0202, zatím nenasazené).

    Telefon, jiná Pracovní Prostředí ani pracovní laptop správu nedostanou, ani když jsou schválené pro jiný přístup. Owner používá vlastní jmenovitou identitu přes soukromou síť a nativní SSH a jeho klíče jdou odvolat jednotlivě. Cesta nikdy nezávisí na IP adrese, počítači, přihlášení ani soukromém klíči jiného Ownera nebo dodavatele a soukromý klíč zůstává na svém zařízení.

  • Roli dokazuje jen GitHub. Členství v tailnetu, sdílený síťový uživatel, štítek Prostředí ani jméno serveru roli Ownera nedokazují. Rozhoduje živá role na GitHubu a přesná vazba zdroje na daného Ownera a přístup se nikdy nedává všem uzlům Organizace najednou.

  • Jen přesné granty. Host má jmenovité SSH účty, přesné síťové granty a jen ta správcovská práva, která práce potřebuje. Odpověď na navázané spojení neopravňuje otevřít spojení opačným směrem. Novou IP adresu nebo novou registraci zařízení opravuje schválená změna přesné vazby, nikdy širší grant.

  • Onboarding končí změnou, ne přihlášením. Samotné funkční přihlášení přes SSH onboarding Ownera nedokončuje. Owner pod vlastním účtem umí:

    • přečíst stav sítě a konfiguraci, kterou potřebuje;
    • dostat se do infrastrukturního repozitáře Organizace;
    • navrhnout, ověřit a provést schválenou změnu běžným postupem nasazení s vlastními přístupy;
    • vysvětlit publikaci, review a obnovu a mít vlastní cestu k obnově.
  • Správcovská práva neobcházejí postup. Požadovaný stav zůstává v infrastrukturním repozitáři a každá změna prochází review a postupem nasazení, u Ownera stejně jako u agenta. Nezávislá kontrola může potřebovat dalšího oprávněného Kolegu, nikdy ale tajný údaj, který má jen dodavatel.

  • Odvolání je samostatný krok. Když Owner odchází, mění roli nebo ztratí zařízení, odvolejte jeho granty a klíče a kde to jde, ukončete i živé relace. Zapište, jestli to proběhlo automaticky, nebo ručně. Role se kontroluje při nasazení přístupu, ne při každém přihlášení přes SSH.

  • Sdílený host má víc nájemců. Owner jedné Organizace nemá automaticky právo spravovat host jiné Organizace: schválení odpovídá vlastnictví hostu a celé jeho sdílené hranici. Správa nikdy neopravňuje číst cizí Personalspace.

  • Vzdálené ovládání sahá dál než síť. Plné ovládání počítače člověka z Pracovního Prostředí může nepřímo zpřístupnit správcovské přístupy toho počítače a síťové pravidlo proti přímé cestě to nezastaví. Rozsah vzdáleného ovládání držte vědomý a zdokumentovaný a neslibujte přísnou izolaci.

  • Nejdřív soukromá síť, záchrana poskytovatele pro nouzi. Správa jde přes soukromou síť. Konzole poskytovatele a jeho záchranný režim jsou nouzová cesta. Než zavřete veřejnou záložní cestu přes SSH, ověřte, že funguje soukromý vstup, oprávnění k obnově u poskytovatele, identita hostu i návrat do běžného startu. Záchranný režim může přerušit sdílené služby, proto každou nouzovou změnu promítněte zpět do infrastrukturního repozitáře a jeho záznamů.

  • Nasazené znamená prokázané. Infrastrukturní repozitář vlastníka hostu zaznamenává povolená zařízení a jejich vazbu na současné Ownery. Zaznamenává i nasazenou verzi, důkaz nasazení a oba druhy testu: skutečné přihlášení přes SSH a se správcovskými právy z každého povoleného zdroje a odmítnuté spojení ze zdroje, který povolený není. Standard, plán, otevřený pull request a živé nasazení jsou čtyři různé stavy.

Dva výsledky předání Prostředí na serveru

Sekce “Dva výsledky předání Prostředí na serveru”

Toto je cílový kontrakt předání Prostředí na serveru a jeho implementace ještě není dokončená: běžící Prostředí se od něj může lišit. Co je nasazené, důkazy a pořadí oprav patří do infrastrukturního repozitáře vlastníka Prostředí. Předání má dva výsledky a každý se prokazuje zvlášť.

Prostředí na serveru je připravené k předání, když:

  • jsou ověřené jeho prostředky, operační systém, identita, správa, síť a izolace;
  • webový vstup má platný certifikát, správné DNS a funkční bránu;
  • čisté Lazurio a základní pracovní vstup běží bez checkoutu Organizace, bez osobního GitHub tokenu a bez přihlášení uživatele k nástrojům AI;
  • Lazurio ukazuje pravdivý prázdný stav a chybějící checkout nezpůsobí pád, automatické klonování ani přístup k jiné Organizaci;
  • opakovaná instalace zachová identitu a existující pracovní data;
  • záloha a obnova mají vlastní ověřený výsledek. Pokud pilot obnovu výslovně odloží, report to omezení uvede a obnovu za ověřenou neoznačí.

Uživatel je připravený pracovat v individuálním Prostředí, které má jednoho přiděleného uživatele, když:

  • má za sebou vstup ze svého zařízení a přihlášení vlastním účtem do GitHubu (gh);
  • má vybrané a nastavené Organizace, které potřebuje a ke kterým má přístup, každou jako samostatný checkout a hranici přístupu;
  • své checkouty najde bez změny konfigurace hostingu a moduly přitom zůstávají v hranici své Organizace a živých práv;
  • má nastavené vlastní nástroje, přihlášení a závislosti projektů;
  • má ověřenou skutečnou práci. Úspěšné přihlášení na web nedokazuje SSH, přístup do Gitu, funkci každého modulu ani obnovu aplikace.

Sdílené Týmové Prostředí osobního uživatele nemá, a proto pro něj neplatí pravidlo individuálního Prostředí, kde se uživatel přihlásí vlastním účtem a připojí kteroukoli svou Organizaci. Na GitHubu pracuje přes aplikaci Lazurio for GitHub Organizace s omezeným rozsahem Organizace a Teamu, nikdy s osobním tokenem toho, kdo se přihlásil naposledy (rozhodnutí 0147). Ani instalace Lazuria tam nepotřebuje checkout dat Organizace a nastavení obsahu Teamu je samostatný krok pod identitou Teamu.

Čekání na přihlášení člověka je onboarding pending, ne porucha zřizování; název popisuje stav, není to hodnota v žádném systému. Report nikdy nesloučí infrastrukturu, základní Lazurio a přijetí uživatelem do jednoho zeleného políčka.