Hogyan működik a Web Access

A Web Access a webes konzolokat — Grafana, Prometheus, egy levélgyűjtő, egy BMC webes felülete vagy API-ja — ugyanazon belépés, csoportok, jóváhagyások, zárak és audit mögé teszi, mint az SSH-t. A konzol gépén nincs ágens, a böngészőben nincs bővítmény: a brókerek minden alkalmazás előtt fordított proxyként állnak, a böngésző pedig az alkalmazás saját hosztnevét éri el, ami a brókerek közös címére oldódik fel.

Ez a lap egy kérés útja. Hogy egy alkalmazás hogyan kerül az apps.yaml-be, az az alkalmazások beállítása; hogy ki jut be és mit tehet egy-egy kérés, az a Web Access-policy; hogy mi kell magának a konzolnak, az egy webes konzol előkészítése.

A részek

• Egy TLS-listener minden brókeren (apps.yaml: listen, a szállított Ansible-ben alapból a 8444-es port). Minden alkalmazás ezen érhető el; a hosztnév (az SNI és a Host fejléc) választja ki az alkalmazást. Egy ismeretlen hosztnév 421-et kap. A listener tanúsítványának (tls_cert_file) minden alkalmazás host-ját le kell fednie; ezt az apps.yaml betöltésekor ellenőrizzük.
• A webUI, ami a belépést végzi. A Web Access-nek nincs saját belépése: jelszó és második faktor, vagy SSO, pontosan, mint magánál a webUI-nál (webui_url).
• Az alkalmazás upstreamje (upstream), amit a bróker ér el, sosem a böngésző. A konzol gépének tűzfala a brókereket engedi be; a Web Access mellett az adminok hálózatáról vezető közvetlen út lezárható.
• Az OpenBao, amit a bróker egy közös fiókos identitású alkalmazásnál (identity: credential) olvas.
• A rekord-tár, ahol minden alkalmazás-munkamenet egy munkamenet-rekord transcripttel, mint egy SSH-munkamenet (http protokoll).

Egy alkalmazás megnyitása

1. A felhasználó megnyitja az alkalmazás címét (vagy rákattint a webUI Alkalmazásaim oldalán, /apps, ami felsorolja, mit nyithat meg ez a felhasználó). Az alkalmazás-hivatkozások új lapon nyílnak.
2. Még nincs alkalmazás-munkamenet: a proxy egy rövid életű állapot-sütit ad a böngészőnek, és a webUI átadási végpontjára küldi (/apps/handoff). Ha a felhasználó nincs belépve a webUI-ba, a webUI előbb a belépést kéri, aztán folytatja.
3. A kapuk, a webUI-n: a felhasználónak az alkalmazás allow_groups csoportjainak egyikében kell lennie, nem léphet be tiltott néven, nem lehet zárolva (sem ő, sem az alkalmazás), és — ha az alkalmazás kéri — nyitott jóváhagyási ablakkal kell rendelkeznie (négy szem elvű, vagy indoklással önkiszolgáló). Egy elutasítás APP_ACCESS_DENIED audit-sor az okával; a felhasználó egy általános mondatot lát.
4. Az átadás: a webUI egy egyszer használatos, 60 másodpercig érvényes kódot ad, és a böngészőt visszaküldi az alkalmazás /_isg/callback címére. A proxy a kódot csak abban a böngészőben váltja be, amelyiknél az illő állapot-süti van, még egyszer ellenőrzi a jóváhagyást, a zárat és a licencet, és megnyitja az alkalmazás-munkamenetet: az isg_app süti (HttpOnly, Secure, SameSite=Lax) az alkalmazás hosztján. Az audit-sor APP_SESSION_STARTED.
5. Ettől kezdve minden kérés hordozza az isg_app-ot, és a proxy továbbítja az upstreamnek.

Minden kérés

Egy nyitott alkalmazás-munkamenet minden kérésénél a bróker, ebben a sorrendben:

• ellenőrzi, hogy a munkamenet él (tétlenségi határ idle_timeout_seconds, alapból 1800 s; abszolút határ max_duration_seconds, alapból 28800 s; a webUI-belépésnek, amiből jött, még élnie kell), és hogy azóta nem került rá zár;
• megítéli a kérést a policy.yaml http_rules szabályai szerint (metódus, útvonal, szerepkör; egy deny, egy friss második faktort kérő step_up, vagy az alkalmazás engedélylista-módja) — a Web Access-policy lap;
• eltávolítja az ISG saját sütijeit és minden identitás-fejlécet, amit a böngésző küldött, majd hozzáadja az alkalmazás identitását: semmit (identity: none), egy friss aláírt assertiont (identity: jwt), vagy egy közös fiók titkát OpenBao-ból (identity: credential: egy Authorization: Basic fejléc, egy megnevezett fejléc, vagy — belépő űrlapos konzolnál — egy olyan fiók upstream munkamenet-sütijei, amivel az ISG maga lépett be);
• egy sort ír a munkamenet transcriptjébe: metódus, útvonal, státusz, méret, idő, a közvetített fiók; record_body mellett egy módosító kérés maszkolt törzsét is.

Ha a kérést nem lehet rögzíteni, a policy nem tölthető be, a címtár nem kérdezhető, vagy a titok nem olvasható, a kérés nem megy át (503) — a Web Access zárva hibázik.

Hogyan ér véget egy munkamenet

A webUI-ból kilépés, a csoport elvesztése, egy zár, egy adminisztrátori lezárás, egy jóváhagyási ablak vége, vagy a tétlenségi vagy az abszolút határ lezárja az alkalmazás-munkamenetet — minden brókeren, a kiszolgáló brókeren legfeljebb kb. 5 másodperc alatt. Egy kérés az alkalmazás logout_paths útjainak egyikére az adott alkalmazásnál kilépteti a felhasználót az ISG-ből. Az audit-sor APP_SESSION_CLOSED, az okával.

Amit a böngésző sosem lát

• A közös fiók jelszavát vagy kulcsát, egy identity: credential alkalmazásnál: a bróker olvassa OpenBao-ból, és felfelé menet teszi a kérésbe.
• Az upstream munkamenet-sütijeit, egy kind: form fióknál: a bróker memóriájában maradnak, alkalmazás-munkamenetenként és fiókonként. Csak azok a sütik mennek át mindkét irányban, amiket egy recept a browser_cookies-ban megnevez.
• Az assertion aláíró kulcsát, egy identity: jwt alkalmazásnál: az alkalmazás azzal a nyilvános kulccsal ellenőrzi az assertiont, amit a listener a /.well-known/isg/jwks.json címen szolgál ki.

Ami a Web Access nem

• Az alap módban nem rögzíti egy alkalmazás képernyőjét: a transcript kérés-szintű. Egy mode: isolated alkalmazás távoli böngészőben fut, és képként rögzül; lásd az izolált böngésző lapot.
• Nem ítél meg egy kérés-törzsben kódolt műveletet, és egy WebSocket kereteit sem: egy szabály a megnyitó kérést látja.
• Nem ad a konzolnak saját második belépést: a felhasználó az ISG-be lép be, és a konzol azt az identitást látja, amit az ISG a kérésbe tesz.