Inshipia Security Gateway

Egy webes konzol előkészítése

Mi kell egy webes konzolnak, mielőtt az ISG brókerezheti — a célgép-előkészítés Web Access-párja. Magát a konzolt a legtöbb esetben nem kell módosítani: azt kell eldönteni, hogyan tudja meg, ki a felhasználó, és hol él a közös fiókjának a titka.

A hálózat

Hogyan tudja meg a konzol, ki a felhasználó

A konzol… identity Mit kell előkészíteni
nem ismer saját felhasználókat (Prometheus, egy levélgyűjtő) none semmit
elfogad egy aláírt tokent egy fejlécben (a Grafana [auth.jwt]-je) jwt a konzol megbízik a listener nyilvános kulcsában; role_map a szerepköreihez
HTTP Basicet vagy egy fejlécben küldött API-kulcsot fogad (egy BMC Redfish API-ja) credential, kind: basic vagy header egy közös fiók, a titka OpenBao-ban
űrlappal és munkamenet-sütivel léptet be (a legtöbb webes GUI) credential, kind: form egy közös fiók, a titka OpenBao-ban, és a belépési recept

Aláírt tokent elfogadó konzol

Példaként a Grafana, a konfigurációs fájljában (vagy a megfelelő környezeti változókkal):

[auth.jwt]
enabled = true
header_name = X-ISG-Assertion
jwk_set_url = https://grafana.apps.example.internal:8444/.well-known/isg/jwks.json
expect_claims = {"aud": "grafana", "iss": "isg"}
username_claim = sub
email_claim = email
role_attribute_path = role

A szállított Ansible ezt a csomagolt Grafanának beállítja, az URL helyett jwk_set_file-lal (a config-forrás JWKS-fájljával), így a Grafana sem a brókerektől, sem a névfeloldástól nem függ. A reserved_usernames-t hagyd úgy, ahogy van: a token sub-ja a konzol azonos nevű helyi fiókjára kerül.

Egy közös fiók

A fiókot a konzolon a konzol saját adminisztrátora hozza létre, azokkal a jogokkal, amik az adott credentials elem felhasználóinak járnak — csak olvasó fiók egy csak olvasó csoportnak, adminisztrátori fiók az adminisztrátoroknak. A titka OpenBao-ba kerül, az operátor írja; az ISG csak olvassa:

bao kv put secret/isg/apps/<app name>/<account name> username=<account> password=<password>
bao kv put secret/isg/apps/<app name>/<account name> value=<api key>

Az út <kv_mount>/data/<prefix>/<app>/<name>; a brókerek OpenBao-tokenjének olvasási jog kell erre a prefixre (az isg_bao_init role bróker-policyja ezt adja). Egy brókeren az isg system check megmondja, minden fiók olvasható-e: a Web Access credentials sor. Egy második faktorral védett űrlapos belépéshez add hozzá a totp_secret-et (a base32 seedet), és használd a {{totp}}-t a receptben.

Egy űrlapos belépési recept

A recept azt ismétli meg, amit a konzol saját belépő oldala tesz. Így írhatsz egyet:

  1. Nyisd meg közvetlenül a konzol belépő oldalát, a böngésző fejlesztői eszközeiben a Network fülön, és lépj be.
  2. Keresd meg a kérést, ami a felhasználónevet és a jelszót viszi: a metódusát, az útvonalát, és hogy a törzse űrlap (encoding: form) vagy JSON (encoding: json). Ha az oldal előbb egy tokent tölt (egy CSRF-mezőt a HTML-ben, egy fejlécet, egy sütit), tegyél elé egy GET lépést egy extract szabállyal (from: body, header:<Name> vagy cookie:<name>, és egy RE2 regex egy rögzítő csoporttal), és használd {{token.<name>}}-ként.
  3. Siker: hogyan néz ki a válasz a belépésre — a státusza, a munkamenet-süti, amit beállít, vagy hová irányít. Legalább egyet nevezz meg.
  4. Kiléptetve: hogyan néz ki egy válasz, ha a konzol munkamenete véget ért — többnyire egy 401 az API-jától, vagy egy átirányítás a belépő oldalra. Ha a konzol olyasmire is 401-et ad, ami nem kiléptetés (egy token-forgatás, amit a saját szkriptje intéz), nevezd meg a válasz törzsének egy szövegét az unless_body_contains-ban.
  5. Azok a sütik, amiket az oldal szkriptjének magának kell olvasnia (egy fejlécbe tükrözött CSRF-süti), a browser_cookies-ba kerülnek; minden más süti a brókernél marad.

Valódi konzolokon látott viselkedések